The JSON output for gid tile properties of off by one.
You can see in this tileset that the skull tile should have a gid of 5

This is correct in the "data" array:
"data":[0, 0, 0, 5, 0, 0 ... ]
However, it's off by one in the tileproperties
"tileproperties":
{
"4":
{
"name":"skull"
},
},
As you can see, this should be "5"
This is true of all 9.1 versions, up to the current: v0.9.1-223-gb0e29e8
It's not a bug since the IDs used in the tileproperties map are the local IDs of the tiles in the tileset (starting from 0) while the IDs used in the data array are global tile IDs that can span several tilesets (starting from 1, since 0 is used for "no tile").
You can use the "firstgid" property of your tilesets to figure out from which tileset the global ID must be and to map it to a local ID in that tileset (by subtracting the "firstgid"). In the case of a single tileset, you can always just subtract 1 since that's the "firstgid" of the first tileset.
Thank you for explaining that!
Came here for the same thing. Thanks for the explanation.
It's really not intuitive and I'd say it would be better to align and handle the multiple tilesets differently, if it's possible. Because the first thing any programmer (who wants to parse the output) needs to do is to match the tile property id's with the data array.
Just a suggestion.
Anyway, thanks for an awesome tool!
@EskelCz Feel free to make suggestions on how to do it better. However, the current method is probably the most memory efficient way to go about it. Another way would be to store two numbers for each tile, one being the tileset index and the other the local tile id. Though that data structure makes it a little less obvious how to count the tiles, unless you store them as pairs in which case memory usage is much higher.
@EskelCz && @bjorn
Hello, It confused me at first too. But now that I'm working with it, it makes a lot of sense. Also, I understand now that it's a complex problem, and that, bjorn, your solution is probably the simplest. I think using two numbers would add unnecessary complexity.
Now when I'm working with it more, it seems the solution should be something else entirely.
I've tried the recent feature of flipping/mirroring a tile (X and Y keys), which when exported to JSON have these very large IDs that are not represented anywhere in the tileset data. (from the JSON I can't figure out which tile from the set it was)
That makes makes this awesome feature unusable for me and originates from the same basic problem. The JSON doesn't contain a representation (an array) of the tiles unsed internally. It has the tile image but not an array with IDs that could be assotiated with other properties of the tile.
That would make the tilesets independent of the visual representations, which is really my goal, since I'm using the editor as a drawing tool and replacing it with 3d models in my game engine, based on those tile properties.
TLDR: Why not just SAVE the internal tile list that corresponds with the actual map data as well? Then you can make new tiles dynamically and still have a link to the original tileset id.
I don't think keeping an additional list and making new tiles dynamically is a straight-forward solution.
The huge numbers are caused by the use of the higher bits to store the flipping information. It does not make the feature unusable, you just have to read out and clear those bits before proceeding to look up the tileset. This is all documented at https://github.com/bjorn/tiled/wiki/TMX-Map-Format#wiki-tile-flipping
Ah, cool, that's good to hear.
The problem is, in the JSON I'm seeing number 2147483649 for horizontal flip of tile id 1.
I guess there's some translation from int 32 bit integer to float? I guess that's just that I'm not good at math and bit operations. :(
Any idea how I get the 0x80000000 mask and the original tile id from that number? (ideally in javascript so no fancy data types, just double precision floats)
Thanks a ton for any info.
there are no floats/doubles involved.
https://github.com/bjorn/tiled/wiki/TMX-Map-Format
See Tile flipping section for sample code. (Should be roughly translatable to JS)
Now I see it's bit 32 in integer. Somehow I missed the obvious. Thanks
"You can use the "firstgid" property of your tilesets to figure out from which tileset the global ID must be and to map it to a local ID in that tileset (by subtracting the "firstgid"). In the case of a single tileset, you can always just subtract 1 since that's the "firstgid" of the first tileset."
Could someone explain how this is done programatically? Changing firstgid in the JSON doesn't do anything. No mention of this issue in https://github.com/bjorn/tiled/wiki/JSON-Map-Format either
Are we supposed to use terrains since it uses local ID? Or do I need to write a script to edit the data field?
Most helpful comment
It's not a bug since the IDs used in the tileproperties map are the local IDs of the tiles in the tileset (starting from 0) while the IDs used in the data array are global tile IDs that can span several tilesets (starting from 1, since 0 is used for "no tile").
You can use the "firstgid" property of your tilesets to figure out from which tileset the global ID must be and to map it to a local ID in that tileset (by subtracting the "firstgid"). In the case of a single tileset, you can always just subtract 1 since that's the "firstgid" of the first tileset.