The Tiled export isn’t actually what Qiso uses. Qiso maps are minimalist for performance and currently don’t incorporate custom properties as such. The Tiled import converts a Tiled map into a Qiso map, and then ignores the Tiled data completely. It does use Tiled custom properties to automate calls to the enablePath() and disablePath() etc functions during this set-up phase, but the actual properties aren’t kept.
There is actually some structure within the Qiso map data that was intended to store per-tile attributes but ended up not being used. It wouldn’t be much work to add a couple of new functions to get/set tile attributes so that you can store properties against individual tiles… But, note that this would be a tile as in a literal x,y coordinate within the world, not as in a sprite which might exist multiple times throughout the world. From your post in the Tiled forum, it sounds like you’re wanting to identify whether a tile contains a building, i.e. a specific sprite, in which case the way you’re already doing it is actually the proper approach, despite the issue of these ID’s changing when you reorder the spritesets within Tiled.
These ID’s actually correspond to the spritesheet files and the sprites within those files so when Tiled changes the gid after you swap the order of the sheets, it’s because the order the spritesheet files need loading in has just swapped around so sheet 1 has to become sheet 2, and sheet 2 has to become sheet 1. The ID’s aren’t decided by Tiled as such, they’re just natural references that all engines can mathematically reverse back to the right images.
We could potentially extend Qiso to internally maintain lists of per-sprite properties and provide lookup functions to see if an individual tile contains a sprite that has a specific property assigned to it, but my gut feeling is that this would unnecessarily bloat the size of the Qiso maps so perhaps wouldn’t be a good idea in terms of the engine being optimised for most uses. You’d still need to pass ID’s when adding sprites to tiles anyway, and these ID’s are still going to change if you swap things around in Tiled. Both of these problems in mind, I’d advise that you instead maintain ID lists within your own code and use those lists for your getTiledData checks and addToTile calls, etc. If you create these lists as nested data tables where the outer table holds a human readable name as a key and the inner table holds the firstgid + ID values of that object, then any time you need to swap the sheets over, you’d just need to do a find+replace on those firstgid references and leave your addToTile() etc calls just adding the two values together to compute proper ID’s. E.g. something like this:
-- Human readable list of sprites sprites = { grass = { firstgid = 1, id = 1 }, hut = { firstgid = 1, id = 2 }, tree = { firstgid = 3, id = 1 } bush = { firstgid = 3, id = 2 } } -- Add a grass sprite to tile 2x2, regardless of where that sprite currently sits qiso.addToTile(2, 2, sprites.grass.firstgid + sprites.grass.id, "ground")
This way, sprites.grass.firstgid + sprites.grass.id will always add up to the correct image and if you move things around, you just have to update those firstgid values accordingly and not worry about your game code.
I’m tired and convinced I’ve messed something up in the above code, but hopefully you understand the concept at least. I believe this approach is what Bjorn means in his paragraph:
So in your game you should generally not use the global ID to associate other information with the tile or to refer to a specific tile. Instead, use the local ID (highlighted in your screenshot) and the tileset if needed to refer a specific tile.
I hope all of this makes sense?
