Map editor shouldn't clobber custom attributes

[stubb]

From @prock-fife on September 29, 2009 2:33

Log from IRC:

[11:25] <or1andov> hmmm, how hard would it be to make the FIFE map editor not truncate instance attributes it doesn't know about? eg they just pass through on load+save
[11:26] <or1andov> i was having a look around the editor + the engine extensions but didn't have any immediate luck
[11:31] <Prock> hmm
[11:31] <or1andov> y'know what i mean
[11:31] <or1andov> ?
[11:31] <Prock> yeah I do
[11:32] <Prock> I think... you want to be able to set some attribues outside of the FIFE map editor and not have the editor clobber those attributes when you save the map
[11:32] <or1andov> exactly

Copied from original issue: fifengine/fifengine#379

[stubb]

From @Beliaar on October 31, 2009 19:21

The only way i can think of to do that would be to keep the xml file in memory and edit in on fly while editing the map. Would probably need to rewrite/change much of the editor code.

Unless someone else has a better idea i'd like to look into this.

[stubb]

From @Beliaar on November 1, 2009 2:41

ok, this is not easily done. Probably better if someone who knows more than me about the editor should look into this.

[stubb]

From @prock-fife on November 20, 2009 9:51

IRC Discussion regarding this ticket. Moving to 0.4.0.

[18:45]  <vtchill> not really sure how we would implement it, and if we should even support it really
[18:46]  <CheeseSucker> we could probably attach a userdata variable to some of the data types in python, but that would be a hack
[18:46]  <vtchill> i think the best we should do is provide an easily plugable saver/loader interface
[18:46]  <CheeseSucker> yep
[18:47]  <vtchill> the only problem with that approach is if a client wants to use 99% of the normal map format.. and just insert a couple of small attributes
[18:47]  <vtchill> then its  a pain to reimplement the parsing of the normal map format
[18:48]  <vtchill> and also cheese, just a heads up i would like to move the map load/save to the engine side, and provide an engine plugin for loading and saving... that way c++ games are supported also through the plugable loader/saver interface
[18:49]  <CheeseSucker> if i remember correctly, you were writing a C++ serializer?
[18:50]  <vtchill> yea it works, but its not in a plugable form... its part of the engine itself
[18:50]  <CheeseSucker> do you notice any performance gain compared to the python ones?
[18:50]  <vtchill> going to basically provide a map serializer dll plugin
[18:51]  <vtchill> eh haven't really don't any testing, but from a small amount of performance stuff i have looked at it is not a ton faster
[18:51]  <CheeseSucker> hehe, ok =)
[18:51]  <CheeseSucker> I suppose most of the heavy code is in C or C++ already
[18:51]  <CheeseSucker> but a C++ serializer would be nice
[18:52]  <CheeseSucker> do you have any thoughts on how the serializer plugin would work?
[18:52]  <vtchill> yea it really wasn't about performance, more about being able to support other languages besides python
[18:52]  <CheeseSucker> I don't have much experience with C++ plugins
[18:52]  <vtchill> it would basically be an external dll (or .so) to fife that would export a MapSerializer interface that would have at least load()/save() functions
[18:53]  <vtchill> and the user must override the functions since they will be pure virtual
[18:53]  <vtchill> we will of course provide a default map serializer
[18:53]  <vtchill> but the user can load their dll instead
[18:54]  <CheeseSucker> would it be possible to override this in python?
[18:55]  <vtchill> we could probably provide a swig interface for it also
[18:55]  <vtchill> i would guess
[18:55]  <vtchill> not 100% sure on that, but it is something to look into
[18:55]  <CheeseSucker> yep 
[18:56]  <vtchill> hope maybe the 0.4.0 release will have some of this in it
[18:56]  <vtchill> and if the python thing works, maybe the clients won't see a huge change from how they load maps now