nested config files work counterintuitive (?)

Lime
#1

If I understand it well, then in the Lime code, the deepest-nested config file property-setting prevails.

So if I define a tile-property and config files as:

“p”:“a”
configFile: “b.json”

b.json:
“p”:“b”
configFiles: [“c.json”]

c.json:
“p”:“c”

then the property value for “p” is “c” in the running program after all is loaded.

I was expecting the opposite, meaning that higher-up defined props overwrite deeper ones.

My understanding is that the use of config files is to provide generalization - objects can share common settings. You should be able to overwrite properties in a specialized fashion, like the property defined on the tile itself should overwrite the more general defined one in a config file.

Did I misunderstand?
If so, how are the nested config files used?

Thanks, Frank.

[import]uid: 8093 topic_id: 6732 reply_id: 306732[/import]

#2

The change to a property-value overwrite by the higher-level config files seems like an easy one.

In “lime-utils.lua” in the definition for “function readInConfigFile(definition, object)”, the properties defined in the json file are set with:

[lua] object:setProperty(key, value)[/lua]

changing that to:

[lua] if(not object:getPropertyValue(key))then
object:setProperty(key, value)
end[/lua]

would only set the property when it has no value yet.

To reiterate, the proposed change would allow you to maintain default property values in config files where the precedence is determined by first file that sets the value, which results in a Tiled-set property overwrites value set in first level configFile, which would overwrite values set in configFiles, etc. The more specific settings overwrite the more generic ones.
This would give the functionality that I would like to see… which is not necessarily the intended one…:wink:

-FrankS.

[import]uid: 8093 topic_id: 6732 reply_id: 23501[/import]

#3

I personally like the idea of options so would love to offer both of these abilities as they will no doubt both be useful in different circumstances. I am more than happy to update the code with your change if that is what people would prefer until I can come up with a clean way of allowing both. Any ideas?

I could offer a single property that means you either have one option or the other in a map however it would be nice to be able to do it on a per config file/object basis if that wouldn’t get too messy for the workflow. [import]uid: 5833 topic_id: 6732 reply_id: 23535[/import]