Update repairer consumption when a unit dies

[aeoncleanse]

Addresses #642

This fix is ready, but not perfect. The build bar state persists until the unit's self:Destroy() is called, so if anyone has an idea how to do that, please help out. @Crotalus?

This whole situation is a mess. For some reason, calling self:Destroy tells any repairing/capturing/assisting units to go to idle etc, or to the next thing on the queue, but self:Kill() does not. It simply links you to OnKilled in the lua, and appears to do engine checks for the unit's own consumption/building state, and for units in the guard state (Assisters), but ignores repairs.

However, since in the lua we sometimes hook into OnKilled with a long-lasting explosion, the delay between OnKilled and the final self:Destroy at the end of the sequence can be lengthy in some cases (UEF Quantum Gate, for example), with the Engineer continuing to repair and waste resources right to the end.

[Sheeo]

Please perform style changes like this in a seperate commit.

[Sheeo]

This fix is ready, but not perfect. The build bar state persists until the unit's self:Destroy() is called, so if anyone has an idea how to do that, please help out. @Crotalus?

This whole situation is a mess. For some reason, calling self:Destroy tells any repairing/capturing/assisting units to go to idle etc, or to the next thing on the queue, but self:Kill() does not. It simply links you to OnKilled in the lua, and appears to do engine checks for the unit's own consumption/building state, and for units in the guard state (Assisters), but ignores repairs.

You can't control unit order queues from lua, so unless you want to call Destroy() immediately (To invalidate the focus entity for the assister/repairer), there is no obvious workaround.

Overall I don't think this patch adds much except for additional mud to the pile that is repairing/assisting/consumption. I prefer a full rework of these odd algorithms that are in place.

The iteration of nearby ally units with Repairing state is highly suspicious, for one.

[aeoncleanse]

I dont much like it either, but its a fairly major resource waste bug, and aside from being ugly this does fix it. If someone can find how to turn off the progress bar we are golden

[quark036]

What if we sent the engi a move command to its current location?

[Sheeo]

You would need to issue a clearcommand first, which kills the order queue entirely -- since you can't introspect it within the sim, you can't reliably reconstruct it, unfortunately.

[aeoncleanse]

Well, that was easier to get working than I thought. Thanks Sheeo, Chris, for putting me onto IssueClearCommands() :D

[ChrisKitching]

You can't control unit order queues from lua, so unless you want to call Destroy() immediately (To invalidate the focus entity for the assister/repairer), there is no obvious workaround.

This is probably the only way to actually handle this from lua: immediately destroy the unit and spawn an identical one with zero health in its place (which just does the whole blowing-up animation and so on).
We can't reach into native-code to manipulate the order queue, but orders referring to destroyed entities are dropped from the queue when reached.

There is likely a meaningful performance cost associated with doing this. I really don't think this bug is worth fixing for now.

[quark036]

We could do it only for shields, as they are the most significant case (long death animation, likely to be being repaired).

[aeoncleanse]

OK so, in this state we sit at:

The buildbeam turns off
The turret swings back, a little forced and fast but not a problem IMO
The build progress bar does NOT reset immediately
The unit doesn't move on to the next task until the death is completed

As you can see, it's possible to harvest the command table for the unit. However, I don't see any way to re-issue it in an identical state. We can issue individual commands, but not the queue for some reason. If we could, we could clear the queue then immediately re-issue it, and trust the engine to recognise the unit at the top of the list is dead now.

[Sheeo]

Needs rebase targeting debelop