Funnily enough, I just found out why it just doesn't connect & how compatibility mode has helped for some people.
Believe it or not, it's creating each connection too fast. I assume running AI server in compatibility mode (usually) slows it down enough to operate, however - unfortunately this is not always the case.
Amusingly, running it in a debugger helped me to establish this. Me stepping through code made it take more than long enough to connect. I was expecting a random exception, instead, each socket connected successfully. -_-
So, here's the two patches to slow it down (one for 1.310/1.351(2.0), one for 1.298). They're for EBENEZER.
1.310/1.351(2.0)- ; Patch over the end of the loop code, so that we jump to a code-cave
- 00415CA4 E9 69C70E00 JMP 00502412
- ; Sleep for 100ms (figured it was reasonable, only 10 connections anyway - that's 1s for the total load time. Didn't want to risk it being too fast, i.e. 10ms).
- 00502412 6A 64 PUSH 64
- 00502414 FF15 08335000 CALL DWORD PTR DS:[503308] ; kernel32.Sleep
- ; Here's our loop code back again
- 0050241A 83FF 0A CMP EDI,0A
- 0050241D ^0F8C 7238F1FF JL 00415C95
- ; Since we're in the wrong spot, we can't follow on as the loop did, we have to jump back to the 'right spot' :P
- 00502423 ^E9 8138F1FF JMP 00415CA9
; Patch over the end of loop code, so that we jump to a code-cave- 0041E08E . 7C 19 JL SHORT 0041E0A9
- ; Initiate cleanup carp - make sure everything stays intact (1.298 seems to cause more havoc than 1.310)
- 0041E0A9 > 60 PUSHAD
- 0041E0AA . 9C PUSHFD
- ; Sleep for 100ms
- 0041E0AB . 6A 64 PUSH 64 ; /Timeout = 100. ms
- 0041E0AD . FF15 1C996800 CALL DWORD PTR DS:[68991C] ; \Sleep
- ; Now revert carp.
- 0041E0B3 . 9D POPFD
- 0041E0B4 . 61 POPAD
- ; Back to the loop!
- 0041E0B5 .^EB C5 JMP SHORT 0041E07C
|
