So I'm a software developer and I was looking into possibly making some mods for some of my 3DS games. But I can't find a reliable source that gives instructions on how to do it.

So does anyone have a good tutorial or site that I can use to learn about it and try developing mods?

 

[TSP184]

First, you have to dump the romfs of your game, which is done on GodMode9 (I'm assuming you already have a CFW on your 3DS):

When you boot up GodMode9, go on "SYSNAND SD" and press R+A, then select "Search for titles" and wait for it to load them all. Choose the game you want to dump and press A.

If said game is on a cartridge, go on GAMECART instead and select the file "*Game ID*.trim.cia".

Select "TMD file options...", and then "Mount CXI/NDS to drive". Once you accept, you'll find the exefs and romfs folders. Select the latter, and copy it to the gm9 folder, or if you only need certain files, select these instead to copy over, and make sure to remember their initial location.

Once you've got a copy, you can move them to your PC to start modding.

Which games do you want to mod? Depending on the format of the files, you might not be able to open some, since there could be no tools to do so at the moment.

 

[Heroice18]

First, you have to dump the romfs of your game, which is done on GodMode9 (I'm assuming you already have a CFW on your 3DS):

When you boot up GodMode9, go on "SYSNAND SD" and press R+A, then select "Search for titles" and wait for it to load them all. Choose the game you want to dump and press A.

If said game is on a cartridge, go on GAMECART instead and select the file "*Game ID*.trim.cia".

Select "TMD file options...", and then "Mount CXI/NDS to drive". Once you accept, you'll find the exefs and romfs folders. Select the latter, and copy it to the gm9 folder, or if you only need certain files, select these instead to copy over, and make sure to remember their initial location.

Once you've got a copy, you can move them to your PC to start modding.

Which games do you want to mod? Depending on the format of the files, you might not be able to open some, since there could be no tools to do so at the moment.

I'm looking to mod the 3DS Pokemon games. I'm thinking of trying to add a hud element to the battle screen

 

[FAST6191]

That is quite the ambitious first project if you are asking the sorts of questions you opened with.

Most usually start ROM hacking by fiddling with text, graphics, music if the console is amenable to it (most 16 bit and older stuff is not as everything there was usually custom from the ground up for each game and the composers will master programmers in their own right), maybe some level editing, cheat making and then graduate into altering the game's code via assembly*.

*while decompilation is increasingly a thing and maybe there will be some leaked code it is not likely to be in play for the 3ds too terribly soon. To that end you get to play with assembly code (all high level code that 99.99% of modern programmers write in gets converted to assembly/machine language to run on the CPU itself, going backwards is not easy (see halting problem) so you get to play at that level, which involves handling basically everything yourself and doing everything in very small steps) which some consider the hardest of general programming (though easy enough to gain a few little skills in to help out).

Anyway as you are speaking to the game's own code and fundamentally altering the game's core functionality by adding new (technically reading something that is there and displaying it which is not so bad as say making it into a shooter) you have a fair bit of work to do.

Minor possible alternative. Might not be on the screen but if you want hidden data to be visible you can find where this data is with normal cheat style searches ( https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial , is for the GBA but introduces it more nicely than the 3ds guides I have seen, not sure what I want to link for 3ds code overviews). The 3ds also has some scope for memory viewers to peer in and see things. To that end you could have the relevant memory areas go out over network and be decoded and analysed by a PC program (presumably you are looking to do something like percentage hit rates, number health values and whatever else that is nominally hidden in the average pokemon game).

 

[Heroice18]

From what I've been reading, it seems like the best way to mod a 3DS game is through ASM. If there's a better way to do it I'm all for it. This is more of what I'm trying to accomplish in detail (from another post)

"So I was recently shiny hunting and on a small 3DS screen and it would be pretty hard to tell if a Pokemon was shiny if I wasn't paying attention to the shiny sparkle. This got me thinking, right now in Pokemon Legends Arceus, if you encounter a pokemon, during battle there will be the shiny mark next to it's name, and it's extremely useful for those Pokemon that have a very subtle change.

So my question is, is there a mod/hack for any of the 3DS era of Pokemon games that adds the shiny mark to the Pokemon's HP bar like Pokemon Legends Arceus?

Or is there a way that I can go in and add it? I'm a software engineer so I could add something in, but I've never had experience messing with the code in a pokemon game."

 

[Kwyjor]

From what I've been reading, it seems like the best way to mod a 3DS game is through ASM.

That is pretty much inevitable. I am confused as to how a "software engineer" would otherwise conceive of doing it? It might conceivably be easier to get something working in Citra, but I am not familiar with its particular capabilities.

Have you ever seen something similar done with another 3DS game?

 

[FAST6191]

Assembly is a tool. There is much you can do with cheats, graphics tweaks, external data, level data, music, text tweaks and the like. However assembly is what allows you to understand those more quickly (if you literally have the code doing what it does in front of you then you know what it does, as opposed to having to infer from baseline knowledge and previous experience and alter-run in emulator to see difference-alter-run-alter...), alter more fundamental things and expand the game beyond its original scope. As above though it is considered one of the harder areas of coding as you responsible for basically everything as opposed to finding a library or part of the language doing it for you, and have to do it from generally first principles. It is also unique to that given family of devices -- the CPU might be the same but if the memory and ancillary hardware is different then that is a fairly minor boost, though at the same time I am a firm believer of "learn one assembly and you can learn two, learn two and they all start looking much the same" outside of you do something silly like learning some basic 80s chip and then moving to modern PC and not expecting a bit of a ramp up (though even then it is all much the same, just with more data types and some extra maths for matrices).

Shiny detection is an interesting one. I did read about an automated input presser that used an external camera to determine the fraction of a second longer the battle would take to load for the shiny (otherwise it would just run away) a while back. https://hackaday.com/2013/11/05/finding-shiny-pokemon-automatically/

I don't know if you can find a value in memory that would be present if and only if it was shiny (don't know what shiny is for this -- probably something like if trainer number is the same as this random number but I have only really bothered with the egg stuff before, though there might be something else really obvious somewhere in memory as a secondary effect). If that is the case you could probably make a nice cheat to do something obvious to the screen like set something to a very silly number (HP to 9999999, name to shiny or whatever, maybe alter a colour of something). That is a way less involved version of doing much the same and would not take learning any assembly at all if you can figure out what might be a shiny pokemon by some easier means (there is possibly even a cheat or something you could do to force a shiny pokemon to appear). That or go back to the network thing earlier -- have the thing analyse a dump of the suitable location every second or whatever and if it is shiny have it send up a flare via whatever means you care to employ as a basic detection loop is probably the example they give in whatever language you care to use's take on loops).

Otherwise yeah time to learn some assembly, figure out what indicates a shiny pokemon and have it alter something on screen (possibly a pokemon name) or maybe add something extra/out of place (there is bound to be something not normally on screen in the memory you can slap down to wake you up without having to go through the aggravation of fetching additional graphics

 

[Heroice18]

So maybe instead of creating an element that appears next to the HP of the Pokemon, do you think it'd be easier to maybe change the text that holds the Pokemon's name during battle if it's shiny with a code? That seems like it might be easier.


If not what are some of the tools people use to code in ASM?

 

[Heroice18]

In all of this, I'm not trying to force a shiny, I still want to do the hunt for the shiny. So this is more of an enhancement or QOL improvement I'm looking for

 

[FAST6191]

If you are doing it with a cheat then yeah - easier to alter than create something new in most cases. Cheats since... maybe the N64 have had nice check this area, compare it to this number/range, if it is within range then do something else options as well so if you can find something that is unique to shiny pokemon (does not have to officially do with anything, though certainly do look for those, but just something that reliably is a certain value or range when a shiny pokemon is there) you can set something else that is hopefully obvious (does not have to be related to anything, just something you can reliably find the location of).

Tools for assembly then...
Three main lines of tool

1) A disassembler. Takes the code and tries to convert it from the machine readable machine code and into the more human readable assembly code.

2) A debugger. Usually an emulator but can be on hardware for some setups (usually ones that run their own firmware in the background or whatever the devs are using for testing), which does include the 3ds.
These will have breakpoints, ability to view assembly in situ (the code having already been run/set up to run and thus ambiguity that might arise from static disassembly which has no context for the code is less), ability to view memory, cheat searches, graphics viewers, sound setup viewers , maybe some 3d settings viewers, maybe lua support and whatever else the dev cares to include as a useful feature.
I mentioned breakpoints above. Computers in their basic form (modern security can make it a bit quirkier) have three basic things a section can be used for -- reading data, writing data and executing code. Hence the big three types of breakpoint (ever wondered what the pause-break button on the keyboard is actually for/was for in days of old?) being break on read (bpr), break on write (bpw) and break on execute (bpe or sometimes boe). Run to line is a thing in some debuggers and is a special case of break on execute. Some will also allow you to log things instead (if an area is written every cycle but you only care about certain aspects then useful), or put some conditionals on the breakpoint (if data written is between this range).
https://www.romhacking.net/documents/361/ is for the GBA and a command line emulator but covers the basics of what is known as tracing (following data back from landing in memory where say a nice VRAM viewer might see it to the ROM or some place further back where it makes more sense to edit). https://web.archive.org/web/20130215155212/http://labmaster.bios.net.nz/vba-sdl-h/ is said same emulator's usage guide.
The gold star in emulator debuggers is usually given to FCUEX which does the NES as it has all the nicest features. https://fceux.com/web/help/Debugger.html including https://fceux.com/web/help/CodeDataLogger.html but you might not be so lucky for the 3ds.
Some emulators will farm out such things to a popular open source debugging method known as GDB which can in turn be spoken to by stuff like ghidra (one of the big open source tools, your NSA tax dollars hard at work on that one) https://wrongbaud.github.io/posts/ghidra-debugger/ radare2 (the other big open source tool these days) https://book.rada.re/debugger/remote_gdb.html or IDA https://hex-rays.com/ if you are feeling particularly flush (the free versions don't do anything but PC really so your 3ds' ARM stuff needs that, and probably a plugin to handle all the 3ds memory locations. It is one of the better tools out there though).

3) An assembler. Takes your assembly instructions and turns them back into the binary the machine needs to run. Not sure what we are suggesting for this one or if the GBA and DS stuff will do here (I usually use whatever GCC assembler is going with homebrew things like devkitpro but armips https://www.romhacking.net/utilities/635/ also is good stuff, no real need to go find whatever ARM themselves provide but it has historically been a thing). One of the standalone debugging programs, or possibly even the emulators, might allow you to assemble something though.

A list of the instructions and maybe a programming guide or CPU listing (which will not have the memory locations for the console which Nintendo would have decided upon). I have not got anything quite as nice for the 3ds as I do for the GBA and DS (and other older consoles). Though usual places to look are emulators and their source code (by definition they have to know how the device works to emulate it, and emulating it necessarily involves replicating it), homebrew guides ( https://www.3dbrew.org/wiki/Main_Page maybe), interest groups (rare but have been known) and possibly leaked SDKs from the original console maker or similar (back in the 16 bit era and prior they were great for hardware listings, as time wore on then less and less and 3ds is not near the 16 bit era as instead most modern stuff focuses on libraries they provide with a superficial overview of specs and how to code to them).
http://problemkaputt.de/gbatek.htm#3dsreference (one of the main things I would link for the GBA and DS) does have a new section on 3ds stuff that is coming up quite nicely. For the GBA but nice intro to ARM assembly http://www.coranac.com/tonc/text/asm.htm (the 3ds ARM11 has a fair few more features but still related), https://blog.quirk.es/2008/12/things-you-never-wanted-to-know-about.html also has some stuff, http://imrannazar.com/ARM-Opcode-Map is again for older than the 3ds but still good. I would also usually say go look at the first few chapters at least of art of assembly https://www.plantation-productions.com/Webster/ and https://stuff.pypt.lt/ggt80x86a/asm1.htm before returning to the PC, youtube videos are not much good for this sort of thing but has some good stuff for a more gentle introduction, also while it is ancient by today's standards then this amiga video is one of the clearer explanations I have ever seen.
Also I linked cheat making before but might as well have something more here https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial https://doc.kodewerx.org/hacking_nds.html (if that site is down then search for enhacklopedia as there are loads of mirrors around the place) and for the sake of something 3ds then https://github.com/iSharingan/CTRPF-AR-CHEAT-CODES/blob/master/ActionReplayCodeTypes.txt looks reasonable. You want to know the basics of cheat making for it you can find something that happens a result of/alongside the code you actually care about you can work backwards (or in some cases forwards) to the thing you actually care about (does not have to be a cheat -- if the OAM moves a 2d sprite when you jump then one way to get moon gravity as a result of that). Do also learn some of the tricks of the trade for cheats -- don't do the epic side quest to try to make 1 new ultimate end game bonus weapon, go to the first town, give yourself infinite money, buy something, search, buy, search, sell, search... until you find that and the ultimate weapon (and possibly bonus hidden/developer only/cut for being OP) will either be a different identifier (as in item identifier and count, usually seen if you can rearrange your bag) or in a nearby location (this cell is count for this weapon, this cell is count for this weapon and so on and so on). Similar thing applies to characters, stats, levels... Moon gravity was mentioned earlier but one of the main ways is to see if the game has double jump and set to cheat such that the double jump has not been done yet which in turn means you launch into the sky by holding jump/tapping jump.

Anyway I will call that my intro to assembly/debugging in general for today, I do have a bit more and some worked examples in https://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/ as well but again more for the GBA and DS.

Edit. As far as forcing a shiny then I was not thinking you were wanting to as a thing for the final game. As a means to test code out and find suitable things to look at to determine shiny or not in memory to then such a thing would be invaluable -- you can do cheat searches for things that happen 1/255 or 1/some thousands (and you possibly needing multiple thereof) but it is quite tedious, and even more aggravating if you fat finger the wrong search option and have to restart.

 

[impeeza]

So I'm a software developer and I was looking into possibly making some mods for some of my 3DS games. But I can't find a reliable source that gives instructions on how to do it.

So does anyone have a good tutorial or site that I can use to learn about it and try developing mods?

Why this have the tutorial tag of it is a question?

 

[Egoistamamono]

Some games have a mods community like RPG Maker FES. Usually they're create a guide for that.