Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8-Bit Patch Codes Will Not Write 00s #2821

Closed
TallgeeseHeaven opened this issue Jul 18, 2013 · 5 comments
Closed

8-Bit Patch Codes Will Not Write 00s #2821

TallgeeseHeaven opened this issue Jul 18, 2013 · 5 comments

Comments

@TallgeeseHeaven
Copy link

What it says on the tin. Take this code for Tactics Ogre USA and EUR:

_C1 No Ninjutsu Spell Reagents Required
_L 0x8048321A 0x00130030
_L 0x10000000 0x00000000
_L 0x8048321C 0x00130060
_L 0x00000000 0x00000000

This pair of patch codes makes it so that any ninjutsu spell which requires a component will no longer require one. The first 16-bit patch code presents no issues. The problem is the second line of the second pair, which is an 8-bit patch code:

_L 0x8048321C 0x00130060
_L 0x00000000 0x00000000

What it's supposed to do is write 00 every 60h starting from address 048321c, up to 19 addresses in succession. The addresses in question control the required number of components. However, it will not write 00. If you change the second line to this:

_L 0x00000002 0x00000000

...it will happily write 02 (the last byte of the first qword is what gets written). Same for 03, 04, and so on. It just will not write 00; it leaves the pre-existing value as-is.

16-bit patch codes happily write 0000. Only 8-bit patch codes have this issue.

@makotech222
Copy link
Contributor

It was pretty easy to see if you look at the code. Since Java allows Null variables, and c++ just sets it to zero, it was reading the second line as NULL, and skipping the mem writing.

@TallgeeseHeaven
Copy link
Author

Somehow I totally missed that line when I examined the CWCheat.cpp.

Out of curiosity, isn't your commit just setting the test to always be true, so you may as well not do the test? Or am I missing something obvious?

Also, I should point out that a 32-bit patch code can also have a valid second-line first half of 0x00000000, so you may want to edit out that test too.

@makotech222
Copy link
Contributor

Hah yeah, it is always true. The reason i left it in was because i was getting build errors using the switch statement for some reason. I have no idea why, so i just left it in.

And thanks for the notice. The others are fixed.

@TallgeeseHeaven
Copy link
Author

Maybe someone will be able to figure that build error out whenever they go code-cleaning again.

Thank you for your rapid responses!

hrydgard added a commit that referenced this issue Jul 19, 2013
@unknownbrackets
Copy link
Collaborator

Since the change was merged, I'm going to close this. If it's still not working, please comment.

-[Unknown]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants