Cheat System

[vsub]

Personally I think pcsx2 first need to have something like a dialog window from which you can choose which codes you want to enable at the moment and which not.
Currently to do that you have to first disable the cheats the you don't want to use by editing the .pnach file and then start pcsx2 and if for some reason you want to use some of the other cheats that you disable already,you have to restart pcsx2 to do that(I may be wrong about that).

Something like the cheat engine(not finding cheats,just enable/disable them)in PJ64 for example,or maybe like PEC for PS1

[Koji]

I'd be happy with just an updated version of the patch searcher from 0.9.6

[nosisab Ken Keleh]

Yes, PEC was a great idea to PSX emulation... it is a plugin which ran over the video plugin, it was completely separated from the emulator itself.
In a way I think this is the way to go, keeping everything external to PS2 itself outside the emulator.

PS: I mean, providing the hook for a cheater plugin could make things easier.

[awsdert]

...not all functionality was implemented, doing so would be totally emulate the original device and because of it the original commercial cheat database can't just be used. Many codes types are not implemented and would lead to crashes or strange behaviors...

I thought about this already which is why I used Code* in my example earlier, it supposed to be a struct or class that the hack() can make use of with a switch statement such as:

Code:

switch (codelist[i].type) {
  case CODE_WRITE8: ... break;
  case CODE_WRITE16: ... break;
  case CODE_SLIDE8: ... i++; break;
  case CODE_IS8: ... i += I; break;
  case CODE_ISNOT8: ... i += I; break;
  default: break;
}// like this unsupported codes are ignored (could be printed to console for user reference)

to allow this the read*Bin functions would feed the types and information into the array before passing it to hack() that does the actual hacking based on this array

[nosisab Ken Keleh]

those code chunks tell nothing, better if you can provide what does each "code type". No developer of PCSX2 has any hard time with coding, you should believe it.

That is the most common mistake many programers do, jumping directly into the code before complete high level understanding (The vision of System) and precise notion of what need to be done.

What I mean is at least something like:

0 - means the provided byte is to be put into the provided offset
1 - means is a short that is to be put there
2 - means a word...
3 - ?
4 - "place here what it does..."
.
.
and so on. Having that information make things much more ease. Of course providing the data structure for the complexes codes is a boon.

PS: What you propose is just the same pnach already does, without it's format. To this would be simpler just to verify the line does not follow the pnach model (after some sanity check, of course).. and pass the values to the already implemented "extented" module, instead remaking all the coding.

Ah, yes, the code still need to be converted to raw...

PS: I totally agree with vsub, having means to activate deactivate codes from inside the GUI is very useful.

[awsdert]

You can't be reading what I write carefully enough (or you're not connecting the dots properly), so here's a simple explanation of what happens:
enum { CODE_WRITE8 = 0, etc }
Code { int type, char address[8], char* value, int repeat, char* inc, char* dec, ? other } // Codes converted to RAW b4 placing in array
FILE -> read*Bin -(no errors)> Array[Code,Code,...] -> hack()
FILE -> read*Bin -(errors)> Console // bad idea to pass uncertain array to hack()

[nosisab Ken Keleh]

Please, I can read the code, it is just not what to "pass" to the programmer staff, less yet what the system analyst expect to know from the user.

On the highest level must be defined "only" what the system is expected to do, in this particular case it consist in identify a base address, a value and what to do with this value. Must not be defined at this level anything telling "how to implement it". The reason is to keep the system modular and allow for cleanness and implementation flexibility as the levels are refined.

Pnach already established a line format which caused more problems that was needed... all commercial cheat devices uses a same line format that is

txDDDDDD wwwwssbb

where:

t is the code type and I'm unsure about x at this point, if it is indeed part of the address or subtype.
D is the address
w,s and b are hex digits composing the actual value.

In it's first generation, pnach strayed from this model, it expected the address being absolutely given and the the code identifier became an explicit "token"... more yet it provided a mechanism to tell how the actual code should be applied and to what PCSX2 module.

In the end it was a clear example of dirty analyze phase from what it tried to redeem implementing the token "extended" which in fact eliminated the need of that already ill conceived pnach line format (it just complicates the parser). I mean, the module that deals with "extended" read the code type directly from the "address" part of the code.

So, the actual pnach line format became obsolete even in the pnach engine with the introducing of the "extended" token and is kept for compatibility. Nevertheless no new facility was implemented in the parser to deal with the "common code format"... and this is what you are actually proposing, what is a mean to read the two 8 digits strings which carries all that is needed: the code type, the base address and the value.

If you are following... with the introduction of "extended" the engine already is able to deal with the most common codes types, there is no need to redo it (unless if to implement the remaining codes it does not understand yet).

What would need to be done is just giving the parser the ability to read a line in that 2 strings format and pass them as parameters to the module that deals with the "extended" code. No need to talk about actual code at this point, actually talking about specific implementation that soon is the bane of good analyze practices. Notice we don't know yet if the parser should be adapted or the entire thing should be redone from scratch.

Still, whatever actual device... the only significant data to the engine proper is the "raw" data. Any proprietary encryption system need yet to be dealt with, and this is another topic.

[awsdert]

From what you're telling me the engine anaylses the codes on the fly permiting only the RAW set, what I'm proposing is that the information is anylaysed before hand leaving the converted info in obj parameters that the hacking function can use straight away after identifing if the code is of an peformable type. Also by putting the array as an argument it creates the potential to support code types that incase several code lines, e.g.

Code:

case CODE_ISLONG8: if(getPSAddress(tmp.address, 8) == tmp.value) {
  j = i + 1; Code* newcodelist;
  while(codelist[j] != NULL) { if (codelist[j].type == CODE_END) { l = j; } }
  if (l = 0) { l = j - 1; }
  for(j = i + 1, k = 0;j < l;j++,k++) { newcodelist[k] = codelist[j]; }
  hack(newcodelist); i = l;
} break; case ... setPSAddress(tmp.address, tmp.value, 8); ...

keeping PNACH support would be simple just use readPNACH(FILE, start); since would still need the re/boot procedure to call the relevant read* function based on user settings.

[nosisab Ken Keleh]

No, I'm saying people analyze the problem in the whole and only afterwards should be concerned with where and how to apply the proper code.

Don't get me wrong, I'm not against posting the codes. It's just you could get the PCSX2 source and look directly there what you see can be enhanced/changed. Or create a totally new cheat engine and submit it to the developer as a patch or plugin proposition, it may be integrated in the project, who knows?

What I said was: pnach engine already is able to identify the code type from the given "address", that is the reason for the token "extended", it tell nothing about the code anymore (like byte, short and word did), it only tell the engine is to read the code type directly... so it's not even meaningful/necessary if the code can be parsed directly from the line with the string pair.

Still, there is big pnach database over there which should not be simply orphaned at once, the parser should yet be able to read the pnach line as it would be able to read the two 8 hex digits length strings and the two passed to the engine which would be adapted to receive them too, as parameters.

At this point I'm not sure if the sanity check is done in the parser or the engine (as in the actual project), better dealing with it the sooner possible.

PS: In the end, what I'm saying is: anyone able to implement that modification in the engine should be knowing enough to need not being told how to code it.

PS: just to give you the idea... a "dirty" and quick way to "solve" the problem would be simply reading the line formatted as those two strings and generating a line including

patch=1,EE,"first string here",extended,"second string here" (notice how the highlighted chunks become redundant and no necessary)

... and the actual engine would happily read it without traumas.

PS2: I did notice the bit about the raw code was not clearly understood. The engine need "actual" addresses and values, if the code is encrypted, the mechanism to convert it to raw must be provided beforehand, the reason I said it being another story. What I see you call "hack" is the pnach engine itself of any other still to be implemented...

[nosisab Ken Keleh]

Albeit being a second post in sequence, I think it better than increasing yet more the previous and the subject is other, anyway.

I don't pretend to know the pnach mechanism completely. Still, the EE part points it was not originally intended only for cheats but to "patches" too. I never saw it being used other than for the EE, probably it should be able to patch GS or other modules too.

At this point I'm "almost" tempted to look the source code for wtf it does

PS: you may want to look the browser.cpp under "cheats" under "AppHost" in the pcsx2 source code...