You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Not really sure if there's a silver bullet here, but many things don't need to respond more than once per frame to this event. It's probably not feasible to suppress all of the events and then fire one at the end but...maybe?
The text was updated successfully, but these errors were encountered:
That event is barely used in stock, and I would argue that using that event (that one and the even worst ones, onVesselStandardModification and onVesselWasModified) is bad practice anyway.
Whatever the reason is, using those "catch-all" events invariably lead to redundant/useless computations being done, and often to bugs, as the state of the vessel/parts is inconsistent depending on the actual reason this was called.
I don't think it's actually feasible to aggregate and delay sending such events, as once all is said and done in the frame, the vessels they are about may not even exist anymore.
I guess in that case we could send them earlier, before Vessel.Die() is called.
But even so, it feels like a bad idea. When to send them ? From Update ? From FixedUpdate ? Those events can originate from any place and time, and not matter what we do, there will inevitably be stuff that will be executing in between the origin of the event and the moment we send them. Given that most use cases involve patterns of parts keeping references to other parts, I don't see how that couldn't end up in a nullref exception festival...
Not really sure if there's a silver bullet here, but many things don't need to respond more than once per frame to this event. It's probably not feasible to suppress all of the events and then fire one at the end but...maybe?
The text was updated successfully, but these errors were encountered: