ROM Hack ASM Hacking | Overlay not loading in game when changing more than 1 byte in the overlay.

[bananabread]

Hi, I'm currently working on trying to do ASM Hacking on a game, Professor Layton and Pandora's box to be exact. I've been trying hard to get this to work. The NSMBE ASM Patcher didn't work, so I wrote my own in python with the use of the ndspy library, and I so far have been able to do hooks in arm9.bin, but since most of the interesting code is put in the overlays, I was working on being able to hook to overlays.
The thing is though, whenever I try to modify the uncompressed overlay. When I change more than 2 bytes, wherever in the file, it fails to load the overlay in game. I can change 1 byte fine, but 2 and it fails.
I was wondering if any of you know why this might occur and how I could fix it, or redirect me to someone who does.

 

[FAST6191]

I am assuming this is in place rather than expanding or reducing the size.

If it had been any changes then we would start looking for some kind of hashing anti piracy check but a single byte working but not two is odd. Hopefully any changes made are valid ones and it is not a problem of the edit itself rather than the methods employed.
You say uncompressed -- are these not overlays that are not compressed in the original ROM? If they are compressed and you are compressing them again (I have never been a great fan of changing the "is compressed" flag) then just to make sure you are using the DS binary compression (in cue's tools it is the blz compression option).

 

[bananabread]

I don't think the issue is compression. I've tested that what I'm editing isn't compressed and the overlays are compressed standard. Also the overlays won't load at all if their not compressed. The changes I made when the hooks didn't work was to first just adjust 1 byte, then adjust another. Both worked fine. Then changed both and the overlay just stopped working. The 2 bytes changed are also far apart so it isn't like I'm making a huge change to some value.

 

[bananabread]

Well, until I figure this out, I will try to implement something to setup the hooks in the overlays while the game is running. My current plan is to change the value at the address when the overlay gets loaded in or branches to the first function I can hook to.

 

[FAST6191]

"I've tested that what I'm editing isn't compressed and the overlays are compressed standard"

So that means the overlays are compressed but the byte you are changing is as it would be in the uncompressed/in memory version? That might be so but the way LZ works means it could well reference that byte later in decompression and at that point you have just propagated an error.

 

[bananabread]

No the whole overlay is decompressed.