View Profile
View Forum Posts
Reply With Quote
I'm not in a position to try it now, but if it works- awesome job!
I'm releasing a "wrapper" .dll for System Shock 2 that converts the old DirectPlay 4 calls that are made for the game's multiplayer support into DirectPlay 8 ones, thereby making multiplayer playable under Windows Vista and eliminating the need to use Hamachi to connect to a host that is behind a router. Stability and latency should also be improved under DirectPlay 8. It can be downloaded from here.
Installation instructions:
1. Copy the files from the .zip into your System Shock 2 directory, making backups where appropriate if you'd like.
2. If you are hosting a game and are behind a router, you may need to forward port 5198 in order for others to connect to you.
3. That's it. The game will automatically load the wrapper .dll at startup, and connecting to or hosting multiplayer games should be much easier than it was before.
Known issues:
- IP addresses are not displayed in the game staging screen for any player other than the host, and the host's internal network IP address will probably be displayed rather than their external one. This will probably not be fixed, since it's a fairly small issue.
I'm not in a position to try it now, but if it works- awesome job!
Just tried this twice with TF, it crashed near the start of Medsci1 in both cases.
The first time, we had the ureleased version of SecMod installed, and got this error after climbing up the ladder right at the start:
After that, I thought maybe the mod could be the cause of the crash, so we tried again with a vanilla install, and got another crash in roughly the same place. I forgot to copy the memory address, but this time it was a read operation and not a write operation that failed.Code:--------------------------- Shock2.exe - Application Error --------------------------- The instruction at "0x20b0b62b" referenced memory at "0x00000008". The memory could not be "written". Click on OK to terminate the program Click on CANCEL to debug the program --------------------------- OK Cancel ---------------------------
Wow! Thanks, Tos!.
Hmm, apparently you didn't apply this fix over shock2.exe included in Kolya's SS2-Tool-v2.4. If I remember correctly it's based on bobruck's Texture Memory-fixed .exe and it includes Displacer's HD Space-fix (Kolya, can you confirm this?).
So, if you can make some sort of binary patch which includes your fix against this shock2.exe, it would be superb job!
Hmm. vort and I were able to play through a couple levels past MedSci2 with no issues last night. I did make a few changes since we ran through those levels and only tested it again briefly, so it's definitely possible that I made a mistake somewhere. I just tried to get that to happen on my LAN however, and was able to get all the way up to the upgrade machines on MedSci1 with no issues.Originally Posted by Nameless Voice
If you can connect to each other without the patch, do you have the same crash there? If not, can you tell me exactly how to reproduce the error if you can get it to happen again? I can't tell what's going on from that error report exactly since it looks like it tried to access memory outside of the game (and probably my DLL too).
Wouldn't be difficult to make a patcher. If you can direct me to it though, I'll look into replacing it with that.Wow! Thanks, Tos!.
Hmm, apparently you didn't apply this fix over shock2.exe included in Kolya's SS2-Tool-v2.4. If I remember correctly it's based on bobruck's Texture Memory-fixed .exe and it includes Displacer's HD Space-fix (Kolya, can you confirm this?).
So, if you can make some sort of binary patch which includes your fix against this shock2.exe, it would be superb job!
Tos, you can download Kolya's SS2-Tool from here: http://www.strangebedfellows.de/inde...pic,392.0.html.
We can connect through Hamachi, yes. We did some testing of SecMod in multiplayer recently, and it didn't crash. I haven't tried playing vanilla SS2 multiplayer is some time, however.
I didn't do anything special. I grabbed the wrench, smashed the conduit, climbed up the ladder, and it crashed in the corridor beyond. I wasn't hosting.
Yes, it sounds like an access violation. Those would be easier to track if you made a version of ShockEd with this patch applied (having a version of ShockEd with this patch would be useful anyway). I suggest using the ShockEd Toolkit version of the editor if you want to try patching one.
I might try testing it again tomorrow.
Very strange. I've repeated that exact sequence of events several times (as a client even) and haven't gotten a single crash. I'm not ruling out the wrapper as being the cause of the problem, but could you try it with a clean installation of SS2?
I'm not sure why it would be easier to track in ShockEd -- perhaps because of the errorlog.txt that the game writes to when it crashes? I actually wrote something for Thief that logs crashes to errorlog.txt in the same way that Dromed does, and stupidly forgot to include it in the .dll for SS2. I can upload a new version with that included, if it'd help.
Normally I wouldn't even ask, but since you've done some works on scripts, would you happen to have a JIT debugger installed (such as OllyDbg)? That would make tracking this down fairly trivial, but if not the errorlog.txt should suffice.
Making a version for ShockEd should be simple. I will have to compile a new .dll though since some addresses are different. (I was under the impression that the only version of ShockEd released to the public was one built before the multiplayer patch was released though, does MP actually work properly in it?)
It sounds like the changes that you mentioned are actually just changes to the .cfg files from what I see in that post -- aside from the multi-core fix, which has already been applied. They should still work with this.
That might be an idea. The install that I was using the second time was "clean" as far as I know. It had some extra assets, but no custom mission or gamesys files.
Partly because of its monolog crash dump, and partly because I have some debug information regarding function addresses for it somewhere...
I'm not particularly well-versed with debuggers, but I do have MSVC and GDB handy. I could try running the game through either.
I'm not completely certain as to the history of ShockEd, but I know that the version which we have definitely has fully functional multiplayer support. The ShockEd Toolkit version that I linked to is just the released version with a few fan-made patches applied to it (mostly made by Telliamed).
I've updated the .zip linked to in the first post with the new .dll that records crash information to errorlog.txt. Since I can't seem to reproduce this bug on my end, if you could get it to crash again and either upload the file somewhere or copy the address that ShockWrapper.dll was loaded to and the stack dump here, that'd be helpful.
I'm not really too familiar with either, but if they're capable of showing a call stack (or any sort of history of function calls) that'd be the thing to look at when it crashes. If there was a call to something in ShockWrapper.dll shortly before it crashed, something in my code is probably at fault.
Wow
Okay, I'm not sure what to make of this.
I suspect you missed something with regards to forwarding ports. I forwarded port 5198 in both TCP and UDP, but I can't connect to that port, even a port scanner tells me that it's closed when I'm hosting a game after turning off my firewall.
My firewall, when active, will say that the game is listening on port 5198, though, alongside a host of other ports.
So, we tried it over Hamachi instead - using the helper DLL - and that seemed to work fine, at least for the start of Medsci. I'll report back with more later.
Edit: I should probably try to find someone else to test this with...
Last edited by Nameless Voice; 8th Jun 2008 at 21:48.
Just double-checked and 5198 is the only port that needs to be forwarded to my computer in order for vort to connect to my game and play without Hamachi. I don't need to have any ports forwarded in order to connect to him. It's possible that the other ports you're seeing are a hold-over from DirectPlay 4 -- I believe the game still attempts to start a DirectPlay 4 lobby (for what purpose I'm not sure), but it does nothing.
So, it's no longer crashing on MedSci? Very odd. If you're still not having any luck, I could try hosting a game and having you connect or vice versa.
I just got confirmation from Kolya that sshock2.exe distributed with SS2Tool indeed does include Displacer's HD space fix and that HyperThread/Multicore fix but not bobruck's fix.
So, it would be still nice if you can make that patcher for this .exe.
Can I reinforce The Brain's request by posting the to-be-patched exe from the SS2 Tool?
I've uploaded a new .zip with a modified version of Kolya's .exe included instead, at the same link.
Hopefully someone else will let me know how this works for them. I'm still mystified by the problems Nameless Voice encountered and have not been able to reproduce them on my end.
Am I right in assuming this wont work with ddfix?
I have an XP laptop and a Vista desktop, both with the wrapper installed.
Whole process is stuck at "Joining Game...", doesnt matter which I use to host.
There's no reason why it wouldn't. I'm not sure if the process has changed in the newer versions of ddfix, but all you should need is a hex editor.
As for the joining game issue, did the host of the server you were connecting to at the time actually have the game window focused? Not doing so will result in clients getting stuck on "Joining Game..." until the game is focused again. If that still doesn't resolve it, I'd try it again without the wrapper just to verify that that's the cause of your problems.
Bravo on this patch, I wasn't able to get Shock2 Multi working between two machines (one XP, one Vista), but when I installed this patch on both machines, it works like a charm! (on a LAN, haven't tried via Internet yet).
Is it possible to tell me how exactly you created this wrapper? Did you physically alter the shock2.exe file or is your patch just the other two files in the zip? (the shockwrapper.dll and ini files)
Glad to hear it worked for you!
The .exe was only altered enough to load the wrapper .dll at startup. All of the real changes are contained in the .dll. The .dll itself works by intercepting the game's calls to DirectPlay4 interfaces and then redirecting them to equivalent DirectPlay8 functions (if there is one, if not they're simply disabled).
Thanks for the info -- so you took the original shock.exe and replaced all instances of directplay4 calls to look at your .dll file instead?
The new .exe only loads the wrapper DLL. Once the DLL has started up, it redirects the game's CoCreateInstance import to my own code, and passes a new DirectPlay4 object to the real CoCreateInstance function that is created by my hook. This allows me to intercept all of the old DirectPlay 4 calls and redirect them as necessary to the newer ones (or simply drop them, if there's no equivalent or they're no longer necessary).
I don't like it when people leave my without any help!
I applied this fix and now that I try to host a game, it crashes to desktop. But if I try from another computer it hosts just fine, but I can't join because it gets stuck on Joining Game....
It says in the CMD window "Failed to enumerate hosts" And "Failed to create local player"
DDFix and all other possible thing there has been in the guides. HELP!
DirectPlay 4 couldn't work behind routers. The ports it uses are dynamic, even for server/hosts (where it should be static).
I guess writing a generic DirectPlay Hook/Wrapper is possible, to force the server/host ports to be fixed.
Visit Homepage
