Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[xenoargh]

...needs to be run when a Ship is killed. 

Otherwise, stat-boosting Systems and other global / area effect Systems won't operate as desired (and can have performance problems).  Just thought I'd give a heads-up; in early-dev of my new Repulsor effect, I found I had to write a bit of logic to catch the "dead" state and remove the ship from further consideration.

[Alex]

Systems deactivate when a ship is disabled, so unapply() should be getting called. Like, for example, burn drive turns off when a ship is knocked out. Or are you talking about when a ship is actually destroyed? Even so, unless we're talking about massive overkill that causes an immediate destruction that skips the "disabled" state, unapply() still should be get called...

There's an implicit assumption that the ShipSystemStats script only affects the stats of the ship. A global effect, imo, should be handled via a global combat script that checks whether a particular system is on. Is there an implementation/API reason that makes this impossible?

[silentstormpt]

Happens when your running a script that destroy any husks as soon as a ship.isHusk() == true (with applyDamage() instead of removeEntity()).

[xenoargh]

Even so, unless we're talking about massive overkill that causes an immediate destruction that skips the "disabled" state, unapply() still should be get called...

That would be it; I have written some code that causes ships to have "reactor failures" upon death.  So they're getting removed in 1 frame.

I'm a little leery of using removeEntity(); as I found out with the Repulsor, that tends to create Null Exception problems when things further down the chain execute.  Had to fix 3 other scripts that were expecting getWeapon() to not be null. 

That's sort of a side topic, though. 

Basically, I think that removeEntity() needs to be a queue that operates only when everything else that frame is done, so that we can't have conflicts in terms of expected states during that or the following frames.