Still, your original point makes sense! What if you want to remove all ships that haven't got a specific role, and one of those adds to a player's bounty in either its death actions or in this.shipDied()?
The relentless wheel of progress marches on...
After 1.73, ship.remove() will have an extra option: if you call ship.remove(true) the ship will vanish without triggering any of its death actions.
However, .remove() ( and .remove(false) ) will still perform the ship's death actions.
The relentless wheel of progress marches on...
After 1.73, ship.remove() will have an extra option: if you call ship.remove(true) the ship will vanish without triggering any of its death actions.
And I was relying on death_actions to remove my timers and other stuff!! We than need another way for triggering cleanup code.
and one of those adds to a player's bounty in either its death actions or in this.shipDied()?
That will fail now also when any other NPC kills that ship or that ship crashed into an asteroid. When it proper checks who killed it, nothing will happen.
And I was relying on death_actions to remove my timers and other stuff!! We than need another way for triggering cleanup code.
Well, normal remove()s wouldn't cause any problems, but if another oxp does a remove(true), then we'd have a difficult to track problem. The error messages would come from your oxp, but another oxp would have caused the errors in the first place. In that case, we'd have to have a warning in the log whenever a remove(true) override is used.
Eric Walch wrote:
That will fail now also when any other NPC kills that ship or that ship crashed into an asteroid. When it proper checks who killed it, nothing will happen.
True, and I probably used the wrong example. But what if another oxp remove()s a random hit contract for whatever reason?
That will fail now also when any other NPC kills that ship or that ship crashed into an asteroid. When it proper checks who killed it, nothing will happen.
True, and I probably used the wrong example. But what if another oxp remove()s a random hit contract for whatever reason?
Hmm, more thinking required!
With any code you will have conflict of interest. But random hits for example is checking who killed it. If it just would be removed, it does nothing.
I think andom hits sets a variable that an NPC has killed the ship. But that is still better that searching for hours for an non existing ship because it could not react on its disappearance.
Problem would be legacy death_actions as they cant check who killed it and may just spawn some debris on death.
Last edited by Eric Walch on Sun Aug 30, 2009 1:14 pm, edited 1 time in total.
Something along the lines of a this.isRemoved event to be triggered when the ship is remove()d, with or without death actions?
That alone would solve quite a few timers problems!
Something like that. But why would an oxp remove things from others! (Sounds like a super weapon) In buoy repair I also remove things but that is always my own stuff and that I can control myself.
Very good question! And it is a super weapon, one that has been there - largely unused - for quite a long time. In other words, the main problem is that - in theory at least - all oxps can add/remove everything from all others!
All the problems we used to have with mission screens were totally unintentional, but they couldn't be fixed until the new methods and events were in place.
Similarly, some oxps death actions might have totally unintended consequences if unintentionally remove()d by another oxp, or it could be even worse if they're removed without death actions. We do need a way to deal with both possibilities, at least that's what it looks like.
Very good question! And it is a super weapon, one that has been there - largely unused - for quite a long time. In other words, the main problem is that - in theory at least - all oxps can add/remove everything from all others!
Oh, I can imagine that this is helpful to free some ressources, or to protect mission ships in early missions. And then removing Uber-ships is a nice option. The next LH has such a mechanism (limits police and hunters if mission is active) and the OXPShipRegulator has already used it - even if it was a special case for Vista users at that time.
Either that or i Would suggest a ship.vanish() function once the feature freeze is lifted..
.
..
