custom node attributes would be deleted on save about tiled

[bjorn]

Hmm, keeping arbitrary attributes alive after loading/saving isn't exactly trivial to implement, unless you only do it in a very limited scope.

Can you explain why you can't use properties instead?

[Hakkeduster]

Ok, heres a example of a actual usage problem. We using one object layer to add waypoints for pathfinding. We have arround 1000+ in one map and loading each one with properties would consume time as also adding a buch of overhead to the file. Here we have added an id attribute that we can fast read and use it to ident the object/waypoint. This we also using on other onject layers to have a file spanning object id for each.

Another problem for the issue are the properties itself, as we using a type attribute like at the object.

I would normaly have just asked for these two additions, but as i don't know if it would be usable for others i have generalised the issue.

[bjorn]

Did you time or measure the difference in execution speed or storage space used with thousands of objects that have an id attribute as opposed to an id property? Is the difference really significant?

About property types. Do you mean storing whether the property is a 'string', 'integer', etc? I think that would be a good feature to support, though probably best after we move on to a nicer property editor.

[Hakkeduster]

The measurement depends on the target system. On a desktop pc with much power it isn't a problem, but on devices with limited resources like mobile phones or netbooks the performance drops noticeable. Especially if there would be additional calculations be done to process the loaded data in the background. As example the test i did on a netbook ended in loading the map for about 15+ seconds (limited memory management and speed) where using just the attribute just took 3 seconds.

I think the general storing of any attribute would really be overkill, and maybe just worth it if some more would really need it. But at general a object id as attribute to have a unique auto incrementing identifier would be nice to have. As I think this could help many to store and handle the objects after loading without giving all objects a different name.

Yes that was the intention on the property to have it store the type of the value as addition to be on the save side.

[bjorn]

Alright, thanks for the explanation. I wouldn't really mind associating an optional integer id with the objects.

One final question I have is why you need to store these object id's in the XML file. Do you refer to these objects by id from another place, and thus need them to stay stable?

Note that for optimizing load time it would probably be better to skip the whole XML business altogether, and write an exporter for a binary format optimized for your use-case.

[Hakkeduster]

The object id is in this case used to connect waypoint objects to other ones, and for this it needs to be stable. There were two versions I am using at the moment, one is that on first load it calculates the connections and the second is that the connections where manually set. On both versions the connections are stored as properties in the object and if they wouldn’t have a stable id the connections would be blown up. It could be archived by using different names for the objects, but at the view of usability and production it would add a bunch of additional work for the map creator to keep track of all the objects manually.

Yeah, I thought about it earlier but didn’t have done it as while development the xml is still needed. But if the load times wouldn’t get better there is no way around to write a binary format.

[bjorn]

I've created issues #13 and #14 to cover unique ids for objects and property types respectively.

Closing this one, since I prefer those specific solutions to the rather complicated solution that would be required to preserve arbitrary element attributes in the map file.

[bjorn]

Just a final note. If you have a deadline on your project and need this feature sooner rather than later, don't hesitate to fork Tiled and patch it up to your needs. At least the low-level requirement of making these specific attributes persistent shouldn't be very hard.

It's just a hobby project of mine, though a donation for my time can of course change my priorities. :)