The problem is that Tiled exports the file with wrong tile IDs. In Tiled, I use 3 tiles and their IDs are (0-1-2) but in the exported file it shifts the numbers by one, so they become (1-2-3) So the tile with ID=0 never shows and the others appear in the wrong place.
I created different maps and tilesets and always the same result.
PS: The shift only happens in the “data” table
I found a workaround.
I changed the IDs manually for each tile in the exported file. Not in the data table but in each individual tile table.
Hello?! Anyone?!
A map can use several tilesets and the data layer refers to tiles from any of those tilesets, so the IDs so not exactly match. Also, on a layer there is an additional number (0) which means “no tile”. So the first tile in the first tileset is referred to by “global tile ID” 1, even though locally in the tileset it’s the tile with ID 0.
This is explained on the TMX Map Format page. The same mechanism is used in the TMX, JSON and Lua formats written by Tiled.
A bit impatient, maybe?
I don’t understand, is this an intentional bug?! The result of what you said made the map appear incorrectly in my project and I had to create my own function to shift the IDs by one.
If the IDs start at 0 and the data table start at 1 then this is a project breaking bug and should be fixed. That’s is as far as my understanding.
It’s not a bug, it’s the intended behavior. I tried to explain to you why it behaves that way, and that you’re comparing local tile IDs to global tile IDs, even though they are not the same thing.
Each tileset specifies the global ID of its first tile as the “firstgid” property. As you can read in the documentation, you can use that number to determine which tileset a certain global tile ID is referring to, and then by subtracting the “firstgid” value, you get the local tile ID of the tile in that tileset.
Of course, you can also set up a look table based on the referenced tilesets so that you can look up the tiles by their global ID directly. However, you will need to add the value of the “firstgid” property to each tile ID before added the tile to the lookup table.
I still can’t wrap my head around why exactly didn’t the map appear correctly. Here is the situation:
Questions:
One more thing:
When I add custom properties to an object in the tileset(.tsx), they appear greyed out in the map file(.tmx) they don’t show in the exported .lua file. the “properties” table becomes empty. I have to manually click on each property even if I don’t intend to change it in order to make get written in the .lua exported file. The same exact thing with the “name” field. The “type” field on the other hand never gets written into the .lua file even if I manually changed it in the map file.
Do all these weird problems supposed to be the intended behavior?!
Yes, this too is intended behavior. Default values can be written to file when exporting using the Resolve object types and properties option.
See also this topic:
This makes much more sense now.
When you visually see something in Tiled but then it doesn’t get written in the file this means it’s a bug. If it’s intended behaviour then it should just not exist unless the user wants it to, this would indicate that it’s how it’s supposed to work.
-Greying stuff out indicates that it’s not possible to edit at all.
-Making stuff appear in normal font indicates it’s the default and if the user edits it then maybe it turns to a different colour or maybe gets bold.
Just my opinion though.
One might argue they’re greyed out because their writing-to-file is disabled.
Now that you know you’ll probably get used to it pretty fast. I assume there’s people that prefer a less distracting greying out as well as others that would rather see bold modified values.
@bjorn Maybe the name of the property should not be greyed out while default values are? Although thinking that makes me realize there’s string properties too, which may be empty by default. Therefor you’d need the style of the property name to reflect its defaultness.
@Abdo23 Are you in favor of making the property name bold as well when the value is non-default?
One might not.
Let me explain:
Most of the problems I’ve mentioned here (no tall of them) were due to some questionable UI choices, which in turn makes the “User Experience” a bit poor.
“User Interface” is how an app or a website communicates visually with its user, it’s a language in itself.
I would like you to fire up any other app you have and if you found a greyed out property then try and edit it. You will instantly realise that it’s a no-go for editing and that’s how the app is communicating this information with you. Not only apps but you can sometimes find that on web forms too, for example, if a web forum doesn’t allow you to change your username. It’s a common UI practice.
The problem here is not only that you have a greyed out property that a normal person would think he just can’t edit ( due to common practice ), but also it does not get exported when it’s obvious that it should ( because it’s placed where every other similar property does), which is a huge red flag from a UI/UX perspective, hence why at first I thought it was a bug and was massively surprised when I realised that it is how it’s supposed to work.
One simple way to solve this is by having the property greyed out and uneditable of course, but also have some sort of a radio button beside it and when the user clicks on that radio button it would change to the normal font and color, then the user would know that this property is now activated. Also, in general, every default property whether greyed out or not should be exported because that’s also what a normal person would expect I can also provide some example of that if needed.
I’m abnormal. Why would you save default values everywhere? It makes no sense from an information theory perspective.
Let’s take a programming example:
When you create a class ‘Car’ and set a property called name and give it a default value of car:
class Car {
string name = “car”
}
You would normally expect that every instance of that class would inherit that property and that it would get the default value “car” isn’t this true? isn’t this what a normal person would expect?
Let’s take an example from Unirt3D:
When you create a prefab ( something like an object in Tiled) and you attach a script to that prefab and give it a property with a default value, you would also expect that every instance of that prefab would get that property along with its default value.
In any kind of practice where you get to create multiple instances of an object, those instances should by “default” inherit all properties/attributes/feature of that parent object. Hence the name “default”
Tiled shows in the editor that this object indeed gets this property but doesn’t actually export it unless you click on it even if you do not intend to change that property’s value which is just wrong on so many levels and we talked about this a little above.
If there is some technical reason behind not giving an object’s properties to its instances unless the user specifically requests it, then the creator of Tiled should have taken an entirely different approach than having this kind of Object/Instance relation that the user would expect to behave in a certain common way.
I’d initialize the name of a Car as “car”. The default value from the tileset would not even be used outside Tiled, they would merely reflect programmatic defaults. Additionally values absent from read files would not need to be checked for defaultness. Where default values are needed after all they can be read from the tileset. This keeps files significantly smaller in some cases.
I don’t really care for any of this, this is a technical issue that it’s up to the creator to solve it in a clear and meaningful way. What I care about is as I mentioned above:
Tiled shows in the editor that this object indeed gets this property but doesn’t actually export it unless you click on it even if you do not intend to change that property’s value
If I can visually see that the instance has a property (default or not), then I should (by default) be able to access that property via code without having to touch it in the editor, otherwise, don’t show it to me or even introduce that kind of Object/Instance relationship because that kind of execution defeats the purpose. You can’t just choose which properties to export and which to not at your own amusement (I’m talking about the “type” property too)
This keeps files significantly smaller in some cases.
It should be about functionality and common sense not what’s easiest to program.
You can, through the tileset. (or the export option I mentioned earlier of course)
Avoiding duplicate data is common sense.
Then the creator should put all the property related code in one area or the other and not divide it on both.
I’m going to try to explain this issue one last time because I can’t just keep repeating myself over and over.
There is a section in Tiled called “Custom Properties” this section contains elements that all share the same functionality ( which adding extra data to each object ) therefore they all should have the exact same behaviour. Giving the user access to few of them one way, and a different way for the others is called "Inconsistency " and “Inconsistency” is always bad no matter what.
The common sense here is if you can access/edit/change one of those elements in a certain way then you should be able to that to all of them in the exact same way. This is the approach that the creator of Tiled should base his code on. Duplicating code or not is not the user’s problem, it’s the programmer’s problem and he should solve it in a way that keeps the app consistent and doesn’t break the experience of working with it.
I would advise you to start reading a bit about UI/UX even though most of what I mentioned here is pure common sense and common practice.
I know how you feel.
The inconsistencies are relative to your expectations. Maybe try sleeping on it.