Finding cheats is the same on most things. You get an emulator or debugger that can read memory and has a cheat search, or a program that attaches to an emulator's memory (this is what the likes of emuhaste, art money and similar things are, can use many hex editors as well but they are not as easy as things designed to look for cheats).
In the case of the gamecube the main emulator of choice is Dolphin. https://dolphin-emu.org/
If you are playing GC on wii then not sure what goes for the likes of the USB gecko for GC games, or what is available for the various compatibility layers/GC "emulators".
https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial covers some basic cheat making ideas for the GBA but the ideas translate to just about everything.
The basic approach is you think of something you want to investigate, say money, get somewhere you can lose or gain money, lose the money whilst doing as little else as you can, search for something that changed, you will probably get thousands of results, lose some more money (buying something maybe), new search, repeat until you get to a manageable amount of results of it becomes obvious.
Depending upon the setup you will have a variety of search options like less than, greater than, range search, number search, signed/unsigned (sign allows you to have negative numbers), floating point (way for computers to do fractional rather than whole numbers), changed, unchanged and all do much as they say.
There are other little things you pick up on -- things like flags*, shifts**, memory setups***, sizes of data expected (if I have 9999 health in the end game I don't expect 8 bits/1 byte values as they only count up to 255, see also why many games have stats that top out at values like 127,255,511,1023...) and more but this is going to be long as it is. Sometimes game makers will add things to frustrate cheat makers, the etk link above covers some of them. This can include mirrored values (more than one value is checked by the game rather than just one, and it is usually not the same but mathematically related), changing locations, check values, values living on the stack rather than memory (basically in the CPU's own memory rather than the normal game memory and it operating on that until it is done with it) and the cheats being too slow to write such that infinite health might not be infinite in the face of a big rocket/ultimate spell that does all the health damage in one shot before the next write can top it back up.
*double jump in a game is usually a matter of when in air if jump is pressed check to see if second (or third or fourth if it is that sort of game) is done, if not then do jump and set second jump flag as done, if it is done then do nothing. You find where this flag is and you have one of the main ways moon jump cheats happen.
Flags are also what a lot of potions, item equips, monster repels, areas, rested bonuses and more are. This is why lists of cheats will often match what is available in game rather than generic notions of such things.
**if you find where the experience is calculated after a battle and stored in memory then some cheat engines will allow you to shift it. Shift in binary maths (which is what computers use) is like multiplying or dividing by 10 in decimal in that you just shift the numbers along in the appropriate direction, and why most exp cheats are 0.5x, 2x,4x,8x,16x... rather than something else.
***for things like stats tables for characters/weapons/whatever then there are two main approaches. It helps if you imagine a spreadsheet at this point.
You can either take the whole character one by one, that is to say in generic RPG setup this is character 1's atk,def,mag,spec,luck, this is character 2's atk, def, mag, spec, luck, this is character 3's...
or you can go what might be column wise. This section is all the character's atk stats in a line, next all the def...
Same idea for inventory cheats -- either there is a big table where say byte 20 corresponds to how many swords, byte 22 to how many long swords, byte 24 to great swords... or there is a list where a value corresponding to what it is and then another to how much of it there is. Do also spare yourself trouble -- don't do the 30 hour epic side quest for the ultimate weapon. Go to the first village shop/whatever is good to use after the obligatory training section, give yourself infinite money, buy a sword, search, buy another sword, search... until you found where sword counts are at in memory. The sensible bets on either the next value along or the next value up in the encoding is the long sword if we are continuing with this generic RPG metaphor. Try different values and eventually you find yourself with infinite ultimate weapons, and maybe even some stuff that was cut from the final game but still in the code.
Pointers are then the annoying part of all this.
It is hard to know how much memory you will need at a given point in a program. On older systems this fell to the coder to know where memory was and what it was doing, however that gets very limiting, very tedious and very demanding of the programmer so as soon as was possible (PC this was quite early on, in games this was the PS1). Today, and this includes some aspects of the gamecube, programs just request a section of memory when needed and return it after they are done (the failure to return it repeatedly happening is what is otherwise known as a memory leak). Something random happening is pretty much standard operating procedure for a game so you can't rely on something getting the same chunk of memory every time for all things. To keep track of where something is then you have a pointer, forgive the recursive definition but these point the way to where the data is at. You can have a pointer to a pointer (to a pointer to a pointer...) and indeed such a thing tends to be a test when doing an exam on C programming, game coders sometimes stack multiple ones up to frustrate cheaters or because they are bored but not always.
Anyway finding pointers can be tricky. Most start by finding the value they want for that given run, and noting where it is. Repeat for a bunch of different runs gaining it in different locations (make sure to keep the locations). You then get to find whatever location is holding the location of the locations of the data (so you have three runs, data found at location X, Y and Z respectively, you then compare each run to find where in memory is something holding the location of X and whether in the run that found Y said area was holding Y and same for run finding Z) you found in each run, which most do with pointer searching tools but you can go manual or use a debugger (this involves programming skills though).
Beyond this then you get into things like attacking the game's code in memory -- waiting to grab new code from your little DVD running at a few megabytes a second with sometimes seconds to get the laser in place to fetch data, to run when you are screaming along at many hundred megahertz (millions of cycles per second) is not a great look. To that end games on optical drive systems, floppy discs and newer cartridge consoles (DS on up, the GBA has expensive memory, why GBA flash carts are expensive to this day, to run it quicker) copy the code the game runs on into memory. As cheats change normal memory then so it goes that you can edit the code the game is running via cheats. Again though this requires some programming skill as you are now editing code, and doing so at one of the harder approaches to programming (assembly programming, being the thing referenced above where coders handle what everything is and does themselves, as that is what the code is left as and turning it back into normal code is quite difficult and the subject for another day -- https://gbatemp.net/threads/can-i-aka-you-as-i-cant-wont-code-port-this-game-to-this-device.576997/ .
In the case of the gamecube the main emulator of choice is Dolphin. https://dolphin-emu.org/
If you are playing GC on wii then not sure what goes for the likes of the USB gecko for GC games, or what is available for the various compatibility layers/GC "emulators".
https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial covers some basic cheat making ideas for the GBA but the ideas translate to just about everything.
The basic approach is you think of something you want to investigate, say money, get somewhere you can lose or gain money, lose the money whilst doing as little else as you can, search for something that changed, you will probably get thousands of results, lose some more money (buying something maybe), new search, repeat until you get to a manageable amount of results of it becomes obvious.
Depending upon the setup you will have a variety of search options like less than, greater than, range search, number search, signed/unsigned (sign allows you to have negative numbers), floating point (way for computers to do fractional rather than whole numbers), changed, unchanged and all do much as they say.
There are other little things you pick up on -- things like flags*, shifts**, memory setups***, sizes of data expected (if I have 9999 health in the end game I don't expect 8 bits/1 byte values as they only count up to 255, see also why many games have stats that top out at values like 127,255,511,1023...) and more but this is going to be long as it is. Sometimes game makers will add things to frustrate cheat makers, the etk link above covers some of them. This can include mirrored values (more than one value is checked by the game rather than just one, and it is usually not the same but mathematically related), changing locations, check values, values living on the stack rather than memory (basically in the CPU's own memory rather than the normal game memory and it operating on that until it is done with it) and the cheats being too slow to write such that infinite health might not be infinite in the face of a big rocket/ultimate spell that does all the health damage in one shot before the next write can top it back up.
*double jump in a game is usually a matter of when in air if jump is pressed check to see if second (or third or fourth if it is that sort of game) is done, if not then do jump and set second jump flag as done, if it is done then do nothing. You find where this flag is and you have one of the main ways moon jump cheats happen.
Flags are also what a lot of potions, item equips, monster repels, areas, rested bonuses and more are. This is why lists of cheats will often match what is available in game rather than generic notions of such things.
**if you find where the experience is calculated after a battle and stored in memory then some cheat engines will allow you to shift it. Shift in binary maths (which is what computers use) is like multiplying or dividing by 10 in decimal in that you just shift the numbers along in the appropriate direction, and why most exp cheats are 0.5x, 2x,4x,8x,16x... rather than something else.
***for things like stats tables for characters/weapons/whatever then there are two main approaches. It helps if you imagine a spreadsheet at this point.
You can either take the whole character one by one, that is to say in generic RPG setup this is character 1's atk,def,mag,spec,luck, this is character 2's atk, def, mag, spec, luck, this is character 3's...
or you can go what might be column wise. This section is all the character's atk stats in a line, next all the def...
Same idea for inventory cheats -- either there is a big table where say byte 20 corresponds to how many swords, byte 22 to how many long swords, byte 24 to great swords... or there is a list where a value corresponding to what it is and then another to how much of it there is. Do also spare yourself trouble -- don't do the 30 hour epic side quest for the ultimate weapon. Go to the first village shop/whatever is good to use after the obligatory training section, give yourself infinite money, buy a sword, search, buy another sword, search... until you found where sword counts are at in memory. The sensible bets on either the next value along or the next value up in the encoding is the long sword if we are continuing with this generic RPG metaphor. Try different values and eventually you find yourself with infinite ultimate weapons, and maybe even some stuff that was cut from the final game but still in the code.
Pointers are then the annoying part of all this.
It is hard to know how much memory you will need at a given point in a program. On older systems this fell to the coder to know where memory was and what it was doing, however that gets very limiting, very tedious and very demanding of the programmer so as soon as was possible (PC this was quite early on, in games this was the PS1). Today, and this includes some aspects of the gamecube, programs just request a section of memory when needed and return it after they are done (the failure to return it repeatedly happening is what is otherwise known as a memory leak). Something random happening is pretty much standard operating procedure for a game so you can't rely on something getting the same chunk of memory every time for all things. To keep track of where something is then you have a pointer, forgive the recursive definition but these point the way to where the data is at. You can have a pointer to a pointer (to a pointer to a pointer...) and indeed such a thing tends to be a test when doing an exam on C programming, game coders sometimes stack multiple ones up to frustrate cheaters or because they are bored but not always.
Anyway finding pointers can be tricky. Most start by finding the value they want for that given run, and noting where it is. Repeat for a bunch of different runs gaining it in different locations (make sure to keep the locations). You then get to find whatever location is holding the location of the locations of the data (so you have three runs, data found at location X, Y and Z respectively, you then compare each run to find where in memory is something holding the location of X and whether in the run that found Y said area was holding Y and same for run finding Z) you found in each run, which most do with pointer searching tools but you can go manual or use a debugger (this involves programming skills though).
Beyond this then you get into things like attacking the game's code in memory -- waiting to grab new code from your little DVD running at a few megabytes a second with sometimes seconds to get the laser in place to fetch data, to run when you are screaming along at many hundred megahertz (millions of cycles per second) is not a great look. To that end games on optical drive systems, floppy discs and newer cartridge consoles (DS on up, the GBA has expensive memory, why GBA flash carts are expensive to this day, to run it quicker) copy the code the game runs on into memory. As cheats change normal memory then so it goes that you can edit the code the game is running via cheats. Again though this requires some programming skill as you are now editing code, and doing so at one of the harder approaches to programming (assembly programming, being the thing referenced above where coders handle what everything is and does themselves, as that is what the code is left as and turning it back into normal code is quite difficult and the subject for another day -- https://gbatemp.net/threads/can-i-aka-you-as-i-cant-wont-code-port-this-game-to-this-device.576997/ .
Similar threads
- No one is chatting at the moment.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
@
RedColoredStars:
There is an actual trailer with footage too. lol. Going to watch it tonight. Grabbed it from... a place. -
-
@
SylverReZ:
@Psionic Roshambo, JonTron's back yet again until he disappears into the void for another 6 or so months.+1 -
-
-
-
-
-
-
