Why does the Cheat doesnt work?
#11
(01-04-2013, 01:21 AM)Riot621 Wrote: Those codes need to start with "2" instead of "0".

No, the values for 0, 1 and 2 used with "extended" are what tells the values are "byte, short or word" and then shall never be changed as was necessary when using those (now deprecated) tokens.

PS: Actually this kind of misunderstanding of the codes function and values length was and still is cause of many cheats issues in pnach files. And the main argument toward always using "extended" from now on. With "extended" the codes are used as they come (provided they are raw) without the need of changing them (actually they shall never be changed anymore).
Imagination is where we are truly real
Reply

Sponsored links

#12
Run a memory viewer such as Cheat Engine and load those addresses, and then load them with a leading 2 instead. If you use ps2dis to view the elf file (which is where the instructions for most codes originate, unless you're directly replacing a value such as HP, MP, SP, etc.) you'll find that the program counter for the instruction you're replacing (or the target address for the value you're writing) in the ELF file may start with a 000xxxxx, but if you view the memory using cheat engine, those values are exist in the memory beginning with a 2. This has been true for all the codes I've hacked myself so far.

On code devices, 0,1,2 were used to designate constant-writes of 8-,16-, or 32-bit values. In PCSX2, "D" commands still apply as a working test command for joker codes and such. I still stick to this format out of habit and because it usually works, but also because I try to stick to the same values that CE shows. In any case, it's worth a shot to change the leading digit and see if it works afterwards.

EDIT: I tested a code without the leading 2, and I stand corrected as far as its effect. CE still leads the address with 2, but it does re-write the value correctly using 0's in the pnach file. Sorry for the confusion on my part. Still, if a code isn't working, I'd check to see what's happening at that address via CE.
Reply
#13
(01-06-2013, 11:29 AM)Riot621 Wrote: Run a memory viewer such as Cheat Engine and load those addresses, and then load them with a leading 2 instead. If you use ps2dis to view the elf file (which is where the instructions for most codes originate, unless you're directly replacing a value such as HP, MP, SP, etc.) you'll find that the program counter for the instruction you're replacing (or the target address for the value you're writing) in the ELF file may start with a 000xxxxx, but if you view the memory using cheat engine, those values are exist in the memory beginning with a 2. This has been true for all the codes I've hacked myself so far.

On code devices, 0,1,2 were used to designate constant-writes of 8-,16-, or 32-bit values. In PCSX2, "D" commands still apply as a working test command for joker codes and such. I still stick to this format out of habit and because it usually works, but also because I try to stick to the same values that CE shows. In any case, it's worth a shot to change the leading digit and see if it works afterwards.

EDIT: I tested a code without the leading 2, and I stand corrected as far as its effect. CE still leads the address with 2, but it does re-write the value correctly using 0's in the pnach file. Sorry for the confusion on my part. Still, if a code isn't working, I'd check to see what's happening at that address via CE.

I didn't meant to be personal, you'd be right if the codes used the old byte, short or word format because in them the address offset is taken liiterally (although it still mirrors address offsets starting with digit 0 to the correct address offset started with 2).

But that is not valid for extended for it automatically prefix all adrresses to start by digit 2 all the while using that digit in the code to indicate the code's type as originally intended.

What I pointed out was the former method (using byte, short, word) were cause of mistakes and since the original code needed to be changed (as you pointed out), later on could be hard to be sure about the value's length on the cases it could not be identified by significant digits in the value content itself.

For example a value of 00000000 is not the same thing if byte, short or word. If is a byte only the last byte (the last 00) is poked into the memory leaving all adjacents bytes untouched.

If is a short, half those bytes are pocked into the memory (0000) what could be problematic if the code was intended to be a byte for it would be erasing a not intended address value.

Things could be worsen yet if a code is defined as word for all those 00000000 are indeed pushed into the memory erasing 3 more bytes than expected.

The contrary could happen also although not so prone to cause corruption but returning wrong results. For example if a code was originally a word and is defined as a byte, then only the last part is actually erased, a common sittuation for "money", and in this case if the user is trying to reduce the amount of money the cheat could fail for not all money is erased...

The combination of all possibles cases make that explicit usage confusing and error prone, hence "extended" should be used from now on and the original code never being changed.

Edit: Is to be noted that this reply is to help those starting in cheat codes to understand how that pair address and value works, yourself proved to know it already.
Imagination is where we are truly real
Reply




Users browsing this thread: 1 Guest(s)