Question and problem: Making your own AR codes

Discussion in 'NDS - ROM Hacking and Translations' started by PlatinaKnife, Apr 9, 2016.

  1. PlatinaKnife
    OP

    PlatinaKnife Member

    Newcomer
    14
    1
    Jan 22, 2015
    Belgium
    Over the past couple of days i've been trying to make my own AR codes, but things aren't really going as I expected...

    I've tried to follow this tutorial that uses EmuCheat and No$Gba. I followed along, did everything the tutorial said, but have stumbled upon a problem. When i hooked up the emulator and tried to search for a value, EmuCheat gave me this message: "Please Run Game after Search!"
    I've tried anything that i could think of, but it keeps giving me that message.

    Does anyone know what i could've gone wrong? Is it important the emulator is the same version as in the tutorial, and not newer?
    Other (better) ways to create AR codes are always welcome.
     
  2. FAST6191

    FAST6191 Techromancer

    pip Reporter
    23,882
    9,788
    Nov 21, 2005
    United Kingdom
    That looks like an older method, it certainly uses a much older version of no$gba. The idea behind the combo is that regardless of what no$gba does it still has a copy of the DS memory inside it. You attach a program to no$gba that can read and manipulate the memory of other programs and you have your cheat finder and maker, however the memory layout of programs does rather tend to change between versions (emuhaste, one of the alternatives has a custom attach point for just this purpose). These days I reckon desmume has a better cheat search, and if you want to get really far in there then the no$gba debug version is free. Stick with desmume at the start though and once you get the hang of basic infinite ammo type cheats you can move onto other things.

    Anyway the encoding for cheats can be found
    http://doc.kodewerx.org/hacking_nds.html

    The first problem you are likely to meet is pointer codes. If you have ever learned C or C++ programming you would have met pointers in memory. In short they do much like they sound and direct (point if you will) to another place in memory. The DS is new enough and with new enough takes on systems design that it saw fairly extensive use of these, normal cheat making method are still good though. Here you can have memory locations that change between boots of the game, even between levels or menus or something depending upon things. However they will still tend to have a location that points to the current value, you can then read this and direct you cheat. It is possible to have pointers to pointers (to pointers to pointers....), indeed it is a popular examination question for those learning C and C++ to see if they have truly grasped pointers to have a massive thing some 20 pointers and encodings long to see if the person truly gets it.
    Afraid this is where I come up a bit short though as I am more of a ROM hacker than a cheat maker so I tend not to keep up with all the tools and there are a variety of pointer cheat search tools. You tend to feed them several memory dumps and the location that the data you want to edit is at for each of them and the pointer search tool will tease out the thing that points to the locations in each instance, kind of similar to the classic cheat making concept of fire one bullet, run a search, fire another bullet... when it comes down to it.

    After this we have all the abstract stuff and common things that are worth checking between games. The DS copies the binary which runs the game into memory so you can make a normal cheat which in fact alters the very code the game runs (classically this would be game genie territory). DS cheat engines are also considerably more advanced than older ones which tend to amount to "hold this value" and not much more -- with the DS ones you can build up a reasonable chain of logic to do things only when something else is a certain value, and do an awful lot of repetitive tasks that would be a pain for older systems. Indeed said check and then do something is useful if you want to edit the binary but the binary in question is actually an overlay (a small section of code that gets swapped in and out memory as it is needed, patching something that is not the overlay could cause issues so you want to check).
    You have some other stuff like language cheats; the DS dumps the firmware settings into memory and the games often determine language from that, we have had games reveal languages they did not officially have in games up to and including advance wars and I have also made such codes for people to use more limited emulators or flash carts or just not have to change their settings for one game.
    Moon jump is popular. These vary, though the first thing you want to check is whether the game has double jump for if you make it so it never registers that a second jump has happened then you get to jump to the moon.

    This could go on, if you lost me after the link to enhacklopedia/kodewerx then don't worry, get the basic cheat making concepts down with desmume first as they are easy enough to start getting results with and the rest you can learn about as you encounter it.
     
  3. PlatinaKnife
    OP

    PlatinaKnife Member

    Newcomer
    14
    1
    Jan 22, 2015
    Belgium
    Thanks alot!