11-26-2012, 08:34 PM
(This post was last modified: 11-26-2012, 08:58 PM by nosisab Ken Keleh.)
Just run the code with 0 and then 2 and you get the same result. By mirror I meant the cheat engine will redirect addresses beginning by 0 to that 20000000 address range.
The problem, if one does exist of course, is from the code is tempting to believe it to be a byte or at most a short, still could be a word also, I can't tell from the address alone for it is in the word boundary so it could be any of them.
If it refers to character status or item code or amount, I doubt it would be a word, if it is the EXP for instance, it probably is word indeed. Still since the first digit is originally 0 one could be lead to believe it is 0 in the original raw code also, and them it's a byte and using as word could lead to problems.
Now, that "explicit" way to define length was meant to some things in the pnach engine that were never implemented and I doubt will ever be now... and it is confuse and confusing, more yet it is not able to deal with codes with different digits there that are special codes not directly related with length alone... to those starting with any digit different from 0, 1 or 2, "extended" is the only way to go. But then, extended is good enough to simple codes as well and since it uses the original code as it is in the raw format, that first digit is never lost and no doubt about the code ever arises.
For these reasons alone, "extended" should be used for all new created pnaches or when conforming old ones... if you can't say the real nature of that digit so to have them correctly prefixed by 0, 1 or 2 as they were originally and how "extended" require, then things are already complicated.
So, extended could be defaulted ever, it is not needed at all other than to keep backward compatibility with that that could be called deprecated, by now, explicit length format. Extended gets all information it needs from the code itself, reducing the chances of user's mistakes or confusion.
PS: When I first used pnach and did not understand how it worked yet, I began using word for almost every code... and soon enough I found than when changing one status (which were byte) for a character I was erasing the adjacent ones as well. First it was not perceived because I was changing many statuses at once and then the erasure was being compensated by the following code in cascade... but the first time one the intermediate status was // (comented) and I loaded from the memcard (notice the sstate will preserve the cheat even when it is disabled) I got the unpleasant surprise of seeing, for example, the ATK being a whooping 0...
The inverse applies as well... a field that should be word and I had as short ... money if I recall correctly... it was too much money and I did not wish to cheat that much, only to have a small start advantage... and them I could not get rid of the excess money at all because I was not erasing the first (more significant) half of the field.
The problem, if one does exist of course, is from the code is tempting to believe it to be a byte or at most a short, still could be a word also, I can't tell from the address alone for it is in the word boundary so it could be any of them.
If it refers to character status or item code or amount, I doubt it would be a word, if it is the EXP for instance, it probably is word indeed. Still since the first digit is originally 0 one could be lead to believe it is 0 in the original raw code also, and them it's a byte and using as word could lead to problems.
Now, that "explicit" way to define length was meant to some things in the pnach engine that were never implemented and I doubt will ever be now... and it is confuse and confusing, more yet it is not able to deal with codes with different digits there that are special codes not directly related with length alone... to those starting with any digit different from 0, 1 or 2, "extended" is the only way to go. But then, extended is good enough to simple codes as well and since it uses the original code as it is in the raw format, that first digit is never lost and no doubt about the code ever arises.
For these reasons alone, "extended" should be used for all new created pnaches or when conforming old ones... if you can't say the real nature of that digit so to have them correctly prefixed by 0, 1 or 2 as they were originally and how "extended" require, then things are already complicated.
So, extended could be defaulted ever, it is not needed at all other than to keep backward compatibility with that that could be called deprecated, by now, explicit length format. Extended gets all information it needs from the code itself, reducing the chances of user's mistakes or confusion.
PS: When I first used pnach and did not understand how it worked yet, I began using word for almost every code... and soon enough I found than when changing one status (which were byte) for a character I was erasing the adjacent ones as well. First it was not perceived because I was changing many statuses at once and then the erasure was being compensated by the following code in cascade... but the first time one the intermediate status was // (comented) and I loaded from the memcard (notice the sstate will preserve the cheat even when it is disabled) I got the unpleasant surprise of seeing, for example, the ATK being a whooping 0...
The inverse applies as well... a field that should be word and I had as short ... money if I recall correctly... it was too much money and I did not wish to cheat that much, only to have a small start advantage... and them I could not get rid of the excess money at all because I was not erasing the first (more significant) half of the field.
Imagination is where we are truly real