Nyerguds 100 Posted January 14, 2009 (edited) bizarre... I tried it out, and it worked fine on my system. You could try this one... it's safer beause it just changes a conditional jump to an unconditional jump, but doesn't mess with how far the jump goes. E10BF: 7D EB This just makes it exit the allying check loop just after entering it. Edited January 14, 2009 by Nyerguds Share this post Link to post
Rich Nagel 0 Posted January 14, 2009 (edited) bizarre... I tried it out, and it worked fine on my system. You could try this one... it's safer beause it just changes a conditional jump to an unconditional jump, but doesn't mess with how far the jump goes. E10BF: 7D EB This just makes it exit the allying check loop just after entering it. Strange, same problem... this one locks up as well. FYI, just to remove any 'variables' from my testing, I've been testing it with a freshly installed copy of C&C that requires the CD in the CD-ROM drive, without the utility (that I normally use) "C&Cheat" installed, 'No sound' for the sound driver, and none of the other addons and other such stuff installed. BTW, (needless to say) the game actually starts up, but the lock up occurs when a network multiplayer game would actually start. NudNud, come on, your braking the poor guys game Hehe, with all of the most excellent things that Nyerguds has done for my game, he is more than welcome to break it as much as he wishes, at his whim <G> :) Edited January 14, 2009 by Rich Nagel Share this post Link to post
Nyerguds 100 Posted January 15, 2009 (edited) You could also try just NOPing out the actual allying command... that'd be E10FD: 50 90 E10FE: 57 90 E10FF: E8 90 E1100: 68 90 E1101: 2A 90 E1102: F9 90 E1103: FF 90 I can't see how any of this could cause any problems, mind you... are you sure you waited long enough? Edited January 15, 2009 by Nyerguds Share this post Link to post
Rich Nagel 0 Posted January 15, 2009 (edited) You could also try just NOPing out the actual allying command... that'd be E10FD: 50 90 E10FE: 57 90 E10FF: E8 90 E1100: 68 90 E1101: 2A 90 E1102: F9 90 E1103: FF 90 That one worked PERFECTLY, Nyerguds, MANY THANKS! BTW, by 'NOPing out the actual allying command' did you mean that would completely remove the allying feature? Although the enemies weren't allied (hehe, funny to see them have a 'swing' at each other <G>), I was still able to 'ally' with them (of course, the sentiment of the enemies wasn't mutual <G>). I can't see how any of this could cause any problems, mind you... are you sure you waited long enough? Yep, C&C was locked up hard as a rock. No biggie though, as I simply ALT+TABbed back to WinDoZe and teminated the DOS shell. When I was using the C&Cheat utility though, it crashes back to DOS with an error message (no lock up), with the standard DOS4GW memory-address crash-type info (a feature of C&Cheat, to provide info to the original author; if his utility was causing the problem or not). (Edit) Dunno if this will help or not, but here's the C&Cheat crash info (using the 'E10BF: 7D EB' hex-edit): DOS prompt error message: -=-=-=-=-=-=-=-=-=- C&C just crashed. If you believe that this crash was a result of a bug in C&Cheat, please run C&CHEAT.EXE immediately and fill out a bug report to notify the author of the problem. Thank you for your help. -=-=-=-=-=-=-=-=-=- Contents of CRASH.RPT: -=-=-=-=-=-=-=-=-=- DOS/4GW Professional error (2001): exception 0Eh (page fault) at 20F:84C2D783 TSF32: prev_tsf32 6B14 SS 217 DS 217 ES 217 FS 0 GS 28F EAX 8 EBX 7 ECX 6 EDX 8 ESI 8 EDI 84CDF929 EBP ED84C92D ESP 84C92C55 CS:IP 20F:84C2D783 ID 0E COD 6 FLG 10282 CS= 20F, USE32, page granular, limit FFFFFFFF, base 0, acc CFFB SS= 217, USE32, page granular, limit FFFFFFFF, base 0, acc CFF3 DS= 217, USE32, page granular, limit FFFFFFFF, base 0, acc CFF3 ES= 217, USE32, page granular, limit FFFFFFFF, base 0, acc CFF3 FS= 0, USE16, byte granular, limit 0, base 0, acc 0 GS= 28F, USE32, byte granular, limit 6144, base 85497000, acc 40F3 CR0: unavailable Crash address (unrelocated) = 1:0007B783 -=-=-=-=-=-=-=-=-=- Edited January 15, 2009 by Rich Nagel Share this post Link to post
Nyerguds 100 Posted January 16, 2009 (edited) That one worked PERFECTLY, Nyerguds, MANY THANKS! BTW, by 'NOPing out the actual allying command' did you mean that would completely remove the allying feature? Although the enemies weren't allied (hehe, funny to see them have a 'swing' at each other <G>), I was still able to 'ally' with them (of course, the sentiment of the enemies wasn't mutual <G>). Ah sorry, hacker speech. No, all I did was replace the code that called the allying function at that point by "NOP" (No Operation) commands (which are byte 90) so the call to the command is effectively removed from that piece of code. The actual allying function isn't touched. If that works, then maybe this simpler hack could do the trick too: E10F5: 75 EB This also lets it run through the entire loop correctly, but cuts the internal loop (to ally one detected AI player with all other AI players it finds) short by jumping back to the start of the loop before executing the actual allying command. This normally only happens if it detects that that side it's trying to ally to the confirmed AI side isn't an AI, but this hack forces it. Yep, C&C was locked up hard as a rock. No biggie though, as I simply ALT+TABbed back to WinDoZe and teminated the DOS shell. When I was using the C&Cheat utility though, it crashes back to DOS with an error message (no lock up), with the standard DOS4GW memory-address crash-type info (a feature of C&Cheat, to provide info to the original author; if his utility was causing the problem or not). (Edit) Dunno if this will help or not, but here's the C&Cheat crash info (using the 'E10BF: 7D EB' hex-edit): Sadly, I can't debug (or even correctly disassemble) DOS4GW applications... it's a dirty mix of a 16-bit memory manager and a 32-bit actual program. So I can't even derive from that at which point in the code it actually crashed Crash address (unrelocated) = 1:0007B783 Well I can see the crash address is 7B783 but it's hard to translate that to an actual offset. Normally the disassembler can do that for me, but with this DOS4GW mess it fails miserably. Edited January 16, 2009 by Nyerguds Share this post Link to post
Rich Nagel 0 Posted January 16, 2009 Ah sorry, hacker speech. No, all I did was replace the code that called the allying function at that point by "NOP" (No Operation) commands (which are byte 90) so the call to the command is effectively removed from that piece of code. The actual allying function isn't touched. Ahh... thanks for the info I had a hunch that 'NOP' meant 'No Operation', but I wasn't sure. If that works, then maybe this simpler hack could do the trick too: E10F5: 75 EB Nope, unfortunately that doesn't work either. Sadly, I can't debug (or even correctly disassemble) DOS4GW applications... it's a dirty mix of a 16-bit memory manager and a 32-bit actual program. So I can't even derive from that at which point in the code it actually crashed Crash address (unrelocated) = 1:0007B783 Well I can see the crash address is 7B783 but it's hard to translate that to an actual offset. Normally the disassembler can do that for me, but with this DOS4GW mess it fails miserably. I had a thought: I was thinking of using the old archaic DOS memory dumper/editor cheat utility "Game Wizard Pro", but unfortunately as I thought, C&C didn't like it much (hard lock ups when running the utility in the background with C&C). My hunch was that I could dump the memory at that address, and maybe with a bit of byte comparison, be able to determine the relevent offset in the GAME.NEW file. But alas, C&C didn't like 'sharing' with GWP <G>. Share this post Link to post
Nyerguds 100 Posted January 16, 2009 Ah, that wouldn't help either... that isn't the address in your memory, it's the relative address inside the memory reserved for the game. But that addressing doesn't start counting from zero, for some reason. Share this post Link to post