[1.298, 1.310] Ensuring AI server makes all of its (10) connections to Ebenezer
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: ; 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 00415CA91.298
; Patch over the end of loop code, so that we jump to a code-cave0041E08E . 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 1C996800CALL DWORD PTR DS: ; \Sleep
; Now revert carp.
0041E0B3 . 9D POPFD
0041E0B4 . 61 POPAD
; Back to the loop!
0041E0B5 .^EB C5 JMP SHORT 0041E07CGood luck, and have fun. :)
页:
[1]