There are a few bytes in-between all that, and four bytes at the end, but those have no obvious value, and are different between my two save games. The EAX values for offense and defense are exactly what you'd expect to find in the structure the stats in the game are two bytes in size, with defense coming right after. It's the same even when the emulator has been closed and started up again. EAX has the same value for each "type" of increase. I had the idea of checking the instructions between two different save files: one end-game, the other a fresh new game. At least I managed to pull together a structure for the player's digimon stats. I spent the whole day trying to find some sort of way to tell what's what, finally found it and you had it right in yer post EAX is the way to tell what's being increased. You can analyze assembly code to see if an identifier is being checked or assigned somewhere.You can check to see if there are any instructions that are exclusive to any other address/value inside of the data structure for the address/value that you are trying to manipulate and store the address for your filter by creating a second injection point.You can check to see if there are any instructions that are exclusive to the address/value that you are trying to manipulate and store the address for your filter by creating a second injection point.You can check the register values by attaching the debugger or setting a breakpoint to see if something can be used for your filter.You can use the structure spider to find workable strings and/or for comparative analysis.You can shift the data structure (+ or -) and/or expand its size to find something useful.You can use pointer trees inside of the data structure to find something viable.You can use a pointer address for your filter, inside of your script, for the value that you are trying to manipulate.Other methods used for finding a reliable ID for filtering purposes: Complete the last step of the CE tutorial that covers data structure dissection to see an example of what I am talking about. Hooking is actually your best bet, usually, in such cases.but you'll need to find proper identifiers to filter out what you want to manipulate while letting all other values remain untouched. Usually, a reliable identifier is being stored in eax or edx in the above example. Typically, with emulators, you'll see instructions like this that are handling most things: If anyone else wants to see what's what, I've uploaded the table to Mediafire, as well as the rom and it's hash. How the hell do I then make cheats? I've read about this thing called Gameshark, but that's a piece of hardware for the actual PS1, far as I can tell. I'm thinking that this haberdashery is caused by some JIT (whatever that is) optimization by the emulator, but that puts me in a bind. Character's digimon ages by one day? Made a care mistake? Virus meter? Yep, they are all incremented by just those two instructions. Playtime increased by one in-game day? Those two exactly the same instructions are called. The oddest part, is that those exact two mov instructions are called everywhere. Tried changing it to inc cx, which instead causes the game to flip out characters bending over, the UI being offset a bunch, sound corrupting, etc. Doesn't do a thing, and the battle counter is still the same. No biggie, so I just chuck in inc ECX after the first mov. In CheatEngine, the codelist shows ECX as the battle counter. When the player wins a fight, it is incremented by one through these instructions: The one I started with, was the "battle counter". I was faffing about in the good ol' Digimon World game, and oh lordy does it need some polishing a couple of tedious mechanics really kills the fun. Posted: Fri 8:41 am Post subject: PS1 - Xebra (Digimon World) - Reused ASM Instructions?
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |