Gonna add my piece too, as I think a few practical examples of why the decomps are easier to work with would be useful here. It seems to me that a lot of the arguments against using the decomps come from a lack of knowledge (and I don't mean that as an insult - obviously we aren't all programmers, and it can be hard to find good information on this), and a lot of the arguments for it are a little too technical, so that makes binary hacking
seem easier. There's no denying that downloading a map editor and diving straight into changing stuff is faster and easier than setting up the decomp, and there's still value in using that as an entry point to ROM hacking. Plenty of the basic knowledge you pick up from binary hacking even carries over to the decomps, so if you're going in with no idea what you're doing and no programming knowledge at all, that's not a bad way to get your feet wet.
However, in the long run, the decomps are MUCH easier to work with AND more user friendly. No binary hacking tool is even remotely comparable to the ease of use VS code provides, porymap blows advance map out of the water, and working with actual, structured, human-readable code is infinitely easier than working with a binary editor that can't even edit most of the game in a meaningful way. Sure, using the command line for the first time can be quite intimidating, but look at it this way: to set up the decomp, all you're doing is pasting things into a box and pressing enter. If you can post on this forum, you can use the command line. You don't need to be an expert or even fully understand what you're doing; you simply follow a tutorial, just like most of us did/still do with ASM routines! On top of that, you only need to go through it once. After the initial setup you'll be typing "make" the vast majority of the time.
But what if you can't code, and don't care to learn? Consider this: if your hack requires any sort of story change, you're probably going to need to learn to script, which means spending a few hours (or more) reading a scripting tutorial and playing around with some basic scripts. Either way, you ARE going to have to sit down and learn something, so why not learn the thing that will ultimately make your life easier? In the time it takes to go through an XSE tutorial, you could learn enough C to get a good foundation for using the decomps. Again, you don't need to be an expert, and you definitely don't need to know the entire language. Learning just the basics gets you:
- A trainer editor
- A Pokémon editor
- A text editor
- An intro editor
- A move editor
- An ability editor (want to make Blaze's boost apply to everything, all the time, and do 100% more damage? Trivial in the decomps - not so much in binary)
- Much more!
And it's all in one program, with built in find and replace, and all in a simple, human-readable format that allows for extremely quick editing - no more clicking through a billion drop down menus. I assume this is another point where binary hacking seems easier, because it's not immediately obvious how to find all those things in the code. It's a lot easier than you might think - just make VS code find it for you! As an example, let's say you want to edit Youngster Joey's team, but have no idea where it is. Search for "Joey", and look through the names of the files that appears - you'll see "trainer_parties" and "trainers" - Trainer parties sounds promising, so click that and the editor will jump straight to Joey's party, which looks like this:
Code:
static const struct TrainerMonNoItemDefaultMoves sParty_Joey[] = {
{
.iv = 0,
.lvl = 9,
.species = SPECIES_MACHOP,
}
};
That's readable even if you've never seen C before, no? If you want to give him more mons, or custom moves, you can go to other trainers in the same file to see how that should look, then jump straight back to Joey with a single click and make your changes based on that. As this is a text file, you have full access to copy and paste, which make this incredibly quick and easy. VS Code can even autocomplete Pokémon species and moves for you! The code essentially doubles as documentation; it's like using existing XSE scripts as examples for your own, but for the
entire game.
You could also follow this same process to make the silly Blaze change I mentioned: searching for "blaze" leads you to "ABILITY_BLAZE", and searching for that leads you to this code in "battle_util":
Code:
case ABILITY_BLAZE:
if (moveType == TYPE_FIRE && gBattleMons[battlerAtk].hp <= (gBattleMons[battlerAtk].maxHP / 3))
MulModifier(&modifier, UQ_4_12(1.5));
break;
Again, even if you can't code yet, you can see that second line mentions maxHP / 3, so that must be Blaze's activation condition - the mon needs to have one third or less of its max HP. It also mentions moveType == TYPE_FIRE, which you may have guessed, makes it only boost fire moves. So we're in the right place! Get rid of that line make the boost on all the time, and affect all attacks. The next line looks like gibberish, but that 1.5 stands out - that must be the 50% damage boost. Change that to 2.0 and it's now a 100% damage boost. Anyway, the point I'm trying to make is that the decomps are, in fact, user friendly. The reason there are so few GUI tools for them is that they wouldn't be helpful for editing things like this - they'd be restrictive, time wasting, and ultimately end up being more of a hindrance than a help. A program like VS code already does everything they would do, but better.
All that said, if your hack NEEDS Dynamax, you're stuck with binary hacking for the time being, so it's got that going for it! Seriously though, if you're making a big hack, I would highly recommend giving the decomps a serious try before resorting to binary. You
can do it, and it's well worth the effort.
