(BUG) KSP2 does NOT unload vessels at range

[JcoolTheShipbuilder]

So I was controlling a station around Dres, and got news that there is water in Vall, and couldnt be bothered to move the mobile station to Jool, so I went to map view, clicked on a craft around Jool, and clicked control. And the game lagged a lot.. but I was now switched to it! yay!

HOWEVER
I was still in control of the dres station, while the jool ship is practically on the other side of the kerbol system.. And I have set persistent debris to 0 once, and with all the debris cleared,  my FPS everywhere dramatically increased...

I am fairly certain that the game does NOT unload vessels at range like KSP2.. it is frustrating when you launch a small little flea on Kerbin and are getting horrible lag from a station around Jool still being loaded. KSP1 has a loading range of about 2.25km by default, and more ships added causes the game to just... take longer to load and take more ram. but in KSP2? The lag in the entire system is based on the number of PARTS in the entire system! This has led to my friend  being unable to play a few days old save due to intense lag.

In my opinion, this is one of the more serious of the bugs and glitches out of all of the ones I have seen...

[Vl3d]

I have also experienced a slow down of the game after launching multiple missions and having a 50 debris around KSC / in orbit.

[Scarecrow71]

This needs to be posted in the Bug Reports sub-forum.

[Gotmachine]

This is not a bug, it's a feature.
The visible, physically interactable with representation of the vessel is not loaded.

However, the core logic will stay loaded, because that's a feature of KSP 2 : vessels are able to use their engines in the background, while unloaded.
To make that work consistently, this mean a large chunk of the core logic is kept running : resource requests and conversions, solar panels, thermodynamics, etc...

This obviously add a lot of overhead, but with a good core architecture, this would have been doable without impacting overall performance too much.
Unfortunately, the way KSP 2 is architectured is absolutely not up to that task, at least in the current state of things.

Edited February 27, 2023 by Gotmachine

[Vanamonde]

Thread moved to (possible) bug reports. 

[Vl3d]

1 hour ago, Gotmachine said:

Unfortunately, the way KSP 2 is architectured is absolutely not up to that task, at least in the current state of things.

Why do you say that?

[Gotmachine]

1 hour ago, Vl3d said:

Why do you say that?

Background processing of unloaded vessels (and other stuff like colonies), assuming they intend the players to be able to have a moderately complex space program going on, entails running a large chunk of the game logic on thousands of entities.
To make that possible without tanking performance, there are only two possible strategies :
- Don't actually run the same game logic and aggregate entities into higher-level abstractions and/or reduce the update rate to cut down computational cost at the expense of simulation precision/coherency.
- Architecture these entities around data-oriented programming paradigms, making the data cache-efficient and allowing to leverage parallelism and SIMD instructions.

As of the current EA release, KSP 2 isn't doing anything like that.
All they have done is to separate the objects game logic from their loaded representation, which is the bare minimum required for the background processing concept to work.
Now, each unloaded vessel/part/partmodule is doing a lot less work than when loaded : no joint physics, no collisions, no visuals to push to the GPU...
But even taking the estimate that each unloaded part does around 5% of what a loaded part does in terms of processing, if for example you have a game with 20 vessels made out of 100 parts, that still is worth the computational cost of 200 loaded parts.

The only thing they can possible do without basically throwing away the whole thing  is to dial down the unloaded vessels update rate, but this has direct consequences on the simulation quality, especially on some subsystem that are time-step sensitive like solar panel evaluation or thermodynamics.
It might be possible given the current architecture to implement some limited parallelism, but currently there is no provision for any of that and it would already require a quite large refactor.

Edited February 27, 2023 by Gotmachine

[Vl3d]

13 hours ago, Gotmachine said:

Background processing of unloaded vessels (and other stuff like colonies), assuming they intend the players to be able to have a moderately complex space program going on, entails running a large chunk of the game logic on thousands of entities.
To make that possible without tanking performance, there are only two possible strategies :
- Don't actually run the same game logic and aggregate entities into higher-level abstractions and/or reduce the update rate to cut down computational cost at the expense of simulation precision/coherency.
- Architecture these entities around data-oriented programming paradigms, making the data cache-efficient and allowing to leverage parallelism and SIMD instructions.

As of the current EA release, KSP 2 isn't doing anything like that.
All they have done is to separate the objects game logic from their loaded representation, which is the bare minimum required for the background processing concept to work.
Now, each unloaded vessel/part/partmodule is doing a lot less work than when loaded : no joint physics, no collisions, no visuals to push to the GPU...
But even taking the estimate that each unloaded part does around 5% of what a loaded part does in terms of processing, if for example you have a game with 20 vessels made out of 100 parts, that still is worth the computational cost of 200 loaded parts.

The only thing they can possible do without basically throwing away the whole thing  is to dial down the unloaded vessels update rate, but this has direct consequences on the simulation quality, especially on some subsystem that are time-step sensitive like solar panel evaluation or thermodynamics.
It might be possible given the current architecture to implement some limited parallelism, but currently there is no provision for any of that and it would already require a quite large refactor.

You didn't answer my question. What sources or evidence are you basing your assumptions on? Because the system is much more complicated than you described.

 

[Gotmachine]

31 minutes ago, Vl3d said:

What sources or evidence are you basing your assumptions on?

Sources and evidences that we aren't allowed to discuss in these forums.

[Fullmetal Analyst]

14 hours ago, Gotmachine said:

Background processing of unloaded vessels (and other stuff like colonies), assuming they intend the players to be able to have a moderately complex space program going on, entails running a large chunk of the game logic on thousands of entities.
To make that possible without tanking performance, there are only two possible strategies :
- Don't actually run the same game logic and aggregate entities into higher-level abstractions and/or reduce the update rate to cut down computational cost at the expense of simulation precision/coherency.
- Architecture these entities around data-oriented programming paradigms, making the data cache-efficient and allowing to leverage parallelism and SIMD instructions.

As of the current EA release, KSP 2 isn't doing anything like that.
All they have done is to separate the objects game logic from their loaded representation, which is the bare minimum required for the background processing concept to work.
Now, each unloaded vessel/part/partmodule is doing a lot less work than when loaded : no joint physics, no collisions, no visuals to push to the GPU...
But even taking the estimate that each unloaded part does around 5% of what a loaded part does in terms of processing, if for example you have a game with 20 vessels made out of 100 parts, that still is worth the computational cost of 200 loaded parts.

The only thing they can possible do without basically throwing away the whole thing  is to dial down the unloaded vessels update rate, but this has direct consequences on the simulation quality, especially on some subsystem that are time-step sensitive like solar panel evaluation or thermodynamics.
It might be possible given the current architecture to implement some limited parallelism, but currently there is no provision for any of that and it would already require a quite large refactor.

absolutely based! 

[Anth]

On 2/28/2023 at 12:54 PM, Gotmachine said:

Background processing of unloaded vessels (and other stuff like colonies), assuming they intend the players to be able to have a moderately complex space program going on, entails running a large chunk of the game logic on thousands of entities.
To make that possible without tanking performance, there are only two possible strategies :
- Don't actually run the same game logic and aggregate entities into higher-level abstractions and/or reduce the update rate to cut down computational cost at the expense of simulation precision/coherency.
- Architecture these entities around data-oriented programming paradigms, making the data cache-efficient and allowing to leverage parallelism and SIMD instructions.

As of the current EA release, KSP 2 isn't doing anything like that.
All they have done is to separate the objects game logic from their loaded representation, which is the bare minimum required for the background processing concept to work.
Now, each unloaded vessel/part/partmodule is doing a lot less work than when loaded : no joint physics, no collisions, no visuals to push to the GPU...
But even taking the estimate that each unloaded part does around 5% of what a loaded part does in terms of processing, if for example you have a game with 20 vessels made out of 100 parts, that still is worth the computational cost of 200 loaded parts.

The only thing they can possible do without basically throwing away the whole thing  is to dial down the unloaded vessels update rate, but this has direct consequences on the simulation quality, especially on some subsystem that are time-step sensitive like solar panel evaluation or thermodynamics.
It might be possible given the current architecture to implement some limited parallelism, but currently there is no provision for any of that and it would already require a quite large refactor.

The is a bug report I did. How if everything is processed all of the time can we ever get good performance...they promised high part counts for KSP2

 

[Gotmachine]

27 minutes ago, Anth12 said:

How if everything is processed all of the time can we ever get good performance...

Well, the only low hanging fruit is the resource request system.
It's one of the main part-count sensitive performance hog, and the current implementation is very, very inefficient.
This is a relatively easy refactor that would have a massive impact, at least if they actually rewrite it with performance first in mind, unlike just patching a few surface issues like they did in the 0.1.1 patch.

But aside from that, they don't have a lot of options.

To give a basic example, in KSP 1, the game doesn't care if your commsat has enough EC generation capacity to keep up with the probe core EC consumption. As long as there was some battery left when you switch away, you're good.
KSP 2 in contrast always do the math of actually generating and consuming EC, even if the vessel is out of physics range.
This is arguably a very nice feature, but they totally failed to build adequate foundations for it to work from a performance perspective, and it will likely get worse once they start adding gameplay elements like heat management and more complex resource chains, because those will be even more demanding from a performance perspective.

Realistically, I don't see them rewriting the whole thing to parallelize it or to take a data-oriented approach.
This is a high effort, high impact refactor of a huge proportion of the codebase that would block their ability to implement any other feature until this is done.
And the required effort gets higher for each feature that get added, so unless this happen very soon, this has no chance of ever happening.
What is in the realm of what can happen is them rate-limiting the thing so only a few vessels are ticked every frame.
This would still require some non-trivial refactoring, but this is the only way they can prevent the general issue that the game performance ceiling is directly proportional to the total part count.
They could also implement some sort of "on rail" state where they don't tick at all some "less important" vessels (ie, non-controllable debris). They might actually be doing this already, but I didn't see it when I looked.

[Anth]

1 hour ago, Gotmachine said:

Well, the only low hanging fruit is the resource request system.

The first part of my bug report had mostly girder segments with a few probe cores to keep the parts from being debris. It shouldn't have taxed the resource system very much at all.

Why would the  resource system need to be applied to the 7993 girder segments? It shouldn't.

[Lisias]

12 hours ago, Anth12 said:

Why would the  resource system need to be applied to the 7993 girder segments? It shouldn't.

Did you had read this Dev Insight? Perhaps it could explain some of these idiosyncrasies...