(Artemis) Code Types

[misfire]

Very soon it will be our cheat engine and with the help of you and other developers Artemis will prevail, without a doubt.

Yes, the file format will be plain text in the beginning. Actually, I've been working on a C library called libcheats which allows you to read, manipulate, and write cheat codes in text format. Although the library is kind of generic, it still expects one code line to be two 32-bit words. Without this size limitation, I guess libcheats could turn into a standard library when it comes to cheat code parsing. We'll see...

As for performance, I/O is quite slow on the PS2. So parsing a text file line by line is a bad idea. It's better to read the whole file into a buffer and let libcheats process it. I don't know if there're issues with really big databases but a binary format is worth considering. We could even support both.

[Lazy Bastard]

Very soon it will be our cheat engine and with the help of you and other developers Artemis will prevail, without a doubt.

Indeed. Not only do we have the only hacking system, but our cheat system will be far better than the others, and will be the only one that supports several code types.

What do you think of the legality of including support for encrypted (CB/GS/AR) codes? And further, how difficult would implementation be?

[misfire]

No encryption. No proprietary formats. An end to control.

If you want to use encrypted codes, decrypt them.

[Lazy Bastard]

I have no interest in using encrypted codes. But I'm thinking of the average user, and simplicity.

Still, I suppose we can simply point them to OmniConvert (or, if I ever get around to updating it, Majestic Porter).

[misfire]

All of the code types I've implemented so far are compatible with CodeBreaker V7+ (the best commercial cheat system) and the basic types are compatible with the other systems too. Except for the F master code, we should technically be able to use most of the available raw codes out there.

I'll do anything I can to keep proprietary bloat out of the project. It's wrong from a technical and philosophical point of view.

[Gtlcpimp]

I have no interest in using encrypted codes. But I'm thinking of the average user, and simplicity.

Still, I suppose we can simply point them to OmniConvert (or, if I ever get around to updating it, Majestic Porter).

In the end there is no use to encrypting codes. If you don't want them to discover what the code is in RAW state, don't give it to anyone. People such as myself have taken encrypted codes and went lazy way out of finding out what they are by dump memory and compare before code use and after code use. There honestly is no point to encrypting them, because in the end it is still able to be found out when encryption's main purpose is to keep it a secret...

Just stick to RAW hexadecimal format as I have, makes it easier on the programming.

[Lazy Bastard]

Again, I have no interest in using encrypted codes, let along encrypting codes to keep their actual addresses and values secret. I abhor the entire idea.

I was merely considering it as a measure of ease for the average user, who wants to add his/her favorite codes that already exist in an encrypted format.

[Viper187]

No encryption. No proprietary formats. An end to control.

If you want to use encrypted codes, decrypt them.

Damn straight! Keeping it raw may annoy some n00bs at first, but we want to push people to learn the difference between raw codes and proprietary shit. In essence, teach people the right way to do things instead of supporting the wrong way to please a few lazy/stupid people.

[kh2k4]

It's the only reason I use CB it's fast and does exactly what it says instead of the fancy gui which Xploder &
AR have which was more than likely coded with stolen code the only thing I had against CB was the inability to save codes to mass.
I'm surprised Datel hasn't already stolen code from this project already just like they did with CWCheat, MEMOR32 etc.
This is gonna be like cosmic cheat on jet fuel :-)

[Parasyte]

Damn straight! Keeping it raw may annoy some n00bs at first, but we want to push people to learn the difference between raw codes and proprietary shit. In essence, teach people the right way to do things instead of supporting the wrong way to please a few lazy/stupid people.

I concur wholeheartedly, my African-American brother.

[misfire]

Thanks for supporting my opinion.

[Parasyte]

Of course.

[Skiller]

@kh2k4: Yes, I'm sure because I reverse-engineered most of CodeBreaker's interesting code, and the C type is also used for the same purpose by Xploder V4.

@bungholio: This is possible. We could use one of the @n digits to indicate the operation without affecting compatibility. I guess nobody actually sets @n to high value. So the 4 code becomes something like this:



What do you say?

if u wanted u could take a page from Ar using this code (Note That it would still be raw just with a tweek :P)

4? aaaaaa nnnnssss
vvvvvvvv iiiiiiii

Make it so u can do 8, 16 and 32

Example

Low Ram
8bit
40aaaaaa xnnnssss
vvvvvvvv iiiiiiii

8bit Hight Ram
41aaaaaa xnnnssss
vvvvvvvv iiiiiiii

16bit
42aaaaaa xnnnssss
vvvvvvvv iiiiiiii

16bit Hight Ram
43aaaaaa xnnnssss
vvvvvvvv iiiiiiii

32bit
44aaaaaa xnnnssss
vvvvvvvv iiiiiiii

32bit Hight Ram
45aaaaaa xnnnssss
vvvvvvvv iiiiiiii


a = start address (25 bits)
n = number of times to write (16 bits)
s = size of address step (divided by 4) (16 bits)< -- the divider Changes depening on the Bits
v = start value (32 bits)
i = size of value step (32 bits)
x: 0 = Write, 1 =OR, 2 = AND, 3 =XOR


---------------------------------------------

U know another Usefull Code type would be one that Alows u to Copy From within a pointer

5-sssssss nnnnnnnn
0ddddddd z0XXXXXX

s = address to copy from (25 bits)
n = number of bytes to copy (32 bits)
d = address to copy to (25 bits)
Z = 1 = Read Address as pointer 0 = Dont Use
X = Offset (24bits)

THis would alow u to make Activators for games with moving Memory .. and your activator is in that memsection ..

Example:
5036AED4 00000001
000A0000 100002EC


(0036AED4 = Value 01000000 Above code would Read that then go to 010002EC and Read the value Starting from that address and then copy it to 000A0000)

This would have made My help with Hacking Pgen (Homebrew EMU for GEN) alot easyer

[bungholio]

This is long. Everything is basically an "if". If you could see an actual use for it, use it, they are just a mixed jumble of ideas.




@misfire
http://www.thegshi.org/vb/showpost.p...1&postcount=15
Do it with the skip instead. Nobody skips that incredibly high, and I definitely use that high of "n". Nobody realistically uses that high of an amount of lines for a code, I just use it that high with codebreaker to apply values to 65536 addresses or more at a time, and would probably no longer need that method if I were using Artemis, even though it could still definitely be used that way by me with Artemis for the sake of checking a bunch of nearby addresses still for things that you wouldn't normally find by comparison scans because they would never change. I'm probably the only "guess and check" guy alive, I must be the only person that would need it. But nobody would ever need a skip amount that high ever.



@misfire again
http://www.thegshi.org/vb/showpost.p...7&postcount=19
I haven't seen more than one pointer necessary yet, but it could have been needed. I keep thinking of that newer Nobunaga game that came out just a little later than Dynasty Warriors 6 that Skiller found codes for. That might have been one of the game's that could have needed that, I don't remember even though he used a subroutine instead of pointer writes. Area 51's codes for individual players might have needed more than one pointer, I wouldn't know because I never knew how to do a save dump with it.
If you could think of something more useful, you might want to implement it. Could just make it 1 byte instead, there's no way a game will use over 256 pointers for something, that way you could be compatible with any codebreaker code for it, and could implement something new for the 2nd byte if you wanted. I honestly couldn't think of anything though.



@viper
http://www.thegshi.org/vb/showpost.p...9&postcount=20
I thought the codebreaker could check for 1 byte too. It would be complete just to have it compare to 4 bytes too, but I've never seen a time where that would be necessary yet. I haven't checked every game in the universe either though, there might be just 1 code where that would be useful.



@misfire and @viper
http://www.thegshi.org/vb/showpost.p...3&postcount=33
http://www.thegshi.org/vb/showpost.p...4&postcount=38
"No encryption. No proprietary formats. An end to control."
"but we want to push people to learn the difference between raw codes and proprietary shit."
Damn Right!!




I was wondering what might all of the code types for each cheat device be? I can't remember, but I know Pyriel might have all of them in the Omniconvert help file. If I had access to usable computer (not this department of labor blocked to death thing) I would check the help file included with Omniconvert, I think Pyriel had all known differences documented in it.



My brain keeps having trouble with this idea here for the 4 type serial repeater.

The increment part. If I set the signed equivalent of -1, FFFFFFFF, would that make the value decrease by 1 with each line?
Like this:
4042dac4 00040003
0069000b FFFDFFFE
would that be the same as:
2042dac4 00660009
2042dad0 00630007
2042dadc 00600005
2042dae8 005d0003
I'd assume it does, I don't know why it wouldn't, but I never actually checked. My only other guess is that it would do this:
2042dac4 FFFFFFFF
2042dad0 FFFFFFFF
2042dadc FFFFFFFF
2042dae8 FFFFFFFF
Those above 4 would be a stupid and worthless way of doing it. The "increment" should be treated as a signed value. It's fairly logical, because if it wasn't and it was always an unsigned value then the code would only increase the next line value higher, and every line after it would always have the value FFFFFFFF. That way it can be an increment or decrement if somebody needed to decrease something. I don't know though, I can' think of a moment where I would have decreased something, nor have I ever seen a code that code have used it that way. It's probably not really necessary.



I was just thinking of that same kind of thing Skiller that you just posted above. Could also use that to copy values from codes that move around in memory. I probably wouldn't use it for much of anything, but if a game like Silent Hill 4 would have used pointers for Henry and Eileen's current positions, then this would have been perfect for copying Henry's position to Eileen's position.
I can't think of a reason to use copy bytes all that much other than for that exact reason, to copy one person's position to a NPC's so you don't need to wait for it's pokey butt to catch up.




I'm also thinking a pointer write would possibly seem to need be incorporated into all code types just in case of those rare pointer codes that could need it. But it might break compatibility?
The code type that starts with 6 would already cover 1, 2, and 4 byte constant writes. What about AND, OR, XOR? Even serail repeaters based off of pointers, maybe your inventory changes position slightly with every room (like Silent Hill Origins, which isn't a good example because a simple ASM code acheieves this) and you would need to give every gun that is about 40 bytes apart 99 ammo. Might even need it for the E and D types for comparing to a code that changes it's location in memory, which would be rare but possible. What if Katamari Damacy would have used pointers for where the current size of your ball is, that would have screwed up my increment/decrement code to change it's size? Katamari Damacy might have used a possible pointer, or maybe just 2 different locations for the movement speed though, my nephew tried it and it only worked in 2 player mode even though the ball size worked in all modes even though the addresses were a few bytes apart. Nothing big.
How about the 4th bit in every code type does a pointer write in the 2nd digit like this:
0(P00a) - 1 byte constant write
1(P00a) - 2 bytes constant write
2(P00a) - 4 bytes constant write
3(P00?) - Increment/Decrement
4(P00a) - Serial Repeater


I'm trying to organize this all in my brain, my thoughts would break compatibility.
0(PLL?) those 2 would determine byte length for all code types
PLLa:
00 = 1 byte
01 = 2 bytes
10 = 4 bytes
11 = 8 bytes

P = is it a pointer?
LL = byte length to write
"a" is still the 1 bit for addresses.

That would make code types 0, 1, and 2 combined into 1 plus add 1 more to it so it could do 8 byte writes, and that would include whether it would be determining whether the address provided has a pointer which points to the address it would write to. I don't know if any games would ever need an 8 byte write, has anybody even seen it used or thought that a code should have been combined that way? I don't think an 8 byte write would be necessary, can't think of 1 moment where I'd have needed it nor have I seen a code that should have used it.




I'd like to keep things perfectly compatible with the codes that already exist for cheat devices, but I'm also a pack rat combining everything into 1 and making the most of what I can with what I'm able to.




Does the code type B function like a timer? I've seen it mentioned, but I have never tried it though. It would just wait however long after a game started and then execute the next line(s) of code(s). I wouldn't see any use for it.



I also can't think of a use for this little idea, but it would only be used with the D and E compare code types. It would be a "write only once per button press" sort of thing. It's a worthless idea. I kind of was thinking something like that would have been needed to use ammo and stuff with the item modifier codes for the Resident Evil Outbreak games, but I was dumber back then and that isn't so because that wouldn't make them work. Don't think of adding that unless you can see a use for it, I can't think of a use for writing something only once per button press.




Do the D and E compare code types have all the compare types codebreaker had, like the OR, AND, FFFF - AND or whatever they were. Pyriel had that little wiki style page that had them. I used one of them for joker commands to allow me to press buttons and activate codes even while other buttons are pressed.

For example:
D042dac4 0000FEEF would only activate the next line if only L2 + Up were being pressed.
D042dac4 00400110 would activate the next line if L2 + Up were ever pressed at the same time, even if you were pressing other buttons at the same time with those 2 buttons.




A master type D or E that would activate every other activate code only if whatever is happening is happening would be a little helpful. I'm thinking of Shadow Of The Colossus. It would save lines for that game, because all of the codes are only active if one certain line is active, or else the game freezes. There's no reason to activate any codes any other time either, so it could just as well be an extra line in the enable code as a separate code type. A "master joker" or whatever you would call it. A supplement to the enable code.
I still remember it slightly, something like E00?E264 013d8190 or something, it was needed for every code.

[Gtlcpimp]

Um, I didn't read the whole conversation going on but I did see some mentioning of pointer commands being necessary or not... I say the pointer command would definately be useful if you can specify how many points there are and how much to add to the address of each point. On Splinter Cell Chaos Theory / Double Agent and SOCOM 3 / Combined Assault I have written routines that access dynamic data for special codes. Codes such as kill modifiers, score modifiers, health modifiers, coordinate modifiers, selected weapon modifiers, character modifiers, etc. down the line of manipulating the structures of any object loaded during game play. The use of a pointer command would take out the routine so I don't have to keep writing to the routine, I could just type up a code that does it all for me and I just gotta add that to a list and hit the "joker" in game.