O'kay I'm not exactly sure if this is the right place to post this question, but since it involves a bit of development I'm gonna try here.
I've been paying attention to Pokémon games for years, and one thing I have noticed and that has my mind sometimes preocuppied is, as the title mentions, the lack of save-state editors for GenIII (FR/LG/R/S/E).
I've seen a lot of tools for GenII at Zophar I believe, and gor GenIV there is the well known PokéSav, but I've never ever heard of a similar tool for GenIII games.
So I wanted to ask...
Not the technical reasons (I'm aware of them) but the human ones...
I don't think there is there a serious lack of interest in GenIII games already, because of the large amount of tools existing for ROM edition, right? Fro Advance Map to NTME... But nothing for already saved games...
Gen IV party screen (from Bulbagarden Archives).
The Gen III screen presents essentially the same information.
From what I've seen at Bulbapedia, editing the main party and item bag data is not that difficult. All the information is available there and, although the offsets seem to be oriented to VBA savestates, at least the reading part seems to be easily doable.
Actually, just this weekend I picked up the data structures and created a small program in C++ that as of now prints the same party information that the so well known Party Screen provides:
For each Pokémon in the current Party:
Number (from 1 to 6)
Species (the Pokédex index number)
Nickname (except some symbols that have no ASCII equivalent)
Current HP / Max HP
A flag indicating wether the Pokémon is afflicted by a Status (I have yet to isolate the specific status codes)
This all took about 4 hours to complete and ~20 hours to test and debug, by using savestates from LG and E. Seeking of the data is not yet automatic: the program requires the user to input the names of at least the first three Pokémon in the party to find the data, then decode it and present it on screen. It also has another limitations: the first Pokémon in the party can not be a traded one or an egg, and it doesn't distinguish Unown forms, for example.
I'm yet to implement the screens with the individual Pokémon data, but so far I haven't had problems to isolate information such as the ability index (ie.: first, second or only ability of their species, *not* the actual ability codes), item, experience, nature and happiness for each Pokémon; also the list of available *normal* items (no Key Items or TMs) plus their amount, which again requires human input, the Trainer name and money, the current and last map visited, and what battle event was fough last (wild battle or Trainer battle).
The ideal would be to actually work this up to the ability to edit the information of the six Pokémon in the party, for example, but so far I'm happy with it being able to report the data of the current party in a convenient format. Actually, the data is printed and tabulated to a text file with Wiki markup (so party records can be eg.: adapted to Bulbapedia's templates, or uploaded to Wikipedia. Now, who would want to do that...?).
So, with all this, I would simply have to ask the question: am I wasting my time?
I know I am quite far from reaching the working stage of an actual savestate editor for GenIII, and maybe I'll have to content myself with a simple reporter, but so far at least decoding and recollecting the basic information of the game has turned out to be simple.
The program still requires human intelligence to locate and decode the data and I'm afraid I'm not smart enough to remove that limitation; but when I compare my small program to the fact that most searches for Gen III save state editors, be it Google, Yahoo or forums (even here at PC I found only *two* mentions of both "savestate" and "advance"), end with people whining "when will we have a Pokésav for Advance?", then I get the idea that what I'm doing either has not been done before, or no one cares.
I would *really* like to hear comments on whether I should continue with this. As soon as I get to the individual data per Pokémon I will most likely make this tool public. It is programmed in C++ and is a simple console utility; so far no external libraries are used and I haven't actually built the executable for Windows (I'm working under Linux), but with some simple instructions and a the VBA emulator on hand it is easy to work with.