Jump to content

aqrit

Members
  • Posts

    37
  • Joined

  • Last visited

About aqrit

aqrit's Achievements

  1. > I tried debugger (gdb, objdump) I'm not familiar with any linux tools for this. Assuming EE is even written in C++... gdb could probably get the job done, but you'll probably want something specialized for this type of work. For debuggers/disassemblers, I assume most people use Ghidra or IDA Pro on linux. The freeware version of IDA Pro doesn't include a debugger or decompiler though. Maybe radare2 (or cutter) could be good? For memory scanners: top google results are "GameConqueror" or "PINCE". > I'm curious how you discovered that this function/offset - 0x00220F4F is responsible for the root inventory background/menu? I don't recall, that was ~10 years ago. However, hooking the DirectDraw API and watching the callstack would've made it clear which function was drawing to which screens. There are many ways to find this function, that is the "game" of reverse engineering. e.g. the inventory menu has a hot-key of "i" so one could hook the keyboard handler then trace to the code that launches the inventory. Or one could hook the open file API then trace the lifetimes of the CHU or background image files. A memory scanner combined with hardware breakpoints is a giant shortcut to a lot of different strategies... > In general, do you think that the example idea of inventory (grid/background) on the left and the game-world on the right is possible to obtain in EE version? All things are possible, given enough time... I don't own the EE version and I haven't followed any news about any of the enhancements... but they probably changed the code a lot around this area.
  2. Learning to patch an executable would require understanding regular programming, then say another ~6 months to learn assembly and reverse engineering.
  3. Are you doing any engine modding? In the original PST the background was set to be transparent and it mostly worked due to how the DirectX swap_chain was setup. However, to get it working right™... The draw code of all the menus should have been modified to redraw both the "game view" and the menu, every frame. http://www.shsforums.net/topic/56475-drawing-transparent-menu-backgrounds-wip/
  4. Sounds similar to http://www.shsforums.net/topic/38012-a-mouse-scrolling-problem/page-3#entry442993 Which I though was fixed for TotSC starting with widescreen mod v3.06 I don't have a CD-ROM installed at the moment... so I can't investigate.
  5. Maybe there is some trick for "EE" but... I don't think the upscaling method as proposed would work. There is always a hard coded distance check somewhere... The only solution is engine modding. The game itself would be blissfully unaware of any changes. One would do the typical "DxWnd" style window mode mod. Then hook into the entire graphics sub-system. I hooked into the original engine's ddraw system to improve the fog of war effect, it might be of interest: https://github.com/aqrit/ddwrapper/blob/95c64084f640d51552f0e77c140d9af71af7cc76/torment.cpp#L398
  6. Which is a good reason to NOT DO THAT. User input needs to be solicited at the beginning. If a tool stacks multiple mod installs then that tool should also assume *full* responsibility for moving the "beginnings".
  7. But it is possible via manual review by a "install tool" maintainer. Yes. Each mod revision requires attention. There is no way around this. What would happen if I decided to changed my subcomponent numbers (or behaviors) between releases? the "unattended install tool" should ask these questions up front. The "unattended install tool" should save the responses that it has already received. Then how (and why) did you queue four hours of unattended mod installs? This makes no sense. Batch scripts are a form of "install tool". A script can prompt questions, verify input, and save responses. Could a script pipe to weidu? I don't know. Could a script edit a tp2 file? Yes. Could a custom program pipe input to weidu? Yes.
  8. The mod install process should NOT be automated unless the exact version of the mod is known. If the exact mod version is known... a "tool" has a couple of options: 1. pipe/send/inject input to automatically fill out READLN prompts with appropriate values. 2. rewrite the mods source code, replace READLN with some helper function that sets the appropriate value. If the 10th mod to install needs absolutely needs input from user -- then -- that input should be asked for upfront, before the tool launches any installation steps for intervening mods. This is how unattended installation should work. Trying to outsource this or related problems to mod creators or weidu is entirely wrongheaded.
  9. Failure on unknown STATS_*PROFICIENCY* https://github.com/Ascension64/TobEx/blob/b5c43d7f0799edb8a40873732d65cd06c60db047/TobEx/src/include/rule.h#L327 https://github.com/Ascension64/TobEx/blob/b5c43d7f0799edb8a40873732d65cd06c60db047/TobEx/src/ext/EffectOpcode.cpp#L3742 what mod is trying to use it? why not post in the tobex forum?
  10. https://codeload.github.com/Gibberlings3/widescreen/zip/master unzip and place the 'widescreen' folder into your game folder *note: the 'widescreen' folder is inside the 'widescreen-master' folder http://www.weidu.org/~thebigg/WeiDU-Mac-240.zip copy 'weidu' file to the game folder rename 'weidu' to 'setup-widescreen' run 'setup-widescreen' *note: I've never used a mac... edit: or... [Tool] Easy mod installer (WeiDu launcher) for OS X by subtledoctor https://forums.beamdog.com/discussion/17717/tool-easy-mod-installer-weidu-launcher-for-os-x/p1
×
×
  • Create New...