You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a simple tileset and two defined object types, with some default properties - Creature, with hit_points = 100 and Terrain, with movecost = 100. Each of the tiles in the tileset is set to belong to one of these two groups.
When exporting either a tileset on its own, or embedded within a map, if the resolve option (in the title) is not selected, each tile will have an exported property type of its appropriate type, as well as any properties of that Object type that aren't at default: so, a creature with hit_points of 300 will have an additional property to specify that it's hit_points are 300, etc.
I assume the expected behavior is that when the aforementioned option is selected, the type property that is usually exported will be replaced with explicit properties, even when their values are default.
Actual behavior
The type property is indeed lost, however so is any other information. Even the ID is not exported.
I've updated tiled to 1.2 from the Manjaro(x64) repo when it became available, not sure if any old information from the previous version might be conflicting with the new and causing this.
This same thing happens whether the tileset is exported on its own, or embedded in a map.
Same results with xml or json exporting.
The actual exported file is about 100 lines shorter with the resolve option selected for me.
I apologize if this is the result of me not understanding the option.
The text was updated successfully, but these errors were encountered:
Thanks for the detailed report! It was as silly mistake on my part to forget to update the Tile::clone function when I added the "type" field to the Tile class.
Oh btw, this "Resolve object types and properties" currently only applies to the actual object instances. It does not currently copy properties from predefined types down to tiles with that type. So, while I guess the bug you reported is fixed, the expected behavior you described is not implemented yet.
In any case I don't think it's a good idea to actually remove the "type" field, but resolving the properties could be implemented. I agree it could be expected behavior, but I was hesitant to copy down properties for both tiles and objects, especially since this could lead to unwanted duplicate information in case of tile objects (which would already get all properties, so there would be no need to look at the properties set on their tile). Do you actually need the properties on the tiles?
I have a simple tileset and two defined object types, with some default properties - Creature, with
hit_points = 100
and Terrain, withmovecost = 100
. Each of the tiles in the tileset is set to belong to one of these two groups.When exporting either a tileset on its own, or embedded within a map, if the resolve option (in the title) is not selected, each tile will have an exported property
type
of its appropriate type, as well as any properties of that Object type that aren't at default: so, a creature with hit_points of 300 will have an additional property to specify that it's hit_points are 300, etc.Example:
Expected behavior
I assume the expected behavior is that when the aforementioned option is selected, the
type
property that is usually exported will be replaced with explicit properties, even when their values are default.Actual behavior
The
type
property is indeed lost, however so is any other information. Even the ID is not exported.Additional info
I've updated tiled to 1.2 from the Manjaro(x64) repo when it became available, not sure if any old information from the previous version might be conflicting with the new and causing this.
This same thing happens whether the tileset is exported on its own, or embedded in a map.
Same results with xml or json exporting.
The actual exported file is about 100 lines shorter with the resolve option selected for me.
I apologize if this is the result of me not understanding the option.
The text was updated successfully, but these errors were encountered: