Persistent build spacing - Page 2

Persistent build spacing

Discuss Lua based Spring scripts (LuaUI widgets, mission scripts, gaia scripts, mod-rules scripts, scripted keybindings, etc...)

Moderator: Moderators

User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6240
Joined: 29 Apr 2005, 01:14

Re: Persistent build spacing

Post by FLOZi »

DrHash wrote:Indeed, gui_persistent_build_spacing.lua requires only to catch 2 events:

- The player has clicked on a building icon or pressed a building keystroke -> change buildspacing to the last stored value for the selected building.

However, I have not seen a specific callin function for the first case, so I used DrawScreen as done in widget gui_context_build.lua (http://widgets.springrts.de/index.php#134)
KeyPress()
KeyRelease()
MousePress()
MouseRelease()

?
DrHash
Posts: 18
Joined: 07 Sep 2011, 00:30

Re: Persistent build spacing

Post by DrHash »

Yes, in the first version I caught key and mouse events, but then each player should modify the widget depending on his uikeys.txt and widgets modifying mouse behavior. The current version does not depend on a particular keystroke/mouse configuration. The callin function I would need should be called when we choose to build a building, but we are yet to place it on the map. Callin "CommandNotify" is called when the building is placed. Up to now, the widget monitors changes in the value returned by function GetActiveCommand. Of course, it would be more efficient to use a callin function that catches such changes (any ideas?).
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6240
Joined: 29 Apr 2005, 01:14

Re: Persistent build spacing

Post by FLOZi »

But if you used those instead of Update you are already way ahead, even if you check on every single click/press.

But anyway, niobium is right \o/.
DrHash
Posts: 18
Joined: 07 Sep 2011, 00:30

Re: Persistent build spacing

Post by DrHash »

Avoiding the need for modifying the widget depending on the configuration of each user is a requirement for bundling the widget with the games. With respect to which function is less called, DrawScreen or Update, it seems the answer is they are equally called; I tested the following code...

Code: Select all

local drawOrUpdates = 0

function widget:DrawScreen()
  drawOrUpdates = drawUpdates + 1
  Spring.Echo(drawUpdates)
end
function widget:Update()
  drawOrUpdates = drawUpdates - 1
  Spring.Echo(drawUpdates)
end
... and the output it gives is -1, 0, -1, 0, -1, 0... that is, Update is called first and then DrawScreen
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6240
Joined: 29 Apr 2005, 01:14

Re: Persistent build spacing

Post by FLOZi »

Which is why i'm saying you can use mouseclick or keypress as they will be called less, even if you perform the check for ALL keyboard/mouse input, without checks that the input is actually involving building; your argument about user configuration is missing the point I am making entirely.

edit: And yeah, as I said, Niobium solved all problems already anyway. All hail Niobium :-)
Last edited by FLOZi on 09 Sep 2011, 17:11, edited 1 time in total.
User avatar
Niobium
Posts: 456
Joined: 07 Dec 2008, 02:35

Re: Persistent build spacing

Post by Niobium »

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.
DrHash
Posts: 18
Joined: 07 Sep 2011, 00:30

Re: Persistent build spacing

Post by DrHash »

Statements such as

Code: Select all

return x = x
make me crazy... assign x to x and return x? For me this is equivalent to just writing

Code: Select all

return x
I guess in Lua this has some special meaning, please enlighten me.

Also this statement is confusing:

Code: Select all

x = y or z or t
It seems this means to assign to x the value of the first variable in the list "y, z, t" that may not be evaluated as false, but if I really want to interpret y, z and t as booleans and I want to assign x the result of the boolean expression "y or z or t"? That is, a true or false value... Perhaps I should then force a type casting? Something like

Code: Select all

x = toboolean(y) or toboolean(z) or toboolean(t)
User avatar
TheFatController
Balanced Annihilation Developer
Posts: 1177
Joined: 10 Dec 2006, 18:46

Re: Persistent build spacing

Post by TheFatController »

DrHash wrote:Statements such as

Code: Select all

return x = x
make me crazy... assign x to x and return x? For me this is equivalent to just writing

Code: Select all

return x
I guess in Lua this has some special meaning, please enlighten me.
It was actually

Code: Select all

return { x = x }
Which is return a new table with the index 'x' set to the value of the global variable 'x'

DrHash wrote:Also this statement is confusing:

Code: Select all

x = y or z or t
It means set x to the value of y, unless y is null in which case set it to z, unless z is null in which case set it to t
User avatar
Niobium
Posts: 456
Joined: 07 Dec 2008, 02:35

Re: Persistent build spacing

Post by Niobium »

DrHash wrote:Statements such as

Code: Select all

return x = x
make me crazy... assign x to x and return x?
...
I guess in Lua this has some special meaning, please enlighten me.
The following lines are equivalent, basically the left side gets treated as a string unless it is in []

Code: Select all

return { xyz = xyz }
return { ['xyz'] = xyz }
Which is similar to how these are equivalent:

Code: Select all

return table.xyz
return table['xyz']
I agree that "{ buildSpacing = buildSpacing }" is pretty confusing, so I'd probably go with:

Code: Select all

return {
    ['spacings'] = buildSpacings,
}
Which makes the key explicit, and removes confusion over whether it is a string or an object. Alternatively you could declare an empty table, build it up entry-by-entry using more common syntax, then return it.
Post Reply

Return to “Lua Scripts”