:drooling_face: omg that's literally the best thing ever!
Well it's a good thing I know(ish) C then. I assume this won't be for everyone though. Hopefully my tool won't be obsolete by the time it comes out lol, but maybe I can just repurpose it for c instead of XSE
Damn so literally everything on this forum so far becomes obsolete... but in this case it's a GOOD thing. It's like a brave new frontier all over again! Is every Gen 3 game supported? I'd even be willing to restart my hack! Which has nothing to do with the fact that I have only 20 minutes of playtime so far
That's the spirit! I was afraid your reaction might have been less enthusiastic given my tone, but I'm pleasantly surprised. It is indeed quite a revolution and as you say, basically all this forum has to offer becomes obsolete. But look at it quite differently, all the research and effort put into it helped with the decompilations. :)
Now, to answer some of your questions.
There are three decompilation projects:
- pokeruby, which is almost completed although it lacks some documentation pokeemerald has. It allows you to build a ruby/sapphire 1.0/1.1/1.2 version in both English and German
- pokeemerald, which is catching up to pokeruby in terms of code decompilation but imo beats the other simply because of all the plethora of features
- pokefirered, which currently is in an usubale state and waiting for the two above to finish, then it will probably start
Now, you DO NOT need to know C to make great use of the decompilations. Think of it this way, you don't need to know asm to make a great romhack, right? You may use tools, script, map and use existing routines made by other people. It wil be the same with decomps, except asm changes to C.
The new approach will also have many advantages such as:
- no worrying about ANY pointers. That means you can edit any script, whether yours or the one already existing in the game, modify it, make it longer, shorter at any time and it won't overwrite anything.
- replacing graphics is as I said before as simple as changing one image in a folder to another, no hustle with repoiting things in a hex editor.
- no 'free space' concept. The compiler puts everything at run-time, so you don't have to worry if area 0x800000 - 0x8A00000 is free to use or one of the 10 patches you're using occupies it. Naturally, the 32-MB limit is still there but it is far more than enough space.
There's much more to it, but that's a quick run-down. :D