ROM Hack How do I convert raw cheat codes made with Desmume to work on R4 3DS?

[CalebW]

I have Tom Clancy's Splinter Cell: Chaos Theory and I searched the web, but the only action replay code I found was just unlocked all the missions. So I used Desmume's cheat search function to find the address of the rifle ammo, but when I put it in my R4 3DS it wouldn't work. Is there a way to convert it to an action replay code?

Here's the raw code:
0x02268778 00000063

I tried to put it in my R4 3DS as:
02268778 00000063

and as:
22268778 00000063

and as:
32268778 00000063

Any help would be appreciated.

 

[FAST6191]

The 2268778 00000063 cheat probably should have worked (assuming it uses AR format codes it should be a 8 bit write to 02268778 which is right in the middle of the memory and right where I would expect to find a such a value).

That it does not says you may be dealing with a pointer code- not all memory locations are hardcoded static things and they may shift every boot (or indeed more often). That there is no cheat for the same online would appear to point at something like that as well (infinite ammo cheats are usually seen as some of the easiest to make and will usually be done when just getting a feel for the game).

It is a fairly simple test- reset the game in desmume and add your code back and repeat a few times, if it continues to work we can look at other things but there is a good chance it will not work.
Finding pointer cheats does potentially have some fairly simple techniques to find the pointer*, I should have a handful of tools up on filetrip for it and I saw a few others up there when I was adding those.
It might be a further thing like a mirrored value somewhere but let us not go there.

*pointers do as they say and are a vital part of C family programming which many DS games are programmed in. The general idea is somewhere will be a value saying where the ammo value is held in this particular boot. These programs take memory dumps from games and locations of the cheats before comparing them to see if it can divine a location, not a foolproof method but one that often works and is far nicer than some of the more in depth methods. As many will wander there yes you can have a pointer to a pointer and it has been seen several times "in the wild" (it being one of the main things to trip up the tools just mentioned) and is not even that exotic a programming technique.

 

[CalebW]

Ok, I did 5 tests.

Test 1:
02210D78 00000063

Test 2, 3, and 4:
02210DB8 00000063

Test 5:
022687B8 00000063

 

[FAST6191]

I assume those are the cheats you found on each new run- if so then you definitely have a pointer code on your hands.

I forgot to link this up first time around, it is not quite what you will have to do but close enough if you follow what is actually going on (basically dumping the memory, noting the cheats for that run and feeding them to the program)


The basic idea does not change much when it comes to actually making your cheat although you will have to add a few steps (there are a handful of "offset" codes that will handle it well, I assume you have access to something like http://doc.kodewerx.org/hacking_nds.html#arcodetypes to tell you what cheats do.

 

[CalebW]

Ok, I tried it, and created a pointer code, but it only works on one level on the emulator, and it doesn't work on my action replay.

 

[FAST6191]

Two possibilities as I see it-
1) I see the same location was seen in a few occasions up above. You might have just got (un?)lucky again.

2) Each level is different (quite doable if everything is cleared and a function/subroutine is called to start anew). I would have thought the pointer would have held but a pointer to a pointer could be in effect and thinking about it the same could also apply to 1).

 

[CalebW]

Yeah, on each level sometimes I've seen up to 3 different addresses for the same thing. How would you find a pointer to a pointer?

 

[FAST6191]

Three main methods as I see it
You can try a similar thing to what you did already for finding single pointers but with the addresses of the new pointers.

You can dump the memory and scan it to see if you can find the location by hand- if you know the location of the pointer to the ammo that run was say 02A00010 then the thing that holds that value will probably be the pointer to the pointer (and hopefully the last one you have to find for that level and maybe even for the whole game although that is not as likely).

You can properly debug the game to figure out what is going on. This is surefire but potentially not easy as you will have to mess around with assembly coding.

All this will take a bit more effort to make a cheat for as well though as you will probably want to mess around with logic inside the cheat engine.

"3 addresses for the same thing"

You say you already have pointers which is fine but when I see that (do you mean at any one point in time there can be three separate values all holding say ammo remaining?) I am reminded of an anti cheat method called mirrored values. Usually it would be fairly obvious from a basic cheat finding search (three values all going down by one each time) but there are slight variations on the theme. If the game is actually doing this sort of thing I am now quite curious- for it to happen on a franchise cheap and cheerful handheld cash in type game is quite odd, that said boredom is an interesting situation to be in and a bored programmer leads to odd things like this.

 

[CalebW]

No, what I meant was that each boot on the emulator it assigns the value for the ammo to a different address, but it usually on each level assigns it to addresses that are just slightly off. for instance on level 2 for pistol ammo the addresses were: 022107B8 and 022107F8. But for level 1 it was close to 022686.. (I don't remember the exact address.)

 

[FAST6191]

Ah OK that potentially makes life easier- on boot it assigns a different address means you have a pointer code and for now I will treat that as a sorted problem for the most part. Your pointer code itself might technically be off as well- it probably has a whole bunch of variables and if it assigns but again I will assume it is good.

"Slightly off" from said value but still close the pointer could mean a few things, much of this is probably easier if you understand C programming up to pointers and maybe a bit of assembly too (youtube lecture series that will eventually catch you up here). You can muddle through it without such knowledge though.

Those few things are

1) Pointer arithmetic
2) Function calls
3) Arrays

1) Pointer arithmetic then.
Short version (and very crude) is pointers well point to things but in C when you add to the pointer it does not necessarily treat it quite as a number as you might expect but will jump so many pointer values ahead. Kind of related is 3) which can do much the same.

2) Function calls- in some ways it might be a hallmark of a bad programmer that coded the game originally if they have called a full level function from within another function and created a new bit of data from the originals you were trying to handle. "Slightly off" means this is less likely to have happened. Alternatively it might be that the storage value the pointer looks at on boot is harder to work with and it was expanded for the purposes of running the game but let us not go there right now- the basic example would be if I have 4 weapons and each can hold 15 ammo I can say FFFF with each number being the ammo for the gun which is great for storage but a nightmare for logic (sub 1 from this value becomes do a bunch of maths), if it is something like this it could be troublesome but I must stay away from theory coding right now as it is not really fair to you to have to read my waffle.

Fortunately the DS cheat engines have things to help account for this (it is part of the reason for "+offset" in the technical definitions of the codes and in the case of AR codes the Incrementive Write having stuff also handling the offset values as they work).

You now get to test what happens. You need to know if it is always the same amount away from the pointer (maybe give or take differences in loadout if you say have a pistol on one and a pistol and a machine gun on another but only a machine gun on another) or if it is near but random. A nice list of boot pointer location and then resulting ammo location and break it down by mission if you want will help figure this out.