The relevant code segment in lime-tile.lua in Tile:create() is the following:
1 2 3 4 5 6 7 8 9 10 11 12 | ... for i=1, #properties, 1 do -- Read in the Config file data if it has one, otherwise it is a normal property if properties[i].name == "configFile" then readInConfigFile(properties[i].value, self) else self:addProperty(properties[i]) end end ... |
Ough... that same code-pattern is used for all the new/create functions for tile/tieset/object,etc.
So if I'm right about this subtle bug, then it requires changes in multiple files.
-FS.
I've made the following change to readInConfigFile() in lime-utils.lua:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | ... if configData then -- Set all the lovely new properties on the object -- First deal with the configFiles before the "normal" props if(configData["configFiles"])then value = configData["configFiles"] for i=0, #value, 1 do readInConfigFile(value[i], object) end end for key, value in pairs(configData) do if key ~= "configFiles" then object:setProperty(key, value) end end if(lime.isDebugModeEnabled()) then print("Lime-Lychee: Loaded Config File - " .. path) end end ... |
Hey, thanks once again for fixing my sillyness :-)
I believe that this issue with not reading-in the config files first before assigning the properties, has been addressed in lime-utils.lua, but not yet in lime-tile.lua (Tile:create) and neither in the other modules that parse the xml-attribute data...
Is that an oversight maybe?
Regards, Frank.
The changes added into 2.9 were last minute changes just to try to stop some of the coercion however I have most likely (as you have now found) missed a few cases. In version 3.0 that is coming out on Friday I have switched it all over to JSON stuff to help remove the need for any coercion.
Sounds good - love big version number changes ;-)
Me too, makes me feel like Lime is progressing really fast :-)