very_bad_soldier wrote:Care to explain this?
Code: Select all
function widget:GetConfigData()
return { buildSpacing = buildSpacing }
end
To be able to add further configuration table entries later?
Pretty much, it also helps a lot if you end up having other versions out that use a different format for the configuration, or have the data in a different format.
For example if you were going to change the format of the buildSpacing data, you could key it as 'buildSpacing2' or something, that way you avoid any conflicts if people downgrade or upgrade as the versions won't be trying to read eachothers data*.
* Note that in the code I gave, the settings table is completely remade from scratch each time, if you want to support downgrading properly then you would remember the loaded settings and append/overwrite the settings used by the current verison, i.e.:
Code: Select all
local loadedSettings = {}
function widget:GetConfigData()
loadedSettings['buildSpacing2'] = buildSpacings
return loadedSettings
end
function widget:SetConfigData(data)
loadedSettings = data
buildSpacings = loadedSettings['buildSpacing2']
end
Which in this case would result in a configuration table being maintained that has both 'buildSpacing' and 'buildSpacing2' keys, so people could downgrade without having had their old settings wiped by the new version. You could also consider having code in the newer versions which attempts to read and update old-format data into the newer format.
DrHash wrote:... and the output it gives is -1, 0, -1, 0, -1, 0... that is, Update is called first and then DrawScreen
:DrawWorld / :DrawScreen / :Update / others are all called in the same function within spring, basically one after the other. As for which one to pick it's generally a 'are-you-drawing?' -> draw callin, otherwise :Update.
Also, I wouldn't recommend trying to use any :CommandsChanged/:MousePress/:KeyDown type stuff to gain efficiency, the gains you'll get will be negligible and you'll just introduce the possibility for bugs. There's widgets that use SetActiveCommand, and other widgets that will block a :CommandNotify and issue the commands with GiveOrderToUnit, both of which result in no callins being fired on other widgets.