This concerns widgets gui_chili_core_selector.lua and unit_auto_reclaim_heal_assist.lua.
Auto Reclaim/Heal/Assist widget causes idle con count to not decrease if con dies
Steps to reproduce:
- Launch a fresh ZK install / have default settings
- Start skirmish, enable Auto Reclaim/Heal/Assist widget
- place commander, plop factory
- Ctrl-K commander
Expected result:
number of idle cons is 0
Actual Result:
number of idle cons ticks to 0 for a moment and immediately goes back to 1
Likely cause:
The auto reclaim widget has a ConController object which keeps track of a given con, and deletes itself when the con dies. The deletion function is ConController.unset, triggered, among other things, by widget:UnitDestroyed:
unset = function(self)
-- Echo("IdleConAssist removed: " .. self.unitID)
GiveOrderToUnit(self.unitID,CMD.STOP, {}, {""},1)
return nil
end,Following liberal use of Spring.Echo, I found that Spring seemingly lets the widget issue an order even to a dead unit, which then triggers the UnitIdle callin (after the order "completes") in the core selector widget, after UnitDestroyed already fired. This creates a ghost idle constructor that will never go away.
Proposed solutions:
a) Make core selector somehow check that the newly idle unit is still alive. (possibly by Spring.GetUnitIsDead?)
b) Stop auto reclaim from issuing orders if unset was called after the unit was destroyed.
c) Engine change to completely block commands to dead units (granted, I'm guessing with this, no idea what really goes on in the engine)
Of these, c) might be cleanest, but i have no idea how difficult that would be, a) is probably more future-proof, and b) seems simplest.
As a) or b) sound like they'd be very simple changes of a few lines, I could do it myself and make a PR, depending on what the preferred solution is.
This concerns widgets
gui_chili_core_selector.luaandunit_auto_reclaim_heal_assist.lua.Auto Reclaim/Heal/Assist widget causes idle con count to not decrease if con dies
Steps to reproduce:
Expected result:
number of idle cons is 0
Actual Result:
number of idle cons ticks to 0 for a moment and immediately goes back to 1
Likely cause:
The auto reclaim widget has a
ConControllerobject which keeps track of a given con, and deletes itself when the con dies. The deletion function isConController.unset, triggered, among other things, bywidget:UnitDestroyed:Following liberal use of Spring.Echo, I found that Spring seemingly lets the widget issue an order even to a dead unit, which then triggers the UnitIdle callin (after the order "completes") in the core selector widget, after UnitDestroyed already fired. This creates a ghost idle constructor that will never go away.
Proposed solutions:
a) Make core selector somehow check that the newly idle unit is still alive. (possibly by
Spring.GetUnitIsDead?)b) Stop auto reclaim from issuing orders if unset was called after the unit was destroyed.
c) Engine change to completely block commands to dead units (granted, I'm guessing with this, no idea what really goes on in the engine)
Of these, c) might be cleanest, but i have no idea how difficult that would be, a) is probably more future-proof, and b) seems simplest.
As a) or b) sound like they'd be very simple changes of a few lines, I could do it myself and make a PR, depending on what the preferred solution is.