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.

Pnach has that complex notation because was expected it to provide extended functionality from start.

For example, if I do recall correctly, patch=0 would be used when the code was to be used once and only once in a game session, but the actual implementation of that feature proved to be complicated and to date I have not seen it being used yet and the attempts made to use it crashed with problems like the cheat being applied "before" an actual save was loaded and then lost, among other issues.

The EE there I can't say for sure what's the reason for it, maybe the pnach developer wanted to provide facility to patch other areas as well, like VU, for example. the "explicit" parameter is another feature that didn't get appropriated treatment.

Then, in practice all those parameters could be just defaulted in the nowadays pnach engine so it could take only the two strings for the address offset and the value and work directly with them as they are (provided they are raw, of course).

Ok, so in short, there's no need to convert the old codes to new because the cheat engine mirrors the "old" address to the new address.

Well, that's solved then.

(11-26-2012 02:32 PM)dharthoorn Wrote:  Are you planning on adding functionality for that in one of your apps or can you advise me another safe & efficient way to do it?

Actually such feature can be useful because codes maded by using the byte,short,word system are not always compatible with extended.

For example you have this code
patch=1,EE,205CD208,byte,00000078
or
patch=1,EE,205CD208,short,00000078
or
patch=1,EE,005CD208,short,00000078
or
patch=1,EE,005CD208,word,00000078
...all will be wrong when converted to extended without changing the first digit of the address

Since my converter have the ability to remove the pnach formatting by just removing patch=1,EE, and replace byte,short,word,extended with space,it will make the code not to work correctly when converted again but this time to extended mode.

Since the "ToRAW" button don't do anything about the first digit of the address,this will convert the code like this
patch=1,EE,205CD208,extended,00000078
which is wrong(if the type was byte or short before)...this will not modify only one address like when you use byte(or two if it was short)but it will modify 4 addresses because 2 means "modify 4 addresses"

So all be adding this feature(it's actually done)

I also have some other fixes on the converter but I'm not sure if the changes are good enough for new version.

PS.My app is only Multi Converter,the other programs are not mine,they just act as helpers for Multi Converter

Thanks for your reply

So, the 2 at the start of the address seems to indicate a 4-byte write in the extended syntax. Is there no byte or 2-byte notation in the extended syntax format?

So far, I don't see any advantages using this extended notation so why even bother at all. If there is an 8-byte notation it could be useful in case of many sequential 4-byte writes but otherwise... Or am I missing sth important?

1 byte with extended,the first digit of the address has to be changed to 0
2 bytes with extended,the first digit of the address has to be changed to 1
4 bytes with extended,the first digit of the address has to be changed to 2

Think of it like this:
Either change the fist digit of the address to the correct digit depending on the value while using extended
Or write the value type of the cheat

It won't save you the trouble of adding the correct digit\word in both cases but raw codes from internet(or encrypted and then decrypted)have the correct type(the first digit of the address)for the extended mode.

In the byte,short,word mode,you have to type the correct word.

PS.There is no 8byte write,max is 4
You can condense the codes...for example
40000000 00040001
00000000 00000000

aaaaaaaa bbbbcccc
dddddddd eeeeeeee

a - starting address
b - code lines in hex
c - address increment...if it says 2 I have to multiply it by 4 and convert the end result to hex
d - starting address value
e - value increment

This will set 0 to all addresses from 200000000 to 2000000C

Edit:It looks like it's a lot more complicated that I thought(converting byte,short,word codes to raw and then to correct extended)

ty for tool after i found it. It made code's lot faster to make

(11-30-2012 11:35 AM)dharthoorn Wrote:  Thanks for your reply

So, the 2 at the start of the address seems to indicate a 4-byte write in the extended syntax. Is there no byte or 2-byte notation in the extended syntax format?

So far, I don't see any advantages using this extended notation so why even bother at all. If there is an 8-byte notation it could be useful in case of many sequential 4-byte writes but otherwise... Or am I missing sth important?

You are missing important things indeed. The "extended" is not just a name, for simple codes which starts with 0, 1 or 2 (in the original code and meaning they are byte, short or word) you "need" to change the code so it starts with 0 or 2 when using the explicit convention.

...but, many cheats use more complex codes, sometimes covering more than one line, and to these you are forced to use "extended" for it extends the support to some special codes starting with values greater than 2. Even then pnach does not cover all the special codes and usages possibles with the original cheater device, but is already something.

PS: Actually, just by the need to "correct" some the codes so to use with the "extended", what means making them like they were originally, should be enough to tell the advantages of using "extended" from start. You don't need to change already working codes to extended format, of course, still if wanting to use "normalized" utilities the codes are already "wrong" for the utility will try and use the first digit as the code type descriptor.

To make things worse, many users did not understand the importance of field length and randomically changed everything to start with 0 or 2 and repeated "word" for all them, despite what they were initially, or put everything as byte... and so on, making almost impossible to know what the code actually is in some cases you can't tell it by the value alone.

@vsub: Some codes aren't just extending the field range, they are conditional. Well, that's the extent I know about them also, I know they exist but not really analyzed what they do. Special usages in the master code and jokers aren't implemented in pnach by what I know, for example.

Multipliers are one these special cases using bitmask (or flags) where the bits in the field are seen as on/off instead the field indicating actual value, or used as "shift parameter" what actually is like multiplying by two to each shift to left.

sir how can i make cheats codes for my Wild Arms 5 game....i also use yor multi converter but it didn't work.....i follow your steps that you mention in your article....

What codes are you placing in the converter(before converting them)

PS.The program don't MAKE codes,it just convert(if needed)them to raw and create a pnach file