Why is script.Killed run after UnitDestroyed?

[smoth]

Why is script.Killed run after UnitDestroyed? It seems to me the order is reversed? I intend on having death animations. Is there perhaps some callin that happens AFTER script.Killed?

[smoth]

According to the chat in #lua, essentially, they are destroyed when their hp is zero, after which killed is triggered, then the long series of events after unit death starts.

should my summary be incorrect, feel free to correct.

It would be nice to have some callin to know if the unit killed has completed and what was returned.

[FireStorm_]

I remember I once asked something similar.

If i was working on it now, i think i'd try to show a death (or falling down) animation, before the unit's health would reach 0.

So I imagine I'd need to set some kind of restrictions, when the unit was falling. So i'd set health to lets say 10 (of a total of 200) as soon as it drops below 10.

The unit then should at least stop being able to move and stop taking commands.

But while not being dead yet, it would still be targeted and/or take fire.
Also line of sight and radar, can still give some info to the player in the final moments of the unit. (imo feature, not bug. )

Only after the death-animation was complete, the health drops to 0 and the unit actually turns into it's feature/corps.

Haven't thought al the angles through, but something like that could work perhaps.

[Beherith]

Yeah, I also experimented with sleep's and delays in the COB killed function, and stuff like the following make me say its not worth it:
unit gets paralyzed, but is still targeted
unit stops, plays the death anim, then its corpse slides a bit
paralysis animation is on these units, along with the health bars

[KDR_11k]

I don't recall units in their death animation being targeted though they will still block bullets. Then again I've been out of the modding game for too long...

If you want a notification that your death anim is complete why not add a manual call to the end of your death anim script?

[Google_Frog]

It's a bit worrying to me that units can still exist after UnitDestroyed. This callin is often used for cleanup so gadgets no longer handle that unitID. I can't think of any places this would cause an issue so far but it is a bit of a worry.

[Kloot]

Steps needed to address this inconsistency:

1) introduce a UnitPreDestroyed(unitID, attackerID) event replacing the current UnitDestroyed(unitID, attackerID)
2) call UnitDestroyed(unitID) (now without attackerID) strictly after Killed finishes

Are you volunteering to fix any and all issues those two simple changes will cause?

[smoth]

Are you volunteering to fix any and all issues those two simple changes will cause?

as in am I willing to go and fix everyone else's code when they can just do a find and replace for UnitDestroyed to UnitPreDestroyed? Why is that is major issue?

[zwzsg]

It's a bit worrying to me that units can still exist after UnitDestroyed. This callin is often used for cleanup so gadgets no longer handle that unitID. I can't think of any places this would cause an issue so far but it is a bit of a worry.

I don't see what problem it causes. The unit is dead already, it just doesn't know it. But everybody else, gadgets and widgets, do. To the contrary, it seems safer this way, as gadgets and widgets can during the death cleanup fetch the unit properties (speed, position, unitdef, experience, etc..) without crashing or getting undefined results.

Steps needed to address this inconsistency:

1) introduce a UnitPreDestroyed(unitID, attackerID) event replacing the current UnitDestroyed(unitID, attackerID)
2) call UnitDestroyed(unitID) (now without attackerID) strictly after Killed finishes

Are you volunteering to fix any and all issues those two simple changes will cause?

1) Keep UnitDestroyed as it is.
2) Introduce new callin, UnitPostDestroyed

There, retro-compatibility preserved, no issues created, no changes required in any mod.

[smoth]

It's a bit worrying to me that units can still exist after UnitDestroyed. This callin is often used for cleanup so gadgets no longer handle that unitID. I can't think of any places this would cause an issue so far but it is a bit of a worry.

I don't see what problem it causes. The unit is dead already, it just doesn't know it. But everybody else, gadgets and widgets, do. To the contrary, it seems safer this way, as gadgets and widgets can during the death cleanup fetch the unit properties (speed, position, unitdef, experience, etc..) without crashing or getting undefined results.

from what i have been told even after killed the unit id is still in use for a bit longer.

[zwzsg]

Indeed, but that's what the OP asked to be removed in the first post.

[smoth]

I am the op, where did I ask that

[zwzsg]

Why is script.Killed run after UnitDestroyed? It seems to me the order is reversed?

Code: Select all

UnitDestroyed
|
| Delay
|
v
script.Killed

But if you reverse the order, then there's no delay after UnitDestroyed!

[smoth]

it isn't about delays, it is about order of opperations. UnitDestroyed is when a lot of stuff is getting cleared out in people's gadgets. I blame ESL issues. It should be UnitDead. Destroyed is what happens when a unit explodes etc. The whole death animation bit means the unit was not *destroyed*.

I ran into a bit of an issue when the unit dies and it's shader would get turned off anyway, yeah.

[knorke]

units (not) firing at dead units:
http://springrts.com/wiki/Modrules.lua#fireAtDead

Is there perhaps some callin that happens AFTER script.Killed?

maybe 'Destroy ' ( ) -> nil
http://springrts.com/wiki/Animation-LuaCallins#Internal

[NeonStorm]

Maybe it depends if the unit script has to be aware of some gadgets.
(e.g: ZK has not only stunned, but slowed/disabled, etc)

Maybe original implemention thoughts were: Gadgets _enhance_ a unit, so enhancements are modular, extern and need to shut down first.
script . . . . killed()