Resolve properties export option doesn't affect custom property types

[ironpowertga]

I made a new Tileset loader for game lib (Context)

Is your feature request related to a problem? Please describe.
Class Property didn't have children properties if children properties have only default values

example : i add a property to object but i didn't change value

<property name="a" type="class" propertytype="Class0"/>

if i change value :

<property name="a" type="class" propertytype="Class0">
    <properties>
     <property name="v" type="int" value="1"/>
    </properties>

Actualy the only way to know if Class0 have properties request to load .tiled-project. This is bad because, if we load only tileset file, we didn't know the .tiled-project file location so we can't know Class0 properties.

Describe the solution you'd like

Properties with default value need always appear in xml

<property name="a" type="class" propertytype="Class0">
    <properties>
     <property name="v" type="int" value="0"/>
    </properties>

[eishiya]

There is an export option for this in Edit > Preferences, "Resolve object types and properties". Enabling this will make the default values show up in your exported TMX/TSX files.

This is an export option because if the values are always saved in the original map, then they cannot remain unset and thus automatically "update" when the defaults change, defeating the point of having default values in the first place.

---

The wording for this option should probably change now that they're called "classes" and aren't exclusive to objects...

[ironpowertga]

i export my tileset after check Resolve object types and properties, but nothing change

[eishiya]

I just did a quick test, and indeed, resolving classes doesn't work when the values are within a custom property type. I think a better name for this issue might be "Resolve properties export option doesn't affect custom property types".

I suspect this bug is related to #3409 and #3344 - Tiled treats the whole class as a single property for the purposes of updating and apparently resolving, it doesn't yet deal with the internal sub-values of that property. The behaviour needs to be updated.

Until this is fixed, your only option to get the default values is to read them from file (the project, or the property types export). For a large project with many maps, this may actually be a better idea, as it would let you easily update the defaults, and would avoid the need to keep two copies of each map around (working map and export), in addition to the space savings of not storing default values with each map.

[ironpowertga]

Thank you very much

[bitbrain]

I have a question: is there a reason this is labeled as a feature? This is clearly an (export) bug to me.

[ironpowertga]

I have a question: is there a reason this is labeled as a feature? This is clearly an (export) bug to me.

At the beginning, yes. But after the eishiya message it can be change to bug. (can't change the label)

[bjorn]

I have a question: is there a reason this is labeled as a feature? This is clearly an (export) bug to me.

I've changed the label to bug now, though I consider it more of a missing feature. Support for custom classes was only added in the most recent Tiled release, and the "Resolve properties" option has existed for much longer. I agree however that it makes sense for this option to also affect nested class values and will look into making it work that way in the upcoming patch release.

And sorry for the late response, I was on holiday last month.

[qiaohhgz]

I am a self-taught java developer, and I also found this problem. I found that the gray value is the default value through the color and will not appear in the export. The way I temporarily deal with it is not to use the default value, but to copy the object after modification. , it would be best if it can be solved. Sorry for my poor English, I used Google Translate : )