Hotseat with DxWnd

[Flocke]

Edit: For those in search, here an update on the preferred hotseat approach:

1. Duplicate install folder
2. Then, from windows start run "regedit" command to access the registry editor.
   Lookup and duplicate the registry keys from selected install at "HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microprose\Star Trek: ...".
   Adjust the InstallPath but for next step keep care to not lengthen the new registry key name.
   
   The registry keys actually are split to "Microprose" and "Microsoft\DirectPlay\Applications" folders, but duplicating the Microprose ones from my testing seems to be sufficient.
3. with a hex editor edit trek.exe registry keys at 0x00174357 and 0x0017b09f
4. change the trek.exe window name at 0x00188c47 so it is unique
5. edit the stbof.ini application path
6. and in my case, for the second run I had to enable window 8 compatibility mode
   ( also refer viewtopic.php?p=58950#p58950 )

copied from viewtopic.php?p=58557#p58557

------

Analysing issues of the corrupted UDM3 MP save game, I noticed that I can't run multiple game instances at same time of same mod, even when copied to another folder with adjusted ini. From what I found DxWnd has an option to allow run multiple instances, trek.exe itself however must have a check to prevent this. For hotseat and testing I think it would be great to disable that check.

Since mpr++ already allows to run multiple instances, I must have disabled it there too, so it should be easy to find. I can have a look what check it is you need to nop.

[thunderchero]

I went ahead and split this off to a new topic,

I did some quick tests this morning with dxwnd gui and dxwnd proxy

the proxy does not have global settings/flags so setting "run multiple instances"

here is what I tried

1. created duplicate folder
2. edited install path in stbof.ini
3. edited trek.exe to read new registry I manually created with new path

when I attempted to run multiple instances I got a message C:\botf\vanilla\mpr

so I suspect the new MPR++.dll is why MPR++ will allow multiple instances? but I could be wrong.

[thunderchero]

Edit I was wrong about mpr file,

hotseat.jpg (441.03 KiB) Viewed 2852 times

this works when using DxWnd GUI or DxWnd proxy
I used vanilla files to run multiple instances

1. sacrifice a different install in this case I used ECM added the stbof.res and trek.exe from vanilla to ECM folder
2. edited trek.exe to read ECM registry. 2 locations 0x00174357 and 0x0017b09f
3. edited the window name. (this is what was preventing both from loading) 1 location 0x00188c47
4. edited the version in ECM registry so it matched vanilla "HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microprose\Star Trek: ECM"

edit; if #2 and #4 are not done I could still load M\P game in DxWnd GUI (windowed) but using DxWnd proxy first instance would load in windowed mode and second instance would load full screen without dxwnd (mouse lag)

Flocke, you might know where/how MPR++ allows 2 window instances with same name? this might allow hotseat from same install path?

[Spocks-cuddly-tribble]

run multiple game instances at same time of same mod (...) trek.exe itself however must have a check to prevent this (...) have a look what check it is you need to nop.

the window name. (this is what was preventing both from loading) 1 location 0x00188c47

Try removing this:

Code: Select all

00401F88                 jz      loc_402045 // 0x1388 (0F 84 B7 00 00 00) -> nop

If this doesn't work the check should be nearby.

But be careful there is a reason to prevent countless instances of the same mod (e.g. unwanted/unnoticed redundant tasks due to mistakenly double-clicking - causing possible issues).

[thunderchero]

Try removing this:

Code: Select all

00401F88                 jz      loc_402045 // 0x1388 (0F 84 B7 00 00 00) -> nop

did a quick test of your suggestion but no go. Flocke edited that sub a lot for MPR++ so he might have an idea

[Flocke]

been close!
at 401DFD is a jump if zero statement that needs to be fixed to always jmp to the right branch:

check_window.jpg (57.73 KiB) Viewed 2807 times

ofc then the left branch and the FindWindowA call become redundant

For a better fix, instead of the window name, the game path should be checked. In combat the game writes temporary files, which makes the second instance crash when it tries to write combat files at same time. That is why you need to copy the game files and change execution path when running two instances.

edit:
alternatively to fixing the jz, it should work to nop the whole check from 00401DEB to 00401E16 and 00401E1F to 00401E26, but leave the xor eax, eax statement to set eax to zero, which previously was ensured by the jz check. That case you however also should ensure to set esi to zero as well, which previously was ensured at 00401DF9!

nop_check_window.jpg (125.62 KiB) Viewed 2804 times

[thunderchero]

I tried your code changes, but second instance would not load for me. (if I did it correctly)

In combat the game writes temporary files, which makes the second instance crash when it tries to write combat files at same time.

when in combat the file can be written in same folder since file names are different (tested with MPR++)

example in my test
H0000001.tac (federation)
K0000001.tac (klingons)

[Flocke]

when in combat the file can be written in same folder since file names are different (tested with MPR++)

example in my test
H0000001.tac (federation)
K0000001.tac (klingons)

that is not the only files it writes:

combat_files.jpg (30.47 KiB) Viewed 2778 times

I remember for sure with mpr++ it frequently crashed on combat due to file conflicts.

Further auto.sav likely does conflict too.

edit: ahh well, regarding tevent.txt I found it is triggered by the Mudd cheat I use for testing
viewtopic.php?f=204&t=75
never thought of it to trigger debug files

[Flocke]

I tried your code changes, but second instance would not load for me. (if I did it correctly)

here is what I edited:

hex_changes.jpg (27.39 KiB) Viewed 2768 times

For me it fails to run twice from same folder as well, but shows an error message this time.
By the event log it failed at error offset 0x0011371c, which didn't bring me any far.
Attaching visual studio as a just in time debugger, I then however found it actually stopped at asm offset 0x51371C, which is located in _3DFX_MPR, short after MPROpenDevice.

dualinst_crash.jpg (25.43 KiB) Viewed 2768 times

Further, after a second, I found it tried to acquire the full screen again, so it might be an issue with dxwnd that it doesn't run second instance in windowed mode.

If I copy the folder and dxwnd entry and modify path it however can be run twice now with same window name.
If I just copy the Dxwnd entry, the second instance tries to start full screen and then crashes for me, too.

The trek.exe 2nd instance window name check however clearly is disabled with above patch. Just clone the game folder and dxwnd entry to get it work - no registry changes needed.

[thunderchero]

If I copy the folder and dxwnd entry and modify path it however can be run twice now with same window name.

but crashes on turn process. duplicate folder trek.exe does not have dplay registries?

It looks like the only way to use same folder is MPR++

[Flocke]

but crashes on turn process. duplicate folder trek.exe does not have dplay registries?

Looks like that's a problem indeed. For single player it works, but mp games not.

[Flocke]

I checked the dxwnd source code hosted on https://sourceforge.net/projects/dxwnd/ whether I'd find something.

As far I understand the code, the game executable path is used to map the hooks, therefore only one hook at a time is supported. Further Dxwnd only can be run once at a time cause it installs some global semaphores and stuff for multi process communication.

To get it work, I think the path name needs to be expanded by the process or window handle as a unique identifier.
But I only took a small glimpse and there might be more issues ahead.

Further, the code base sadly is pretty outdated, with project files still depending on Visual Studio 2008 and MFC.
I'd have a hard time to try fix the issue, so if at all I think the author might help.

[Spocks-cuddly-tribble]

How about the relocation issue?

Remember some mods have the relocation table removed/disabled (and/or use advanced patches breaking the table).

If I'm not mistaken only the first instance of BotF can use the preferred RAM address? (albeit modern OS's might do some virtual magic to solve the issue?)

Is it certain that multiple instances of BotF do not open the door for very hard traceable issues? And how does MPR++ avoid this problem?

[thunderchero]

I tried several different ways to get this to work, but from what I found it looked to me the issue was in mpr97.dll and gen.mpr file. I even tried to create dulicate files (renamed)

this also might explain why MPR++ is able to do hotseat since MPR++ does not use those files

How about the relocation issue?

Remember some mods have the relocation table removed/disabled (and/or use advanced patches breaking the table).

All my test was done with vanilla with reloaction table intact. (you taught me to edit vanilla )

[Spocks-cuddly-tribble]

All my test was done with vanilla with reloaction table intact.

My question in not limited to your current problem and don't feel too safe relocating vanilla ('intact' is a great euphemism for trek.exe ver 1.0.2):

even vanilla shows increased instability if relocated from it's preferred address. Just a wild guess, but I think there is bugs in the original relocation table...