ToME WikiSimply put, I think that we should move to XML or some other easily-read format for the savefiles. About the only reason I see *against* this (aside from that we'd have to rewrite the load/save code) is that it makes cheating a bit easier, which I see as no big loss. On the flip side, I believe there are many things that having a standard text-based savefile format would make considerably easier.
DarkGod: "aside" from rewriting the whole save.loading code ? heh .. It's not broken, it even works extremely well, why change it ? And why using xml for data files when we have lua(which is great at describing data)? How do you include code in xml ? a specia ltag that contains lua ? might as well use lua directly 
I do realized xml is very buzzwordy but it is also profoundly useless in many cases.. Tell us what would be achieved by using it? Maybe it can be done otherwise
Derakon: Lua would be fine too; I suggested XML mainly because it's a well-known plaintext way of encoding data. Mainly I just don't like dealing with binary filetypes in this age of massive storage space. They're very fragile to work with and require a lot of work to parse. The current (2.3.4) savefiles are binary; I don't know if you've changed the format for ToME 3 or not; if you have and it's easier to work with than binary, then by all means, ignore me!
As for what can be accomplished with a different file format, the big thing I see is making the savefiles easily extensible by module writers. Say you have a module writer who wants to include a seventh basic stat, or an extra "skill" (like Saving Throw, Perception, et cetera); if you have an easily-modified savefile format, then either they can do it themselves, or alternatively it becomes nigh-trivial to write the functions needed to add such stats to the savefile. With binary file formats, though, making such modifications becomes very difficult. In fact, it's easier in that case for the module writer to create a second "savefile" that contains the information that the module writer wants to store, but then you have two files when you could just have one; why bother?
I don't think that this is a crucial feature, no, but I do think it'd be nice to have, and will prove its worth once we have it.
KitaKita: Personally, I don't like the idea of easily editable save files. XML is just a text format, after all.
Derakon: Assuming you had the choice between two equally effective savefile formats, one binary and one text, why would you choose binary over text? The only reasons I can think of are a) to save space (pointless in this day and age), and b) to obfuscate the format so it's harder to modify (also pointless, given the myriad undetectable ways to cheat in ToME). So what's wrong with easily-editable savefiles?
NeilStevens: That sounds like a pain for the users to me actually. If you want to make save compatibility, do it right.
Derakon: Done right, this shouldn't affect the users in the slightest, except in that their savefiles wouldn't be compatible with the previous version of the engine. I think that if we want modules to be able to change the concept of what a player is, then they'll need to be able to modify the savefile, potentially in ways we haven't thought of. XML is a natural way to do this, though there are plenty of others. What we certainly don't want the module writers to have to do is read and write binary files in Lua. That's just painful. And yes, this does have the potential to break savefile compatibility between modules. Is keeping compatibility there really desirable, though? Modules are essentially different games anyway. I don't expect my ZAngband save to work in OAngband.
BucketMan: You can do this with the T-engine right now. It's not a problem. Dragonball T has seven stats. Bone to be Wild replaces experience with three types of souls that you steal from your fallen foes. Bard's Tale has a class system that allows progression in each of ten different classes concurrently. No need to directly access save files for any of this. Why not download the latest alpha and experiemnt with it? You might be pleasantly surprised with what it can do.
DarkGod: Indeed. As BucketMan said the engine already allows all this kind of stuff without any problems add_loadsave("foo", default) is all that is required to add new stuff to the savefile, if 'foo' is an array it even automagically detects all its contents and save them accordingly to their type. BTW, savefile compatibility between modules has never been assured and never will be
Derakon: All right then, feel free to ignore me. I apologize for wasting everyone's time.
DarkGod: I never ignore people But in this case there is just no need to change :=)