[1.8 - 1.12] KSPCommunityFixes - Bugfixes and QoL tweaks

[Gotmachine]

12 hours ago, dok_377 said:

It's not my computer, it's KSP being a piece of trash.

That's a strong statement.

It's extremely difficult to make reliable performance measurements between different runs without automated benchmarks that reproduce exactly the same configuration and sequence of inputs.
This being said, I'm somewhat able to reproduce what you're seeing, although not as dramatic as the 27% FPS difference you're showing in your screenshot.

Using your craft file, I can reliably measure a 4-5ms per frame overhead on KSP 1.12 vs 1.10 (for a frame time of ~45ms). In practice, this mean a 0 to 20% drop in terms of FPS, depending on the baseline.
This can partly be explained by new features. With your craft, Part.FixedUpdate() call time has jumped from ~0.65 ms/frame to ~1.22 ms/frame due to the new kerbal mass system.
There are likely a few other methods that increased in complexity slightly, resulting in some fixed overhead in newer KSP versions.

More surprising, there is also a consistent and repeatable overhead (about 5% overall) in many top level method calls, including methods that haven't changed at all between KSP 1.10 and 1.12.
I'm not sure how to explain this apart from some global regression at the Mono/Unity level when KSP was upgraded to Unity 2019.4.18 for the 1.12.0 update.

[dok_377]

27 minutes ago, Gotmachine said:

It's extremely difficult to make reliable performance measurements between different runs without automated benchmarks that reproduce exactly the same configuration and sequence of inputs.

I did whatever I could to make it as accurate as possible. Both versions were downloaded freshly from Steam, both were started cold after I restarted my computer, went straight into the same flight scene through the same sequence of buttons in the game under the same circumstances from the same hard drive. Everything else was outside my control AFAIK. Today I even went all in and made a fresh Windows install, just to see what will happen. It did improve the fps slightly (added like 3-5 fps), not much to care though.  

Judging by the rest of the text, I was at least partially right. 1.12 is in fact more performance heavy than 1.10. In a building game where performance relies heavily on the number of parts you use, the more performance you have "in storage" - the better. Losing up to 20% fps is just not something that I want to have, that's why I'm still on 1.10. 

To add an insult to injury, those percentages of the performance loss were all in a stock game without any mods on a completely clean save. When I first noticed that something was wrong, I was playing early career (not a lot of vehicles in the save file, low partcounts) with a bunch of mods, which means it only gets worse with mods. Something definitely changed, I don't think it should be this bad even with all new features. The prior updates never had this much performance difference, the game was getting heavier with each update, but the fps didn't drop. That's why this particular one stands out so much. 

[JonnyOThan]

1 hour ago, Gotmachine said:

More surprising, there is also a consistent and repeatable overhead (about 5% overall) in many top level method calls, including methods that haven't changed at all between KSP 1.10 and 1.12.
I'm not sure how to explain this apart from some global regression at the Mono/Unity level when KSP was upgraded to Unity 2019.4.18 for the 1.12.0 update.

Might be interesting to test 1.11 as well?  But no matter the result, is there anything we could even do about that?

 

The kerbal mass thing probably seems fixable, yeah?

[Gotmachine]

17 hours ago, dok_377 said:

In a building game where performance relies heavily on the number of parts you use, the more performance you have "in storage" - the better. Losing up to 20% fps is just not something that I want to have, that's why I'm still on 1.10. 

I understand your point of view. I'd say that 20% is an absolute worst case scenario for a 650 parts vessel basically doing nothing in the least performance intensive situation.
In more real-world performance heavy scenarios (atmospheric flight, active attitude control/engines, stuff running in the background, mods adding their own overhead, etc), that difference will become much lower and likely unnoticeable as the fixed overhead is dwarfed by other things that are just as heavy no matter the KSP version. In fact, I just tested a random craft file from KerbalX and got actually better FPS on 1.12 just because that ~500 part ship had a few converter parts, and those have perf issues on 1.10 but not on 1.12.

16 hours ago, JonnyOThan said:

Might be interesting to test 1.11 as well?  But no matter the result, is there anything we could even do about that?

I'm trying to think about what could be causing that global overhead. While the differences are measurable and consistent, there is always the possibility of some measurement bias, although I'm relatively confident in my methodology.
Here are some compiled results :

Hard to say what is at play here. Diffing some of the methods showing significant degradation, there are some methods where null checks against Unity objects were added, which can be somewhat expensive, but some methods are strictly identical between 1.12 and 1.10...
But yeah, I need to do the same tests against other KSP versions

16 hours ago, JonnyOThan said:

The kerbal mass thing probably seems fixable, yeah?

Maybe. I guess the bulk of the overhead comes from the call to Part.isKerbalEVA(), which could be partially optimized. The above graph show other potential optimizations, like preventing SuspensionLoadBalancer to run when not landed,

[stk2008]

Ohhh profiling.

I pray you can find whats causing it and increase performance that would be amazing

[stk2008]

Hi all

So in a sandbox game if I load up a stock craft I get all these messages

I also think this is part of a different issue I am having after loading a stock craft that does soemthing to resources (post in rational resources thread)

and as expected my log files

https://oshi.at/mhbp/KSPBugReport_2022-11-17_160422.zip

thanks in advance

[Gotmachine]

25 minutes ago, stk2008 said:

So in a sandbox game if I load up a stock craft I get all these messages

These messages are "normal", and would happen in stock KSP too. This happen because all your mods are adding non-stock modules to stock crafts. This being said, the log entries should probably not be emitted as warnings.

[stk2008]

Ah ok fantastic and thank you for replying

[JonnyOThan]

17 hours ago, Gotmachine said:

I'm trying to think about what could be causing that global overhead

Are there new modules that are added to every part in 1.12 but not 1.10?

[Gotmachine]

Just now, JonnyOThan said:

Are there new modules that are added to every part in 1.12 but not 1.10?

No. There are a few new modules like the inventory/cargo stuff, but they have near zero impact.
That's not what I meant by "global overhead". What I meant is that for many methods, the exact same code seems to be executing slower in 1.12 than in 1.10.

[JonnyOThan]

8 hours ago, Gotmachine said:

No. There are a few new modules like the inventory/cargo stuff, but they have near zero impact.
That's not what I meant by "global overhead". What I meant is that for many methods, the exact same code seems to be executing slower in 1.12 than in 1.10.

Sure, but many methods probably do things like iterate over all modules on a part.  An increase in the module count could cause something like that.  Just guessing anyway.

[CanOmer]

On 7/25/2021 at 8:30 PM, Gotmachine said:

DisableManeuverTool [KSP 1.12.0 - 1.12.3]
Allow disabling the KSP 1.12 maneuver planner tool in the KSPCF in-game settings menu. It can cause stutter and freezes on scene load, when changing SOI or when editing maneuver nodes, especially with Kopernicus modified systems.

I had hoped this helps but, it didn't.

 

Here is the issue:

FPS drops significantly when another craft set as target or when a maneuver node is created (fps drops further with the additional maneuver nodes). This is modded KSP but exactly same thing happens to unmodded KSP as well:

 

[JonnyOThan]

13 hours ago, CanOmer said:

I had hoped this helps but, it didn't.

Note this setting only enables the option to disable the maneuver tool in the in-game settings. You have to enable the patch in the settings.cfg and then also turn off the maneuver tool in game.

I can’t say for sure if this will help you, but it’s a detail that’s often missed about that patch and it does sound at least sort of related.

[kev4ev]

Hello! There's a 100% reproducible 'rotation after re-root-save-load bug for the BZ-52 Radial Attachment Point' in the unmodded KSP 1.12. It was reported about a yea ago (still not fixed):

https://bugs.kerbalspaceprogram.com/issues/28593

Here's a short video example (1- place a tank and then the radial attachment point, 2- re-root (!) to the latter, 3- save/load this assembly and 4- each parts should be rotated in wrong directions):

Anyone would like to try to fix it?

I'm not sure the BZ-52 is the only part bugged this way.

[stk2008]

IGNORE does not do it with min install

 

Edited December 6, 2022 by stk2008

[stk2008]

@Gotmachine sorry to ping you but I to am currently testing KSP (as good as I can due to zero coding skills nor do I have a way to test with a profiler like you have above)
but I have 100% found some thing odd.

So only mod installed is show FPS by linux and dependancys press F8 in game I do it at title screen prevents save popup showing once in game ETC you can now drag the fps readout any where you like

so game 1.12.3 if you fly the Gull (my test craft of choice) in sandbox mode as this makes it easier to test....so take off BUT stay below 150m (set alt readout to land not sea) note FPS (I have my FPS uncapped or set to default in KSP setting it makes it so much easier to test for FPS drops) on my rig I get about 187fps.

Now slowly raise alt and note as soon as you hit 150/153m your FPS will drop about 25frames or so.for no reason what so ever.But as soon as you go back to 148m boom instant fps increase of about 25fps.

Game 1.10 same thing as before and note fps drop still happens but not as much on mine its about 10fps drop once I go above 150m.

I am still testing currently I will now test with the KSP version before 1.10.

 

on a separate note

I would like to ask is there a mod or app that profiles even KSP mods would be so handy as I have lots of mods installed (please note not for the above tests the games where 99% vanilla except show fps and dependancys) and I am currenty trying to figure out the hardest hitting fps mods ETC.

 

thanks so much in advance and I hope the above helps.

Edited December 9, 2022 by stk2008

[JonnyOThan]

2 hours ago, stk2008 said:

I would like to ask is there a mod or app that profiles even KSP mods

https://gist.github.com/gotmachine/d973adcb9ae413386291170fa346d043

[stk2008]

Oh thats awesome thanks I shall have a look at this

[HB Stratos]

On 11/5/2022 at 4:18 PM, Gotmachine said:

It is fixable with a mod, but it would be a behavior change that has a significant chance to affect other mods in unexpected ways, so KSPCF isn't the right place for that.

I don't think it is a major behavioral change to just make it behave as expected. A part copied from another part that was already placed is supposed to inherit all properties and settings from said previous part.

How would it break mods that a copied part retains fuel flow being disabled if the same thing would be achieved by copying the part and re-disabling it manually? If your fear illegal states it could be implemented to only apply to parts where the player can toggle whether the fuel stored in it should be able to flow or not. But to even be able to reach an illegal state the part that was copied has to have been in an illegal state itself. If you fear for issues it could be disabled by default, but I feel the QOL improvement would be significant. I frequently build big craft and disable fuel tanks that are purely cosmetic to save on lag in the fuel flow calculation and to make the fuel counter show proper percentages. And it is very annoying to have to fix it every time after I copy something. And I often miss tanks as I expect tanks I copy to retain their settings, and not just loose one particular one while all others are retained.

 

Actually thinking about the argument above, that parts should retain all properties of the part they were copied from, fairings should also retain their X-Sections when copied with alt-click. It would be immensely helpful for shaping plane fuselages from many fairings and I think it also makes sense. Currently you have to detach the fairing and leave it floating in the hangar, then ctrl-z to revert while keeping the detached fairing around. This seems like an annoying hack for what should just be a feature. Especially since some things about fairings like to break when using ctrl-z (colliders liked to just disappear or become solid inside especially in older versions) it would be nice to just copy fairings with their shells. And I don't think that would break anything else.

 

[AccidentalDisassembly]

Not sure if anything can be done about it, but there's an interesting bug in stock 1.12.4 that I think has been around for a very, very long time - it has to do with parachutes and is easy to reproduce.

1. Make a rocket in VAB, then, in radial symmetry, connect two or more things with identical mass (a tank of ore, let's say) to the craft through decouplers. Put 1 or more parachutes on those things, also in symmetry.
2. NOTE: It does not appear to matter if you do this in symmetry or if you place each part individually, a similar effect will be visible regardless, I think.
3. Set staging to activate parachutes on decouple, launch, go to 500m (or whatever altitude, it's easier to see with more falling time -> higher parachute altitude, and with certain ratios of parachute effectiveness to test-weight mass), then decouple the ore tanks, activating the parachutes.
4. Observe the falling speed of the ore tanks when slowed by the chutes - in principle, they should fall at the same speed (or very, very close) before and after the parachute opens fully, because the properties of each parachute should be exactly the same, and the mass of the tanks, mass of the contents, etc. If you test this with a dead weight, the (several) dead weights you decouple will fall at very, very close to exactly the same speed, except for any tiny variations in drag they might encounter on the way down.
5. Note, however, that each tank will fall at a different speed when the parachute is involved. If you try this with more and more parts in radial symmetry (for convenience), each new presumably identical part will have its own speed different from the others, and (I guess?) therefore its own parachute properties; 2 parts in symmetry will fall at 2 different speeds, 3 parts will have 3 speeds,  etc., and each additional part in radial symmetry seems to fall faster than the last / have a parachute that appears less and less effective than what the 'default' parachute should.
6. So... I guess... if you have multiple parachutes on a vessel, each one you place does less than the last one...? Or if you decouple 2+ things from your ship, each new vessel/debris/entity (whatever the game considers them) gets slightly different parachute properties...? I don't know what this means, but it's pretty weird.

Fun Kerbal bugs! It would be awesome if it could be fixed, but I guess February is around the corner, too...

 

[Kwebib]

Interesting. I suppose that bug is not really a problem unless you're using Stage Recovery, right? Do the parachutes become so ineffective that the final parts crash into the ground?

[AccidentalDisassembly]

7 hours ago, Kwebib said:

Interesting. I suppose that bug is not really a problem unless you're using Stage Recovery, right? Do the parachutes become so ineffective that the final parts crash into the ground?

Depends on the weight, but yes, it seems possible for it to be problematic with SR - or if you're dropping probes that have juuuuuuust enough parachute power to make them land softly, I guess...

In my tests, the difference was big enough to cause destruction for some parts when others landed OK (in flight scene).

Edited December 15, 2022 by AccidentalDisassembly

[Gotmachine]

On 12/15/2022 at 3:39 AM, AccidentalDisassembly said:

it has to do with parachutes and is easy to reproduce.

There is definitely a bug where a chute placed in symmetry is staged for deployment at the same time as the decoupler removing that symmetry.
This will cause the chute to think it still used in symmetry, which combined with the "spread angle" setting will reduce the parachute drag.
The effect is quite visible, the chutes will stay at an angle out of nowhere.

Pretty sure this can't happen if the chutes aren't in a symmetry group.

Will try to make a fix for next release.

[AccidentalDisassembly]

On 12/30/2022 at 1:16 PM, Gotmachine said:

There is definitely a bug where a chute placed in symmetry is staged for deployment at the same time as the decoupler removing that symmetry.
This will cause the chute to think it still used in symmetry, which combined with the "spread angle" setting will reduce the parachute drag.
The effect is quite visible, the chutes will stay at an angle out of nowhere.

Pretty sure this can't happen if the chutes aren't in a symmetry group.

Will try to make a fix for next release.

Huh, I didn't notice the angle myself, but I was pretty focused on the "every next part gets its own slightly less effective parachute" - I'll look for the angle if I get around to testing again. Thanks!

[AccidentalDisassembly]

Is the issue of "using stock construction, dropped parts weigh 20 tons regardless of their actual weight" phenomenon a known issue? It happens when (for example), rather than placing a deployable science experiment via the correct method (the little place button in the lower right corner of the icon when it's in a kerbal's inventory), you do this instead:

1. Enter construction mode
2. Click on part from wherever it is (in a container's inventory, in a kerbal's inventory)
3. Mouse over open ground near the constructing kerbal - part will appear orange (if not blocked)
4. Click to drop part on terrain; part will drop, and about 1-2 seconds after dropping it, it will magically weigh 20 tons

Quite annoying! The workaround of Cheats -> Ignore max weight for construction definitely lets you fix it, but... kind of janky

Edited January 15, 2023 by AccidentalDisassembly