Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crashing a large vessel into terrain causes many hitches via CollisionEnhancer -> partcountchanged events #263

Open
JonnyOThan opened this issue Oct 13, 2024 · 1 comment
Labels
kspPerformance Possible performance improvement in KSP

Comments

@JonnyOThan
Copy link
Contributor

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?

@JonnyOThan JonnyOThan added the kspPerformance Possible performance improvement in KSP label Oct 13, 2024
@gotmachine
Copy link
Contributor

gotmachine commented Oct 13, 2024

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kspPerformance Possible performance improvement in KSP
Development

No branches or pull requests

2 participants