I have some object types defined, but when the object is created the params are greyed out until changed. The only way to cause them to be written out to the .xml file is to go in and change the value and then change it back to the default. I expected the default values would just become real values when the object is created. Double-click the greyed values to turn them real would be OK, but having to change the values and then back is kind of cumbersome. Is there a quick way to do this?
Works fine here. With single click.
That’s my point. I have to edit a value to get it to stick. If my default value is 5, I have to edit it to 6, then edit it back to 5. 90% of the time I want the default value, so it’s a lot of useless editing.
Is it your assumption that the value will not be used because it is greyed out?
This is not the case: It merely indicates the value is set to its default.
The value is not used. It’s not emitted in the .xml file in the objects block. I have confirmed this several times. It’s not until the values goes from grey to black that it’s emitted in the xml.
Ah, but the default values are stored, namely in the XML of the tileset. It would be folly to save the default values wherever an instance occurs.
My point is, to turn them from grey to black (i.e. stored in the map .xml) should happen with a quick double-click, not a convoluted process of changing a 5 to a 6 and back to a 5.
Could you share your reasoning for doing so?
If you encounter modified values you read those, otherwise you read the default value from the set.
Also, you don’t need to change it to a different value first. You can just type the default value and it will turn from grey to black too. But I still don’t know why you would want to do that, except maybe when you’re about to change the default value and want to keep some objects’ values as they are.
The reason the default values are not saved in the TMX file is to avoid overriding the values defined on the object type. As such, if you’d ever change the values on the object type, any objects for which you have not explicit set other values will automatically take on those new values. This is often desired, because copying the base value all over the place takes additional storage (can be quite a lot if you have a lot of properties and object instances) and it makes changing the default very cumbersome (need to update all occurrences).
Additionally, when I introduced the object types I considered that in most engines, the properties would already have hardcoded defaults. In that case those values in Tiled would reflect what is hardcoded in code, and they would not need to be actually loaded by the game.
However, I understand that in some cases it is useful to define certain non-hardcoded types, but that at the same time you would not want to code another reader for the object types XML file (something you could do however, since you can put that file in your game folder). Recently, I have added the option to resolve the object types and custom properties upon export (not on regular saving). This way, you will find those defaults are also saved to the map file, as long as you use the Export action (and I would suggest you export to a separate file than the file you usually save to - possibly to automate this process with the command-line --export-map and --resolve-types-and-properties options).