Jump to content
Rich Nagel

New C&C TD Command Line Parameter Discovered!

Recommended Posts

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 by Nyerguds

Share this post


Link to post
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 :P

 

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 by Rich Nagel

Share this post


Link to post

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 by Nyerguds

Share this post


Link to post
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 by Rich Nagel

Share this post


Link to post
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 by Nyerguds

Share this post


Link to post
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

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

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×