Quick Modding/Hacking Answers Thread

I believe the sets of code for each NPC are pretty close to each other so if you change the length of an NPC's code it will likely overwrite part of the next NPC's code.

 

If you offset an NPC, and the asm coding takes up more space than the original, does it overwrite the next NPC as well?

If you rewrite an NPC's AI function, and the new function is longer (in bytes, not commands) than the old function, then yes, it'll overwrite into whichever function is next (which is likely the next NPC), since you're trying to put a longer function into a smaller space.

 

If you rewrite an NPC's AI function, and the new function is longer (in bytes, not commands) than the old function, then yes, it'll overwrite into whichever function is next (which is likely the next NPC), since you're trying to put a longer function into a smaller space.

What if I put some code for the the said AI function in a completely different(and empty) part of the exe, and CALL to it during the NPC code? Then Retn it and it wouldn't take up any more space in the NPC code area?

Spoiler

Wait, f*ck, don't local variables, like not stay during a CALL function or something like that?

 

What if I put some code for the the said AI function in a completely different(and empty) part of the exe, and CALL to it during the NPC code? Then Retn it and it wouldn't take up any more space in the NPC code area?

Spoiler

Wait, f*ck, don't local variables, like not stay during a CALL function or something like that?

Calling another function will "mess up your local variables" if you set it up right, yes. Basically the function you called will/should no longer have access to the local variables from the function you are calling from. But instead of calling, you can just JMP to your code in the unused space elsewhere in the .exe, which would mean that you're never leaving the scope of the function you're in and could use the local variables. You'll want to be sure to JMP back to the end of the function at the end.

 

Calling another function will "mess up your local variables" if you set it up right, yes. Basically the function you called will/should no longer have access to the local variables from the function you are calling from. But instead of calling, you can just JMP to your code in the unused space elsewhere in the .exe, which would mean that you're never leaving the scope of the function you're in and could use the local variables. You'll want to be sure to JMP back to the end of the function at the end.

Wait, so now i'm confused.
If you could just JMP back and forth, what would CALL and RETN be good for?

 

because there are some benefits that come with not having to worry about having conflicts over local variables with every other block of code that could call a function. The rest is left as an exercise to the reader.

 

Wait, so now i'm confused.
If you could just JMP back and forth, what would CALL and RETN be good for?

To play nicely with the stack, i.e. so that the functions you are calling DON'T touch/mess up your local variables.

It's also so that you can call a function and it'll know to return to where it's called from, whereas if you JMP back and forth, the code block you are JMPing to can only JMP back to one spot. So the function can easily be called from multiple spots.

 

To play nicely with the stack, i.e. so that the functions you are calling DON'T touch/mess up your local variables.

It's also so that you can call a function and it'll know to return to where it's called from, whereas if you JMP back and forth, the code block you are JMPing to can only JMP back to one spot. So the function can easily be called from multiple spots.

This information would be really useful to me if I could FIGURE OUT MY ISSUE WITH OLLY.

By the way F_Link, I couldn't open up the other debugger because of the 7-zip format. Cause, parental controls.

Anyone got another disassembler I could possibly use?

 

parental controls.

I hate to be the bearer of bad news, but I think that those parental controls *might* have to do with your olly problems. Maybe.

 

I hate to be the bearer of bad news, but I think that those parental controls *might* have to do with your olly problems. Maybe.

Yeaaah, it always gives me a message when I open up olly saying "you do not have administrator privlages".

But my issue is that it crashes when I try to save my changes to the executable. So why would parental controls mess that up instead of just preventing me from opening up olly at all?

 

one is a "read" event and one is a "write" event

 

one is a "read" event and one is a "write" event

Shit, does that mean that other disassemblers would have the same issue?

Guess I can't really get into assembly until I get my own computer...

Spoiler

F*ck it, i'll just become a master of TSC with little knowledge of assembly, like enlightened.

Spoiler

So parental controls apparently blocks it, but on my schools computers, it just lets me do it without any issues???

 

just ask your parents if you can install an assembler and prompt for them to put in the password for you.

It's not that hard.

 

If you rewrite an NPC's AI function, and the new function is longer (in bytes, not commands) than the old function, then yes, it'll overwrite into whichever function is next (which is likely the next NPC), since you're trying to put a longer function into a smaller space.

FUUUUUUUUUUUUUUUUU
NOW I HAVE TO GO BACK AND TRY TO RECOPY THE ENTIRE TABLE BACK

I had thought it would recognise that and automatically make more space in the exe (like increasing the size of the exe)
Or something like that...
BTW is there a better way of copying data instead of just typing it in?

Also if someone could tell me a place in the exe with loads of free space, that would help, because I'm kinda desperate for space now...
Would places like 493874 ~ 493C3B work? Since they look really plain to me... Would they work as 'free space?'

What about 49A7C0 ~ 4BEFFE? Since that looks like simply a ton of ADD BYTE PTR DS:[EAX],AL

And one more thing.

Why is there always some DB 00, DB 01 etc and things like INT 3 between NPC offsets?

 

Is there seriously no way to make the executable bigger?
Surely there's some kind of program that can do that.

Yeah, 1.5 MB is nothing; even ollydbg takes over 2 MB in space!


I'm still wondering if 499B3E ~ 4BEFFE is free space, or is that the place Cave Story stores in-game values?

 

If you highlight whatever code you want to copy, you can right click, and in one of the menus that shows up there should be an option to "binary copy". This will store the code you highlighted to your clipboard as the hex values of that code. After doing this, you can highlight another selection of code (or empty space) and do a binary paste to paste the code to that spot. This will screw up JMP and CALL commands, as Olly tries to find the relative equivalent for where the JMP or CALL used to go. For example if in the original code the JMP jumped from
424EAA to 424EAF and you moved that command to 424E00, the new JMP would try to jump to 424E05 instead of 424EAF.

I believe the section at the very end of the executable is free space for extra code. 48B905 is where I usually start coding new stuff though there's not a ton of room.

 

Is there seriously no way to make the executable bigger?
Surely there's some kind of program that can do that.

Inserting space into the middle of the .exe would mess up a lot of CALL statements, and maybe some JMPs (if you had some custom code). And also I think you would have to edit the exe's header, to let it know that the "code" part of the executable is bigger.

But fixing all those CALL statements might not be a trivial task. Executables were not exactly designed to be easily edited after they're compiled from their source code.

 

Yeah, I'm sorta desperate for a large amount of free space, and I don't want to keep putting JMPs after every tiny bit of space.

Also why does everyone only read half my posts?

 

How does one separate the "take damage function" and the "lose exp function"?

I want to make it so that you don't lose exp when you take damage.

 

because maybe at one point in the game he would either need the PC to take damage or have them lose EXP.