[1.8 - 1.12] KSPCommunityFixes - Bugfixes and QoL tweaks

[Gotmachine]

On 4/1/2023 at 11:23 PM, immolated said:

Stock transfer alarm is broken when going from a larger orbit (Kerbin) to a smaller orbit (Eve).

Yep, the stock transfer math is not very reliable, not to say outright broken.
It can also fail in rather catastrophic ways that can cause stutters or even a total freeze of the game, that's why KSPCF gives the ability to disable the stock maneuver planner (which share the same transfer analysis code, and runs in the background even if you don't touch it).
I personally don't have the will to work on this, mainly because the modding ecosystem already has plenty of mature alternatives, but if someone is willing, contributions are welcome.

On 4/8/2023 at 5:19 PM, MartyrKomplx said:

Regarding the incompatibility between Community Fixes and SCON (SimpleConstruction) and EPL (Extraplanetary Launchpads), it's been said over on the github issues tracker that the issue stems from the ConfigNodePerf patch, and that by disabling the patch the issue isn't there

That patch indeed can't be disabled from the settings because it runs right on game launch, before ModuleManager patches are applied, and the KSPCF settings are meant to be altered from a MM patch.
This being said,  having a separate config file/switch to disable this specific patch is doable.

On 4/8/2023 at 11:59 PM, tg626 said:

I'm seeing engine shrouds not remaining OFF when reverting to VAB, is that within the scope of this mod?

Can you give specific repro steps for that ? Because engine shrouds state is correctly carried over when reverting to VAB and in other situations on my end.

Edited April 15, 2023 by Gotmachine

[theJesuit]

7 hours ago, Gotmachine said:

That patch indeed can't be disabled from the settings because it runs right on game launch, before ModuleManager patches are applied, and the KSPCF settings are meant to be altered from a MM patch.
This being said,  having a separate config file/switch to disable this specific patch is doable.

On 4/9/2023 at 9:59 AM, tg626 said:

I'd appreciate a fix please.

[tg626]

9 hours ago, Gotmachine said:

Can you give specific repro steps for that ? Because engine shrouds state is correctly carried over when reverting to VAB and in other situations on my end.

Ill do some tests. It may be shrouded decouplers doing it.

[Gotmachine]

V1.27.0 is out :

• New performance patch : LocalizerPerf [KSP 1.8.0 - 1.12.5] Faster and minimal-allocation replacements for the Localizer.Format() methods, can provide significant speedup for GUI-heavy mods using localized strings.
• FastLoader : Faster implementation of the stock translateLoadedNodes method, can reduce loading time by up to 30 seconds in a heavily modded install (thanks to @siimav for spotting this).
• LandingGearLights : fixed the patch not applying to the smaller LY-10 landing gear (thanks to @JonnyOThan).
• Fixed issue #98 : ConfigNodePerf patch ignoring the last key/value pair when parsing a node-less, values only input. Notably fix a compatibility issue with the SimpleConstruction mod causing missing vessel construction costs.

[MartyrKomplx]

1 hour ago, Gotmachine said:

Fixed issue #98 : ConfigNodePerf patch ignoring the last key/value pair when parsing a node-less, values only input. Notably fix a compatibility issue with the SimpleConstruction mod causing missing vessel construction costs.

You're my hero, man. I've been struggling so hard trying to justify one mod over the other. I love what your fixes do, but I've always dreamed of a proper yet simple orbital shipyard. No more Alt+F12-ing my highly non-aerodynamic designs into orbit.

I gotta buy you a Coffee or something for this.

[tg626]

NM about the shrouds, it looks like a Decoupler Shrouds issue.

[JAK0723]

On 11/20/2021 at 7:17 AM, Sandriell said:

Is it possible to have the PAW groups expanded by default? Particularly the stock ones? Its kind of of annoying and tedious having to expand them all the time while building a craft.

Was this ever addressed? It's the first thing I noticed with the mod and it's quite annoying that I have to manually expand the groups for every ship I build. It would be nice if this was configurable, similar to PAWCollapsedInventories but for all PAW groups.

[cain546]

I am experiencing an error where ksp community fixes is causing an error with kopernicus.

I get an error that kopernicus.components.dll fails to load.

It took me a few days to dissect my mod order until I found the culprit.

I can supply a log file if needed, but it's quite large and I'm not sure where or how to upload it though.

[JonnyOThan]

23 hours ago, JAK0723 said:

Was this ever addressed? It's the first thing I noticed with the mod and it's quite annoying that I have to manually expand the groups for every ship I build. It would be nice if this was configurable, similar to PAWCollapsedInventories but for all PAW groups.

I'm not sure if you can make them default to expanded, but you can disable the groups entirely by toggling the `PAWStockGroups` value in settings.cfg.

47 minutes ago, cain546 said:

I am experiencing an error where ksp community fixes is causing an error with kopernicus.

I get an error that kopernicus.components.dll fails to load.

It took me a few days to dissect my mod order until I found the culprit.

I can supply a log file if needed, but it's quite large and I'm not sure where or how to upload it though.

You can zip it first.  google drive is a decent choice.

[JAK0723]

Just now, JonnyOThan said:

I'm not sure if you can make them default to expanded, but you can disable the groups entirely by toggling the `PAWStockGroups` value in settings.cfg.

That does remove the need to manually expand the PAW groups, but doesn't this disable the PAW group functionality entirely? I'll keep it disabled as manually expending the groups is very annoying, but it seems a bit excessive to disable the whole feature just because of a non-configurable quirk.

[Gotmachine]

2 hours ago, cain546 said:

I get an error that kopernicus.components.dll fails to load.

Send your log, but kopernicus.components.dll is an old dll from a Kopernicus version at least 4 years old that doesn't even support KSP 1.8 or newer, so either you need to update/reinstall Kopernicus, or you're using a KSP version older than 1.8, which KSPCF doesn't support.

Edited April 21, 2023 by Gotmachine

[Brigadier]

5 hours ago, cain546 said:

I can supply a log file if needed, but it's quite large and I'm not sure where or how to upload it though.

First, when supplying log files for diagnostics or help  try to run KSP for the minimum amount of time to demonstrate the error or issue then quit KSP.  This keeps the log file small and helps the rest of us sort through the log without extraneous entries, allowing readers to focus on your problem.

Second, read the link in my sig block for a topic on help sending logs.  Briefly, upload your file(s) (the entire file, not just an excerpt) to a sharing service, such as Google Drive, OneDrive or Dropbox, and paste a link to the upload in your forum post.   Make sure you've granted public access otherwise we can't read/download it.   You can do something similar with screenshots or use a service such as Imgur to be able to embed images directly in your post.

HTH

Edited April 21, 2023 by Brigadier
Really poor grammar :-)

[Gotmachine]

V1.28.0 is out :

• New KSP bugfix : ReRootPreserveSurfaceAttach [KSP 1.8.0 - 1.12.5], disable the stock behavior of altering surface attachment nodes on re-rooting, a questionable QoL feature that doesn't work correctly, leading to permanently borked attachement nodes.
• New performance patch : DisableHiddenPortraits [KSP 1.8.0 - 1.12.5], prevent non-visible crew portraits from being rendered after a switch back from the map view (and other cases), causing a significant perf hit when there are many kerbals in the vessel.
• New performance/bugfix patch : DragCubeGeneration [KSP 1.12.0 - 1.12.5], faster and more reliable implementation of drag cube generation. Improves overall loading times (both game load and scene/vessel/ship load times), prevent occasional lag spikes (in the editor mostly) and fix some issues causing incorrect drag cubes to be generated (notable examples are the stock inflatable heat shield, the 1.25m and 2.5m nose cones and the Mainsail shroud). Note that by design, this patch results in a small deviation from the stock behavior for buyoancy, aerodynamics and thermodynamics, as the generated drag cubes will be slightly different.
• New API/modding patch : BetterDDSSupport [KSP 1.12.3 - 1.12.5] (actually part of the FastLoader patch), implement compatibility with the DXT10/DXGI specification, and support of loading additional texture formats :
  • BC4 : single channel (R) compressed 4 bpp
  • BC5 : 2 channels (RG) compressed 8 bpp
  • BC6H : 3 channels (RGB) compressed 8 bpp with HDR color range (Not available on MacOS)
  • BC7 : 4 channels (RGBA) compressed 8 bpp (Not available on MacOS)
  • R16G16B16A16 : 4 channels (RGBA) uncompressed 64 bpp
  • R16_FLOAT / R32_FLOAT : single channel (R) uncompressed 16/32 bpp
  • R16G16_FLOAT / R32G32_FLOAT : 2 channels (RG) uncompressed 32/64 bpp
  • R16G16B16A16_FLOAT / R32G32B32A32_FLOAT : 4 channels (RGBA) uncompressed 64/128 bpp
• DisableManeuverTool : added MM-patcheable flags to set the default enabled state of the maneuver tool or to forcefully disable it, see Settings.cfg.

Edited May 6, 2023 by Gotmachine

[Omar X]

Here's handy fix for the Kraken Death Shake.

Years ago, I discovered a way to prevent/fix the Kraken Death Shake. I and some others have been doing this for years, and so far it has worked 100% of the time. Ive never had a credible report of failure. I tend to build very large/complex ships, and I have not lost a single ship this way in over 6yrs.

The problem seems to stem from multiple sources of torque facing different directions. When two ships are combined, it appears that a new point of control is not automatically assigned. As a result, they start fighting each other to face the craft in their respective direction/plane, and it leads to destruction.

There is no need to spam struts, or turn off SAS, or go around disabling a bunch of reaction wheels.

All you have to do is: 
When you dock two craft, immediately designate a specific control point ("Control from here"). It doesn't matter what part you choose. It will not affect the function of the ship.

If you come into physics range of a craft, and you see it is already beginning to shake, quickly designate the control point, and the shaking will begin to abate. 

If the shaking is already dangerously violent, you should warp for a second or two to stop the physics. Then, come out of warp, and quickly designate the control point.

When undocking, it is wise to immediately repeat the procedure for both craft. It's just a part of my standard approach to docking now.

I would appreciate it if you let me know how it works for you.

I have tried to find a modder who will write a small mod to do this automatically at every un/docking, but no luck so far. If you know a modder who is willing to give it a shot, please put them in contact with me. All I ask is for some recognition  in the name. It would be a tremendous benefit to the entire community.

Edited May 9, 2023 by Omar X

[Gotmachine]

13 hours ago, Omar X said:

Years ago, I discovered a way to prevent/fix the Kraken Death Shake.

I wouldn't be as confident as you, but I don't want to dismiss your findings either.
What I need to make your report actionable is a reproduction setup, meaning a save file made in a stock (non-modded) game that I can open to reproduce the "Kraken Death Shake" and your fix on my side.

[Omar X]

1 minute ago, Gotmachine said:

I wouldn't be as confident as you, but I don't want to dismiss your findings either.
What I need to make your report actionable is a reproduction setup, meaning a save file made in a stock (non-modded) game that I can open to reproduce the "Kraken Death Shake" and your fix on my side.

I'll figure out a way to get that for you. I suppose I can do a separate install. Round stations seem to really invite this problem. . I'm not a coder, so perhaps I'm wrong about the cause, but the solution is great. I'll be in touch.

Thanks.

[Manul]

14 hours ago, Omar X said:

The problem seems to stem from multiple sources of torque facing different directions. When two ships are combined, it appears that a new point of control is not automatically assigned. As a result, they start fighting each other to face the craft in their respective direction/plane, and it leads to destruction.

Kraken Death Shake mostly appears while docking to an asteroid that doesn't have a control point or reaction wheels. There are two major reasons for that:

1)PhysX is glitchy as hell when it creates a joint between parts that have a huge difference in their mass.  Autostruts may help or make things even worse
2)While docking autostruts are disengaged and created again with a new root/parent/heaviest part. If the craft is being deformed while autsotruts are rebuilt they are screwed and make more deformations.

Joint glitch also affects modded heavy parts like naval ship hulls, some lighter parts just fall of from the heavy hull under the slightest load. Or the ship just  explodes or shakes itself to death after the physics is applied.

[Omar X]

1 minute ago, Manul said:

Kraken Death Shake mostly appears while docking to an asteroid that doesn't have a control point or reaction wheels. There are two major reasons for that:

1)PhysX is glitchy as hell when it creates a joint between parts that have a huge difference in their mass.  Autostruts may help or make things even worse
2)While docking autostruts are disengaged and created again with a new root/parent/heaviest part. If the craft is being deformed while autsotruts are rebuilt they are screwed and make more deformations.

Joint glitch also affects modded heavy parts like naval ship hulls, some lighter parts just fall of from the heavy hull under the slightest load. Or the ship just  explodes or shakes itself to death after the physics is applied.

I've never captured an asteroid of built the kind of ship you referenced, but I used to have craft shake themselves to pieces quit often. Out of pure frustration, at one point I completely stopped even playing for arounda year.

I'm not a coder, so I could well be wrong about the cause. Perhaps, there could be different conditions that trigger the bug.

What I do know with certainty is this fix has worked every time it's done.  Give a shot. We've got nothing to lose, and it saves a lot of wasted hours.

[Manul]

3 minutes ago, Omar X said:

Perhaps, there could be different conditions that trigger the bug.

Yes. There are much more reasons to KDS, including landing gear, robotic parts and ground anchor. I'm just spamming autostruts everywhere so I never experienced the KDS cases caused by reaction wheels and my creations are usually too massive to be affected by small amounts of torque created by reaction wheels. Also they are too massive to survive without autostruts. There is some shaking after docking a 120t spaceplane to a 300t station but it's not dangerous and it can't be compared to what happened when I failed docking a 300t station to a calss E asteroid: it started violently shaking and spinning,  some parts got close to light-speed after the explosion.

[JonnyOThan]

I wouldn't be surprised if there's some bug in reaction wheels that gets corrected when you reset the control point - but the correct fix would be to fix the code bug, not invoke "control from here" on docking events.  In any case with an easy repro save finding the bug shouldn't be too hard.

[Omar X]

51 minutes ago, JonnyOThan said:

I wouldn't be surprised if there's some bug in reaction wheels that gets corrected when you reset the control point - but the correct fix would be to fix the code bug, not invoke "control from here" on docking events.  In any case with an easy repro save finding the bug shouldn't be too hard.

That would be the best option, a true fix, instead of a work around. However, I reported this info to Squad support for years, and didn't get a single reply.

1 hour ago, Manul said:

Yes. There are much more reasons to KDS, including landing gear, robotic parts and ground anchor. I'm just spamming autostruts everywhere so I never experienced the KDS cases caused by reaction wheels and my creations are usually too massive to be affected by small amounts of torque created by reaction wheels. Also they are too massive to survive without autostruts. There is some shaking after docking a 120t spaceplane to a 300t station but it's not dangerous and it can't be compared to what happened when I failed docking a 300t station to a calss E asteroid: it started violently shaking and spinning,  some parts got close to light-speed after the explosion.

Sounds like the perfect test of my suggested method. Can't hurt. I just want this game breaking problem to finally be eliminated for everyone, one way or another.

[Gotmachine]

To expand a bit, I'd say that changing the reference transform point (ie, "control from here") has indeed a direct effect on the SAS behavior for attitude control providers (reaction wheels, rcs, gimbals, control surfaces).
The conditions for a feedback effect where the SAS enter a self-reinforcing "shake inducing" loop are indeed primarily dependent on the position of the reference transform, the general rules being that when the reference transform is far away from the attitude control providers, the refrence transform momentum has a greater chance to be in an opposite direction as the attitude control provider at any given time due to ongoing or pre-existing oscillation effects.

After looking a bit into it, I'm very doubtful there is an actual bug where for a single vessel, some components would be referring to different reference transforms.
However, without doing any testing, I'd say there is decent probability for the reference transform to be reset to the root part in some circumstances, like docking.
And in the case of docking, it's likely the root part of the combined vessels will be located at some "far end", which might be a not-so-great place as far as the above feedback effect is concerned.

The thing is, by setting manually a different reference transform, you're acting knowingly on the root issue, with all the mighty analysis power of your brain.
Turning that into an algorithmic rule is likely difficult, might simply not work (the fact that you're acting manually with a delay after the feedback loop has started might play a great role in why it actually works), and is also likely to have other unwanted side effects.

Edited May 9, 2023 by Gotmachine

[Omar X]

25 minutes ago, Gotmachine said:

To expand a bit, I'd say that changing the reference transform point (ie, "control from here") has indeed a direct effect on the SAS behavior for attitude control providers (reaction wheels, rcs, gimbals, control surfaces).
The conditions for a feedback effect where the SAS enter a self-reinforcing "shake inducing" loop are indeed primarily dependent on the position of the reference transform, the general rules being that when the reference transform is far away from the attitude control providers, the refrence transform momentum has a greater chance to be in an opposite direction as the attitude control provider at any given time due to ongoing or pre-existing oscillation effects.

After looking a bit into it, I'm very doubtful there is an actual bug where for a single vessel, some components would be referring to different reference transforms.
However, without doing any testing, I'd say there is decent probability for the reference transform to be reset to the root part in some circumstances, like docking.
And in the case of docking, it's likely the root part of the combined vessels will be located at some "far end", which might be a not-so-great place as far as the above feedback effect is concerned.

The thing is, by setting manually a different reference transform, you're acting knowingly on the root issue, while all the mighty analysis power of your brain.
Turning that into an algorithmic rule is likely difficult, might simply not work (the fact that you're acting manually with a delay after the feedback loop has started might play a great role in why it actually works), and is also likely to have other unwanted side effects.

Very interesting info.  I understand that addressing it with code is likelymore difficult than i had hoped. All I know with certainty is this procedure has worked everytime its been tried for many years by multiple players. In my personal experience, there have been no emergent tangential problems resulting from it. None have been reported to me by others as well.

Yes, if applied quickly, this procedure has worked well when the shaking is beginning to be noticeable, but I've made it a habit to apply it proactively as part of my un/docking method. As a result, I have not even had a craft begin to shake in many years. As far as I'm concerned, the results speak for themselves. 

Please understand that my ego is not rolled up in this. I just want to help the community overcome one of the most game breaking causes of frustration and wasted time. 

If anyone is interested, I'd love for others to try it, see what their experience is with it, and report back with the results. I don't see any downside to giving it a shot.

Edited May 9, 2023 by Omar X

[Gotmachine]

36 minutes ago, Omar X said:

If anyone is interested, I'd love for others to try it, see what their experience is with it, and report back with the results. I don't see any downside to giving it a shot.

Well, as I said, please provide a save that reproduce it and I will take a look.
I was just pondering that while there are cases where the oscillation issue can be a result of interactions between the SAS, it's control point and the controlled attitude control providers, the underlying root issue has very little to do with that and can be reproduced with a vessel that doesn't has any SAS nor any attitude control providers, it's an inherent instability of the physics simulation KSP uses.

[Omar X]

1 hour ago, Gotmachine said:

Well, as I said, please provide a save that reproduce it and I will take a look.
I was just pondering that while there are cases where the oscillation issue can be a result of interactions between the SAS, it's control point and the controlled attitude control providers, the underlying root issue has very little to do with that and can be reproduced with a vessel that doesn't has any SAS nor any attitude control providers, it's an inherent instability of the physics simulation KSP uses.

Will do.