fallahn/tmxlite

Support for object types

Eren121 opened this issue · 4 comments

Does tmxlite supports object types rules ?

And also tile property ?

Not sure what you mean by type rules. An object will contain its type string as stored in the map file, available via Object::getType(). The map loader doesn't read the objecttypes.xml file as that's not part of the map, so you'll have to load that yourself.

The tile property of the object is available via Object::getTileID() and optionally Object::getFlipFlags()

I mean that I think that many classes have properties: objects, tilesets, and individual tiles inside tileset.
Was I needed was individual tile properties. But it's ok, I found it under Tileset::Tile::getProperties().

But I thought objects don't have tile IDs, So what is Object::getTileID()?

For object types, yes I mean the default properties, like a class default stored in objecttypes.xml.
Is it planned anytime soon by chance (or will a pull request be considered) ?

I have also another question regarding IDs. I'm uncertain how GID works.
Does every ID returned by tmxlite starts at 1? I know there is like a +1 offset convention in file but only in certain places (in .tsx files, GIDs look like to start at 0, but Tilset::getTiles()[0].ID == 1). I mean there is in the tileset.tsx:

<tile id="0"></tile>

From the Tiled format document:

id: Unique ID of the object. Each object that is placed on a map gets a unique id. Even if an object was deleted, no object gets the same ID. Can not be changed in Tiled. (since Tiled 0.11)

This is the UID returned by Object::getUID()

gid: A reference to a tile. (optional)

This is the GID/global tile ID of the object returned by Object::getTileID()

Tile global tile IDs in Tiled start at 1. 0 represents an empty tile in the map. Each tileset starts at 0, and then the tile IDs in that tileset are added to TileSet::getFirstGID() to return the global ID of the tile in the map. I hope that makes sense. You can read more in the tileset documentation here.

I haven't considered adding support for objecttypes.xml as I've always thought of it as more of an editor config, but I don't see why it couldn't be loaded if it is found in the same path as the current map. It should be trivial to use something like std::unordered_map to map the type strings to the loaded properties. Pull requests are always considered! 😉