Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Grandia III Codes not working.
#1
Hello There,

I can't seem to get the Quick EXP codes from codetwink to work. I used Omnitool to convert the codes from codebreaker V1 to raw but it simply does not work.
I'm not sure what I'm doing wrong so maybe you can help me.


I attached my pnach file.
Reply

Sponsored links

#2
(04-29-2013, 11:22 PM)R.D. Wrote: Hello There,

I can't seem to get the Quick EXP codes from codetwink to work. I used Omnitool to convert the codes from codebreaker V1 to raw but it simply does not work.
I'm not sure what I'm doing wrong so maybe you can help me.


I attached my pnach file.

Try this:

1 - Just change "word" to "extended" in the first block (Exp Gain)

2- Do the same for the other two blocks but use the editor to change the first byte at the address to 2. so they look like this:

//Max Hp all Characters & Infinite HP.
patch=1,EE,205B7874,extended,270F270F

Do it, although they work as they are they are already wrong because the original code was like the above with 2 instead 0 (0 would make them "byte").

Doing so now will grant the real nature of the codes is preserved without doubts. And is how new pnachs should be done always, not using the explicit length anymore.

PS: Make sure not changing the 1 at first byte for the first block, they are indeed "short" and is how the extended will interpret them.

PPS: the easiest way to change the addresses all at once is using the text editor to replace all occurrences of 005 by 205

Edit: Seriously, support to byte, short and word should be discouraged fiercely, maybe people stop using them and so stop making such a mess like in this very example.
Imagination is where we are truly real
Reply
#3
Explicit length is optional, personally i prefer it over using extended, because i can sort through the codes more easily compared to a numeral search.

Now, the valid range for codes is within 2000000-21c00000, so anything out of that will either have no effect or break something when EXTENDED is not used.
So first of all, your codes should start with 2 instead of 0 or 1 or whatever. As for the length, most games use addresses which start at even numbers, such as 0, 2, .., A, C, E. That being said, WORD addresses can be found at ranges 0-3, 4-7, 8-B, C-F or 2-5, 6-9, A-D, E-1. You will never find an address which starts from a number which isn't even; unless it is a BYTE. Those may occasionally be found more tightly packed.

Now for determining the length of the address being modified, it depends on what it is about. For EXP, you can be sure it's WORD(0-4,294,967,295). For character levels for example, it can be BYTE(0-255). For item quantities or type, it can be SHORT(0-65,535). If you are unsure what the correct length is, you can always scan the addresses ahead to see if it's safe to expand, and experiment with values.

All this supposing it is you who's trying to make some cheats. You can find pre-made ones from code-breaker or gameshark or anything, but there's no guarantee they're gonna work, even if you convert them properly. Some are just mistaken and some simply do not work without their respective program.
Reply
#4
Coornio, is even intuitive than a system prone to errors and misunderstanding, which ask to change the original code and is cause of so much problems should not be encouraged.

There is no secret, 0 is byte, 1 is short and 2 is word... besides whatever other value for that first digit forces use of extended anyway, so why not using it from start and never needing to change the digit and creating so much problems?

The idea is not protecting against wrong codes. Wrong codes can and will bring wrong results, the idea is not including errors all by ourselves into correct codes.

You are right about the addresses, just to add: short (2 bytes) starts at multiple of 2 addresses, words at multiple of 4 and double word in multiples of 8 (correcting my previous post), a compiler align them automatically or the CPU would need to do it losing performance at execution time. Byte does not have that restriction and can use any address or address offset.

The point is simple, a lot of people don't even understand what is that byte, short or word and their importance, so historically pnachs have been created where people just put word for all and every code and change the first byte to 0 or 2.

Sometimes is easy to pinpoint the error but not always. when you see a code like:

Patch=1,EE,201C0428,word,00000000

there is no secure way to say if the original was a byte a short or indeed a word and this makes a HUGE difference in how the code works. Automatic conversion is much complicated in these cases.

About the original codes found in most places, they commonly comes from official cheat engines, which try and protect their codes by encrypting and so must be reconverted to raw before being used.

That's also the case of master codes, they are special codes to instruct the engine on how to treat the following codes, they aren't codes by themselves, just the engine's proper control and is not implemented on pnach (and then must not be included in pnach files), what makes those codes starting with non common digits to either work, don't work or work inversely the expected.

That's because pnach will ignore the conditional in most these cases AFAIK and apply the code, sometimes that is the expected... just not always.

Finally, quoting your last line above: when making your own cheats, decoding correctly the code, don't you think is much better just including the result into the pnach, without needing to change any digit, avoiding errors, just by using "extended" for all types? the sheer amount of wrong pnach files reported across the time in this very forum should say by itself which method should be used.

If you want, think that old method (explicit length) was an ambitious attempt which was never really implemented and was made deprecated by "extended". To the point that

patch=1 and EE and the very word "extended" became redundancy, they could simply be removed from pnach files without problems, simply by "assuming" them as default if missing. How many people ever understood why exist a patch=1 or EE in a pnach file?

Code:
Hint

Those were from a time when pnach was meant as a patcher also and not just a cheat engine by it's own merits. So was thought the possibility to patch specific modules, as EE, VU, GS, SPU and so on... this was never really totally implemented but is still an idea and has merit.

But now the patching is separated system from pnach at all and is actually better that's so.

Patch=x was to define how the code is to be applied, for example

patch=0 still works nowadays and makes the code being applied only once instead at each frame.

The idea is good indeed but the implementation is complicated, as it is now the code is applied once as intended, just that most of times is applied at wrong time, sometimes before the game itself is loaded from memcard or sstate and then is just... lost...
Imagination is where we are truly real
Reply
#5
True, the addition of EXTENDED made all other redundant. It is however a matter of choice too. While EXTENDED does all and more than the conventional explicit length system, i still prefer it simply because it's easier for the eye to see immediately what length each cheat has. Merely a line length difference and better visibility; stupid reason, i know, but it's why i still use it.

Of course explicit length is more prone to errors with all the newbies who barely know how copy-paste works to transfer a cheat to their pnach, i'm not denying that. But removing it just because of that is a bad call. Most people new to something often make mistakes, i asked around a bit myself when i got to making cheats for my games until i learned how stuff works, it's all part of the procedure.

There are guides somewhere in the forums explaining how patches work which should be a bit more readily available. Alas, you cannot count for people who have no idea what HEX means to read that guide and make proper patches without making a topic about them not working, but we can't have it all.
Reply
#6
(04-30-2013, 01:20 PM)Coornio Wrote: True, the addition of EXTENDED made all other redundant. It is however a matter of choice too. While EXTENDED does all and more than the conventional explicit length system, i still prefer it simply because it's easier for the eye to see immediately what length each cheat has. Merely a line length difference and better visibility; stupid reason, i know, but it's why i still use it.

Of course explicit length is more prone to errors with all the newbies who barely know how copy-paste works to transfer a cheat to their pnach, i'm not denying that. But removing it just because of that is a bad call. Most people new to something often make mistakes, i asked around a bit myself when i got to making cheats for my games until i learned how stuff works, it's all part of the procedure.

There are guides somewhere in the forums explaining how patches work which should be a bit more readily available. Alas, you cannot count for people who have no idea what HEX means to read that guide and make proper patches without making a topic about them not working, but we can't have it all.
I think you didn't get my meaning. How good for the eye if it has caused many codes to be plainly wrong? I'm not saying you'd do it wrong, just saying this notation made and makes a lot of people creating wrong pnach codes from "correct" original codes.

Exactly because I don't count with people knowing hex or even knowing differences between byte, short and word, the main reason to avoid it.

Besides, it "forces" changing the first byte from the original code to 0 or 2 and because the reason for this is not well understood as well, many people did and do it without criterion, sometimes changing word code (2) to zero or changing byte (0) code to 2. If this was not enough to give you idea of what I mean, I don't know what could. Did I already mention how many time people simply put "word" to all codes and changed the digit to 2 despite the original could be anything else?

Edit: even in your, mine and every other case who know all this, this notation still FORCES changing the original code first address digit (1) for short to 0 or 2, what by itself makes the code "non standard" and invalid for translation to any normalized method. in the previous post I gave you example of a code you couldn't grant the correctness unless comparing with the original to verify that lost digit. Of course the code could be right, what does not mean it IS right.

In the end, all this discussion resumes to: In the "extended" notation is enough to look that first digit to know the nature of the code, unequivocally, with certainty there is no errors caused by misunderstanding of all that mess. That's because with "extended" the user don't need to change anything in the original raw code and MUST not do it.
Imagination is where we are truly real
Reply
#7
(04-30-2013, 03:20 PM)nosisab Ken Keleh Wrote: I think you didn't get my meaning. How good for the eye if it has caused many codes to be plainly wrong? I'm not saying you'd do it wrong, just saying this notation made and makes a lot of people creating wrong pnach codes from "correct" original codes.

Exactly because I don't count with people knowing hex or even knowing differences between byte, short and word, the main reason to avoid it.

Completely understood. I just don't think it of it a reason enough to remove it. If it's such a bother, adapting the guides to only mention explicit length as an advanced technique or something should suffice.
Reply
#8
(04-30-2013, 03:29 PM)Coornio Wrote: Completely understood. I just don't think it of it a reason enough to remove it. If it's such a bother, adapting the guides to only mention explicit length as an advanced technique or something should suffice.

Actually, maybe the pnach (file) could be simplified to accept the code as it comes raw. Extended notation allows for this, so a pnach file could be

//my cheat
10023448 00000000

and that would be interpreted by the pnach (engine) as

patch=1,EE,10023448,extended,00000000

making easier to maintain, keeps backward compatibility and be much less of a pain creating the file. And I would never doubt it is a "short".

Now:

patch=1,EE,20023448,short,00000000

is still correct, but the original code was tampered and made non standard.
Imagination is where we are truly real
Reply
#9
Started quite the conversation here I guess. Well the HP and MP codes did work. But the Quick EXP did not. As said I took them from codetwink and there are in codebreaker format so I converted them. Of course my knowledge of how the pnach file works isn't that great Smile

So this code does not work:
Code:
//Quick EXP gain
patch=1,EE,205B7790,extended,0000FFFF
patch=1,EE,205B7890,extended,0000FFFF
patch=1,EE,205B7990,extended,0000FFFF
patch=1,EE,205B7A90,extended,0000FFFF
patch=1,EE,205B7B90,extended,0000FFFF
patch=1,EE,205B7C90,extended,0000FFFF
patch=1,EE,205B7D90,extended,0000FFFF

Maybe it's just not a code that works. I dunno. I don't have the time to search for it with a memory viewer so I simply have to train I guess xD
Reply
#10
(04-30-2013, 10:43 PM)R.D. Wrote: Started quite the conversation here I guess. Well the HP and MP codes did work. But the Quick EXP did not. As said I took them from codetwink and there are in codebreaker format so I converted them. Of course my knowledge of how the pnach file works isn't that great Smile

It may be irrelevant, but are you sure you got the right codes? You mention Grandia II here while the comment in the pnach says it's for Grandia III..

Other than that, search for alternatives such as gameshark to see if the codes line up with one another. If not, give them all a try.
Reply




Users browsing this thread: 1 Guest(s)