Bug Status [10/4]

[Intercept Games]

Hi all! Welcome back to another K.E.R.B (Kerbal End-users Report Bugs) check-in! 

Apologies for the delay, but we had to ship a hotfix! Release v0.1.4.1 went out last Friday addressing the widely-known Registry Issue - and we also managed to slip-in a major fix to orbital decay! We've seen so many stories from you all sharing how impactful the orbital decay fix has been, but we're also aware of a few remaining minor issues causing more decay. We want this issue GONE so we're investigating them right away.

Wobbly Rockets continues to sit atop the list, but our goal is still to resolve this issue leading up to Science. We do not want your first impressions of our upcoming milestone release to be undermined by a major issue like this. That being said, we want to set the expectation now that we do not expect to majorly address this issue until after the next release v0.1.5. If you're curious about details surrounding the complexity of this issue and potential solutions, check out Nate's recent Dev Chat with David 'Trigger' Tregoning. In addition to that, we'll commit to sharing progress as we get closer to a solution (or solutions!) we feel addresses the core issue.

As always, we appreciate all of you who submit new bug reports, upvote existing reports, and add critical details as replies. We're not only looking at these 20 - every single week we knock out smaller issues thanks to your reports as well.

Thank you!

The KSP Team

p.s. because of the delay, don't expect a K.E.R.B. next week - instead it'll be two weeks from now!

Current Top Issues: 

#	Bug	Status
1	Wobbly Rockets	Experimenting with short-term solutions
2	KSP calculating physics all at once	Investigated. (See Nestor's Post below)
3	Camera Resets Position Map View	Partially fixed. Remaining issues will require some refactor on the camera system.
4	Phantom forces when deploying landing legs/gear	Partially covered by one but needs further investigation. Different bug than we originally thought.
5	No trajectory lines in map view	Unable to repeatedly reproduce, need more info
6	Timewarp under Acceleration stops Engaging Properly after a certain amount of years have passed	Investigating
7	Acceleration During Time Warp Doesn’t Work at Times	Investigating
8	Inconsistent Framerate During Launch	Investigating. Have bugs impacting performance in flight, but unsure if those 100% aligned.
9	Moving a radially attached part with a strut on it, break the game	Two separate issues, one with struts, one with symmetry. Investigating
10	Timewarp is Distorting Planets Visually when Seen from a Tidally Locked Moon	Unable to reproduce, investigating
11	Active Vessel Pulls Craft Close when in Timewarp	Original bug fixed, but found new reproduction related to docking/undocking. Investigating
12	Engine Plate Fairing Respawns after load or switching vessels
13	Reloading a save and switching vessels retracts the LV-2000 Trumpets nozzle	Fixed implemented and verified.
14	Struts: ctrl+z in the VAB renders struts/fuel lines invisible, visual bug	Investigating
15	Surface Collision not even with Terrain Mesh	No reliable reproduction, investigating.
16	SAS does not hold orientation during time warp	Investigating
17	Cannot create/edit a maneuver node when game is paused	Known, investigating solutions for this and other pause-related issues
18	Elliptical Solar Orbits Cause Timewarp Under Acceleration to Stop Producing Thrust	Similar to #6, investigating
19	Planets collide after switching vessels
20	Mirrored airbrakes not deploying correctly	Investigating

Note: this report is not fully representative of the work our team is focused on. This is just to provide insight into our progress on the most concerning issues to our community. Additionally, the lack of a status update does not imply a lack of importance or general progress - we just do not have anything to share at this time.

[nestor]

Number 2 is not really a bug but a side effect of all the calculations that are running in the background and that are needed for future features such as colonies. This will need a mix of optimizations and  adjustments to the plan to be able to have something that can scale with future updates of the game. As with other areas we are exploring both short term improvements and long term solutions to the challenge. 

[Scarecrow71]

@nestor

Is this something that could be optimized by only calculating on objects in the currently focused SOI?  I mean, the objects elsewhere are still there, but not calculated on until you focus on that SOI?

[S_Coriolis]

I sure hope we don't get a Kessler syndrome from all the unfocused crafts slowing down your save so much that you can't launch anything again

[nestor]

For clarification on my post, 

My comment about it not being a bug refers to the fact that this is not something that can be fixed with one change but rather a long term goal of improving perf.

We will fix this but gradually and one step at a time.

[RileyHef]

Not sticking to your own cadence of KERB updates on every other Friday is disappointing. One delay should not impact all future updates, too.

Even more disappointing to me is the word "investigating". 14 of the 20 points mention this word, and 6 of them do not provide any more info other than the word alone! Why do we even have a status column if we are getting so little information?

For a report delayed by 2 full business days (yes, I know it's due to sickness) I expected something a little more... substantial in terms of information.

[TFA3393]

Thank you for this clarification. The first post did have me a little worried. I feel better now. 

7 minutes ago, nestor said:

We will fix this but gradually and one step at a time.

[Strawberry]

Can we get clarification on if the game is simulating every aspect of all crafts at once or just simulating certain aspects like resource flow that are viewed as needed for things like colonies?

[PicoSpace]

I haven't seen #19 yet... that's a whooper!

1 hour ago, Intercept Games said:

19	Planets collide after switching vessels

 

[Nertea]

Hey all, some clarification for #2.  The core contributors to these issues are various gameplay systems (resources, thermal, orbital positioning) that currently run for all parts on all vessels, regardless of how close vehicles are to the player. To be crystal clear, we do not simulate rigidbody physics or perform rendering on parts that are not in the player's influence sphere.  This is contrary to KSP1 which effectively rolls up all these things into a single vessel and doesn't do much when a vessel is 'unloaded'. This is in order to support key features like

• Tracking of resource usage through activities a player may want to run in the background
• Core KSP2 features such as acceleration under timewarp, and specifically acceleration under timewarp while observing another vessel.
• Tracking of resources related to various complex activities as part of colonial features like delivery routes
• Overall, making your vessels behave consistently whether they are close to you or not. This is a key goal we have compared to KSP1

There are a number of improvements we are looking to make as we go forwards because this is a key issue with scalability of saves. Notably, a lot of those features don't exist ingame yet and are coming further down the roadmap. So, our approach is going to be incremental and based on supporting the appropriate set of gameplay features for any given milestone.

One of the things we absolutely are doing for the future (past 0.2.0) is defining specific scenarios for the sizes of ships and saves we want to support as a baseline in each update. That means taking a good hard look at the systems involved in each milestone and putting good, realistic numbers on player vessels, parts, resource consuming parts, resource producing parts and other simulation performance costing items for the engineering team to work towards. We have to scale, and we need to know how much we need to scale.

[Kerbart]

47 minutes ago, PicoSpace said:

I haven't seen #19 yet... that's a whooper!

That'll be a nice loophole to exploit for those Ship X kilogram of ore from A to B missions

[Superfluous J]

2 hours ago, Scarecrow71 said:

@nestor

Is this something that could be optimized by only calculating on objects in the currently focused SOI?  I mean, the objects elsewhere are still there, but not calculated on until you focus on that SOI?

I don't see how, once you have regular interplanetary deliveries being made.

Maybe it could be estimated but then there will be an entire metagame for tricking the estimation calculations.

[DancZer]

 

2 hours ago, Nertea said:

Hey all, some clarification for #2.  The core contributors to these issues are various gameplay systems (resources, thermal, orbital positioning) that currently run for all parts on all vessels, regardless of how close vehicles are to the player. To be crystal clear, we do not simulate rigidbody physics or perform rendering on parts that are not in the player's influence sphere.  This is contrary to KSP1 which effectively rolls up all these things into a single vessel and doesn't do much when a vessel is 'unloaded'. This is in order to support key features like

• Tracking of resource usage through activities a player may want to run in the background
• Core KSP2 features such as acceleration under timewarp, and specifically acceleration under timewarp while observing another vessel.
• Tracking of resources related to various complex activities as part of colonial features like delivery routes
• Overall, making your vessels behave consistently whether they are close to you or not. This is a key goal we have compared to KSP1

There are a number of improvements we are looking to make as we go forwards because this is a key issue with scalability of saves. Notably, a lot of those features don't exist ingame yet and are coming further down the roadmap. So, our approach is going to be incremental and based on supporting the appropriate set of gameplay features for any given milestone.

One of the things we absolutely are doing for the future (past 0.2.0) is defining specific scenarios for the sizes of ships and saves we want to support as a baseline in each update. That means taking a good hard look at the systems involved in each milestone and putting good, realistic numbers on player vessels, parts, resource consuming parts, resource producing parts and other simulation performance costing items for the engineering team to work towards. We have to scale, and we need to know how much we need to scale.

This was very informative! Thank you for sharing it with us! 

[Periple]

There’s lots of room for optimization there I’m sure. You can figure out when you need to simulate things and cull the cases where you don’t, and what are the boundary conditions. You can lower the simulation frequency in lots of cases. Like a craft that’s not under thrust and not close to a body doesn’t need to be simulated but you do need to know when it will approach a body so you can re-evaluate. Thermal or resource equilibrium can be recomputed at a low frequency for craft that aren’t in focus. That sort of thing.

All that needs work and it makes sense to do it as you go with good profiling against defined performance targets. Otherwise it’s likely you’ll be overengineering and optimizing the wrong thing. It happens a lot if you go by intuition alone!

[Vl3d]

Please don't forget about the bugs related to wheels (bad collider boxes, sudden swerving). These really ruin the fun of building and driving rovers - which should be the easiest thing to do as there's no flight required.

Edited October 5, 2023 by Vl3d

[1straycat]

  

3 hours ago, Nertea said:

Hey all, some clarification for #2.  The core contributors to these issues are various gameplay systems (resources, thermal, orbital positioning) that currently run for all parts on all vessels, regardless of how close vehicles are to the player. To be crystal clear, we do not simulate rigidbody physics or perform rendering on parts that are not in the player's influence sphere.  This is contrary to KSP1 which effectively rolls up all these things into a single vessel and doesn't do much when a vessel is 'unloaded'.

 Why does performance degrade so much then in anth's tests?  The vessels in his tests were made of one probe core and a bunch of truss segments to  reduce strain on the resource system. The only resources present are the EC for one command pod  per vessel(10 pods total  in his biggest test), and they weren't changing. Is there some thermal calculation being done despite thermals not being implemented yet? I would struggle to understand there  being separate orbital calculations per part rather than per vessel. What is being calculated, then, if not the physics?

I also find it curious that the way KSP2 frame time scales per anth's tests for parts on different vessels looks very similar to the way they scaled in KSP1 with one x-thousand part vessel rendered in in the scene, per stratzenblitz's benchmarks (and that was with engines running and fuel drain, vs  static truss segment vessels in Anth's tests). 

 

Edited October 5, 2023 by 1straycat

[Ezekiel]

@Periple Is spot on with the suggestions. It's like using LOD for graphics. If what's happening on a vessel is far away from the player, then the player isn't going to see (or care) about what is happening second by second. All they really care about is when they leave the vessel to do something else, they can return later and the vessel's state will logically make sense. So that allows heuristics to be used that substitute the normal simulation while the player is gone, and if the end result is nearly the same as if they sat there and watched, then they won't care (and will be happy about the performance increase in the meantime).

[The Aziz]

6 hours ago, Intercept Games said:

10 Timewarp is Distorting Planets Visually when Seen from a Tidally Locked Moon Unable to reproduce, investigating

This is odd. It happened on something as trivial as Mun landing, shouldn't be hard to reproduce. All it required to happen was a landed craft and high time warp. I'll look into this personally.

Also, one could think that something like a minor graphical issue would go way down on priority list (while there are more pressing issues regarding construction) but there we are, in the top 10.

Edited October 5, 2023 by The Aziz

[Vortygont]

In KERB [9/14] were bugs "Massive framerate drop when looking at planet in low orbit" and "Surface Rendering Fragment Shaders Are Inefficient" and they were merged. But in KERB [10/4] there is only "Inconsistent Framerate During Launch " bug. Its status said:

7 hours ago, Intercept Games said:

Investigating. Have bugs impacting performance in flight, but unsure if those 100% aligned.

These bugs in status description relate to bug "Surface Rendering Fragment Shaders Are Inefficient" or it is for other bugs or it is other bugs + surface rendering. Because I don't understand why "Surface Rendering Fragment Shaders Are Inefficient" disappeared from this KERB and there is no its status

[MarcAbaddon]

3 hours ago, Periple said:

There’s lots of room for optimization there I’m sure. You can figure out when you need to simulate things and cull the cases where you don’t, and what are the boundary conditions. You can lower the simulation frequency in lots of cases. Like a craft that’s not under thrust and not close to a body doesn’t need to be simulated but you do need to know when it will approach a body so you can re-evaluate. Thermal or resource equilibrium can be recomputed at a low frequency for craft that aren’t in focus. That sort of thing.

All that needs work and it makes sense to do it as you go with good profiling against defined performance targets. Otherwise it’s likely you’ll be overengineering and optimizing the wrong thing. It happens a lot if you go by intuition alone!

I agree that there should be a lot of room for optimization here - in fact, I am surprised the impact is currently as high as it is since there is no heating at the moment & if the engines are off there is no resource usage either.  It seems like you'd have to work at it to make the slow-down as large as what we currently observe, which is why people assumed it was due to running physics. Something must be very inefficient in the current implementation. 

This is another blow against the 'colonies and interstellar were almost completely implemented before forced EA' theory that sometimes floats about, as this behavior would make those almost untestable.

On this bug about time warp orientation: 

 I was assuming this is intended behavior or at least known behavior, so it is strange for me to see that it under investigating. But maybe it means investigating to see if it can be improved? It should definitely not be investigation about whether it exists! If it is a bug I would also like to note that thrust under time warp has other issues: for example it behaves incorrectly when thrust is not in line with center of mass by not sending your craft spinning. 

See my old post here:
 

I think there is a fundamental issue to solve here, in that thrust under time warp won't work at all with the current system when you need to rotate the craft, as then you would need the entire physics for the craft to run.

Edited October 5, 2023 by MarcAbaddon

[Alexoff]

Am I missing something or has the Kraken already been slayed? I haven’t launched the game for a long time, now there is no spontaneous disassemble of crafts?

[Alpha_star]

1 hour ago, Alexoff said:

Am I missing something or has the Kraken already been slayed? I haven’t launched the game for a long time, now there is no spontaneous disassemble of crafts?

Maybe, seeing that I have not seen this issue in 0.1.4 and 0.1.4.1. I do encounter this bug in 0.1.3, though. I did not see it in the previous KERB updates, though, so it might as well be present. Be careful, and fly safe.

[mattihase]

probably depends. Last time I had spontaneous dissasembaly that was down to small RCS thrusters spawning midair and I think that one's fixed at the very least.

But other things could cause similar issues.

[Pyritin]

12 hours ago, Intercept Games said:

p.s. because of the delay, don't expect a K.E.R.B. next week - instead it'll be two weeks from now!

Which in IG speak means expect in a month...

Seriously how can something with so little real information NOT be released on time. You sorted the bug report forum by votes and then tossed the word "investigating" next to most of the items for crying out loud... The level of mismanagement this studio has going for it is beyond belief...

[Kerbart]

31 minutes ago, Pyritin said:

Which in IG speak means expect in a month...

Seriously how can something with so little real information NOT be released on time. You sorted the bug report forum by votes and then tossed the word "investigating" next to most of the items for crying out loud... The level of mismanagement this studio has going for it is beyond belief...

Well you have to contact the lead on each bug and get an update. I'm not a professional software engineer and I'd think they'd have a "bug list" with the status that gets updated on a daily basis, but what do I know.