Let's say version 1.0 doesn't have support for editing the ability data table. Let us further suppose that version 1.1 adds support for the ability data table.
...
Hah, you're right. You only need meta data for identifying the different data tables. Like, <table type="static" name="ability_data"></table>. The editor will then look up where to write this particular table to.
Even better - your friends can start releasing mods for the US release of SGF whilst you're still developing support for the JP version (which has different lookups), but will still be able to apply their American mods to the Japanese release later on, letting the latest version of the editor worry about the different addresses.
Again, newbie non-programmer at work, beware of falling "WTF?" blocks. Yeah, you're right, I just like the simplicity of plain text. You don't have to worry about getting your xml right.
It feels like you could really gain a lot by learning some OOP and functional-programming concepts. There isn't space for a full explanation here, but let me give you an analogy.
You run a restaraunt called Restaurant.exe. In your kitchen you have lots of different chefs - the peelers, who peel; the choppers, who chop; and the fryers, who, uh, fry. Above them all you have the master chefs who manage the production of each particular dish.
Let's say your master chef want to add another dish to the menu - tomato soup. He tells the peeler to peel tomatoes, the chopper to chop them and the fryer to finally fry them. But he doesn't want to go into the nitty gritty of telling them *how*. He shouldn't really need to tell the peeler how to peel tomatoes - the peeler should understand peeling in general, and then apply that technique to whatever ingredient the masterchef specifies. And if new peeling techniques come into play, that's something only the peeler (and the programmer maintaining him) really needs to know about. What should really happen is that the peeling code stays with the peeler, and the chef just passes him a message 'Peel tomatoes / carrots / onions, pronto'.
In OOP terms, the master chef is
abstracted from the process of peeling, and the peeler is
encapsulated - his actions aren't to be directed by anyone else. When writing the master chef's code, we don't have to be able to remember everything there is to know about peeling. When writing peeling code, we don't have to worry about context - just write something that can handle any vegetable. This makes our code for each chef very readable and maintainable.
Thus with chefs, thus with programs. Your enemy editor section shouldn't have to worry about the addresses of each creature's data - it should just have to pass a message to the actual ISO handler. This way, if it turns out you screwed the addresses up, need to support a new release (eg PAL UK) or discover a better way of compressing the data, you don't have to update each and every one of your editors - just the ISO handling component.
There are other benefits to OOP too (like modelling data and associated actions together as 'objects'), but I think abstraction and encapsulation are the ones you'll find most immediately useful.
That's good to know. I was told by other people to learn Scheme, Common Lisp, and Perl.
Odd languages to choose. I'd stick to C++ or maybe even Java if you're getting the low level experience elsewhere.
More newbness - I meant C is good for writing simple command line tools which can be used to do more advanced things with a scripting language.
So are most languages. And pretty much everything lets you put functions in a library and call them in later programs. Besides, object-orientated programming does this 'scripting' intrinsically (think of the master chef 'scripting' the peeler, chopper and fryer).
