I'm making a widget that makes use of the new GameSetup() callin. I want to optimise the code in a way that I don't run things in DrawScreen when not really needed. But I can't make it work.

The problem is the sequence of callin call. In this instance, I want to check whether a player has placed his marker on the screen during startup. So I use the MapDrawCmd() or MousePress() callins. It's just that these callins are called before the startposition status has changed, so it makes the user require double clicks, because the first time this callin runs, the player information is still unchanged.

Is there a callin to use for an event that takes place after change of start position information? Or is the standard practise to just shove everything in DrawScreen?

try return true in mouse-click callin so the click is not eaten by the widget.

Ah, still same problem.

If I return true in a mousepress callin, then the click is eaten by that callin, which results in that users cannot place a map position at all.

I don't wanna eat the click, I just wanna do some code when the user clicks.

Don't worry about optimizing the code, simply poll the players start position every time you may be interested in it (In a :Draw_ callin if you are going to be drawing something, or :Update_ for non-drawing work).

A short bug-free widget that is easy to understand and maintain is much better than one that has a negligible performance benefit and relatively complex interactions with users mouse presses/map points/etc.

I tried to put the code in the Update(dt) callin of the gadget, but I reached a maximum packet limit. Btw, it seems that the dt parameter of the callin is nil, so I don't know how to adjust the update frequency.

Some info: this part of the code resides in the unsynced part of a gadget, and it communicates with a widget with a LuaRulesMsg that tells the widget which player has readied up. The optimum place to put this code in would be gadget:MapDrawCmd(), but that not yet implemented it seems (marked FIXME in https://github.com/spring/spring/blob/9 ... adgets.lua). That's why it's a bit cumbersome to put the code in a update/draw callin, because it sends a lot of luarulesmsgs.