[1.8 - 1.12] KSPCommunityFixes - Bugfixes and QoL tweaks

[theJesuit]

3 hours ago, Gotmachine said:

New KSP bugfix : DockingPortConserveMomentum [KSP 1.12.3 - 1.12.5], make docking ports conserve momentum

Ya canneo' change the laws of physics!

Unless you are a startrek writer in which case the you never let physics get in the way of a story.

or...

you are incredibly talented coders.

 

Thank you for another happy update!

[Gotmachine]

On 9/5/2023 at 8:02 AM, MrAlexTg said:

Can you help me fix this? If you need logs, just tell me which ones and where to find them.

Logs are indeed needed, please upload them somewhere (dropbox, google drive...) and provide a download link.

Mac OS X: Open Console, on the left side of the window there is a menu that says 'Reports'. Scroll down the list and find the one which says "Log Reports", click that.  A list of files will be displayed in the top part of the window, in there will be Player.Log ( Files>~/Library/Logs>Unity>Player.log ).  Right-click on it and select "Reveal in Finder".

[Manul]

23 hours ago, Gotmachine said:

New KSP bugfix : DockingPortConserveMomentum [KSP 1.12.3 - 1.12.5], make docking ports conserve momentum by averaging the acquire forces between the two ports. Thanks to @Jules-Bertholet for the contribution.

RIP Zompi's Kraken Drive?

[MrAlexTg]

On 9/14/2023 at 12:24 PM, Gotmachine said:

Logs are indeed needed, please upload them somewhere (dropbox, google drive...) and provide a download link.

Mac OS X: Open Console, on the left side of the window there is a menu that says 'Reports'. Scroll down the list and find the one which says "Log Reports", click that.  A list of files will be displayed in the top part of the window, in there will be Player.Log ( Files>~/Library/Logs>Unity>Player.log ).  Right-click on it and select "Reveal in Finder".

Hello,

I've prepared the log files as per your instructions. I've created four files based on different game states of KSP for comparison. Here they are:

1. Not-works_Player.log_ TEXTURE_QUALITY=2vsHarmony+KSPComFixes_ONLY
2. Works_Player.log_ TEXTURE_QUALITY=3vsHarmony+KSPComFixes_ONLY
3. Not-works_Player.log_ TEXTURE_QUALITY=1vsAll_Mods_Installed
4. Not-works_Player.log_ TEXTURE_QUALITY=2vsAll_Mods_Installed

I've uploaded them to Google Drive.

Player.logs on Google Drive

Please let me know if there's anything else you need.

Best regards, Alex.

[VERT]

Hello, there is a problem. Judging by the data, the TWR of the RSC engines is more than enough to lift off from the surface of the Moon, and the device does not come off. And only at Minmus it really starts to work, when the indicators are already under 10 units. This problem only occurs if this mod is installed. In fact, I only need a fix for drifting robotic parts. Can it be downloaded separately?

Edited September 28, 2023 by VERT

[Gotmachine]

16 hours ago, VERT said:

Judging by the data, the TWR of the RSC engines is more than enough to lift off from the surface of the Moon, and the device does not come off.

I just tried with a replica of your setup, and everything seems to be working as expected :

I'm not sure what could be happening, especially since KSPCF doesn't touch RCS stuff directly, and very little else that could somehow end up causing such an issue.
There is nothing else I can do if I can't reproduce it, so I need more information.

At the very least could you provide a download link to your KSP.log ?
And if you're playing mostly stock, can you also provide your savegame where this issue can be reproduced (persistent.sfs file in the "saves\yourgamename\" folder) ?

For easier/automated bug reporting, I'd suggest using :

 

16 hours ago, VERT said:

In fact, I only need a fix for drifting robotic parts. Can it be downloaded separately?

No, but at a few exceptions all patches can be individually disabled, as mentioned in the OP :

Individual patches can be enabled or disabled by editing the Settings.cfg file. To make sure your changes persist when the mod is updated, it is recommended to make them in a ModuleManager patch. Open the Extras\KSPCF_UserSettings.cfg.extra file in a text editor for further instructions.

[JonnyOThan]

18 hours ago, VERT said:

the device does not come off

Did you use “set position” in the debug menu?  Is the vessel still easing to ground?

[VERT]

1 hour ago, JonnyOThan said:

Вы использовали «установить позицию» в меню отладки? Судно все еще приближается к земле?

Yes, I used the debugger to place the device on the surface, but I had to manually disable the placement by going into the menu again. Since without the mod it most often turned off on its own, but in this case, I always had to do it myself.

[VERT]

5 hours ago, Gotmachine said:

I just tried with a replica of your setup, and everything seems to be working as expected :

And if you're playing mostly stock, can you also provide your savegame where this issue can be reproduced ?

 

3 hours ago, JonnyOThan said:

Did you use “set position” in the debug menu?  Is the vessel still easing to ground?

Sorry. Apparently it was my mistake due to the specific sequence of actions. For some reason, with this mod, the placement of the device through the debug does not stop automatically, as it usually happens in a pure game. And it doesn’t matter whether I have other mods or not. This only happens with these fixes. When I placed the device on the surface, it was night, and because of this, without turning off the placement, I immediately rewinded the time to sunrise, but stopped the placement after. And for some reason this breaks TWR, but doesn't happen in stock because placement stops automatically in most cases as far as I know. If you stop the placement first, then there is no such problem and the device takes off normally.

[Gotmachine]

On 9/17/2023 at 3:45 PM, MrAlexTg said:

I've prepared the log files as per your instructions

Had some time to check your logs, and have done a bit of digging. Check out the github issue for details.

The gist of the issue is your GPU driver crashing when instructed to load DXT5 DDS textures when those textures have a specific NPOT resolution.
In your logs, it's crashing when loading :

• A 320 pixels height texture at level 1/4 mips, so 80
• A 160 pixels height texture at level 1/2 mips, so 80 again

I've found a bunch of reports from 2012-2015 era mac users having a similar issue in various games and applications, including KSP.

To validate could you try, without KSPCF being installed, to just drop these 2 textures in your GameData folder, and try to launch the game at 1/2 and 1/4 texture resolution (TEXTURE_QUALITY = 1 and TEXTURE_QUALITY = 2) ? I suspect your game will crash as well, please send a log if it happens.

The likely reason it happens when KSPCF is installed is because it tries to convert additional textures to the DDS format, and those textures have a tendency to use those problematic NPOT resolutions, but as far as I can tell this isn't directly caused by KSPCF.

If I'm right, I don't think there is anything I can do to fix this, especially since it is happening on specific hardware, and likely a very specific hardware/software combination. I would suggest to check if the GPU drivers and OS are up-to-date. In other games/apps, people mention having this issue after updating OSX to a newer version.

Edited September 28, 2023 by Gotmachine

[dok_377]

On 9/13/2023 at 9:11 PM, Gotmachine said:

DragCubeGeneration : patch enabled by default, hopefully all bugs fixed

I just randomly checked the settings file and it seems like the patch was left disabled by mistake. Downloaded the archive again just to be sure, and yep, it's set to false in the config. 

[Comrad_501]

Quote

 About Kopernicus… Well… That's the history: since some time ago, some folks around here decided to deeply change some code on KSP using Harmony or similar (RunSharp appears to generate CIL code at runtime - something like having a compiler embedded with your code). I'm one that criticise this practice due the incredible chances of screwing other people - usually people that are doing things right, and are caught in a crossfire by a new situation that never happened before - exactly what caught me with my pants down right now.

I concede that sometimes there's no other viable way, but yet… Before 1.8.0 Kopernicus wasn't using any of that shenanigans, so apparently it's possible to avoid using them - but take this with a grain of salt, because there's a limit for what is doable without these things.

But yet, I really try hard to avoid them, even by doing things in the hard way.

The whole KSP-Recall uses that "hard way" concept - I reimplement the feature that it's misbehaving, instead of trying to fix it injecting new code on the system (what's not exactly allowed on this Forum, by the way) - the reason I do things this way it's clear by now.

It's virtually impossible to foresee every consequence of changing already stablished code that will so behave in a new way, we never know when we will be hit by a new bug.

Exactly what's happening now. I will try to fix KSPe (my personal library that I use on everything I do, kitchen's sink included) and so I will really need to fix this thing only once (deployment will be my problem, because I didn't managed to push KSPe as a reusable library on SpaceDock's eco system as I did on CurseForge), but keep in mind that a lot of add'ons around here also use Reflection the way I do, and they are going to get hit the same.

— — POST EDIT — — 

As a matter of fact, I did a search on all my archived Logs and found this "RunSharp.dll" on some logs from my support "tickets" since Nov 2021.

Interesting enough, the RunSharp's induced "Unsuported" Stunt didn't screwed TweakScale all the time - sometimes TS passed through unscratched.

— — POST POST EDIT — — 

That's precious! (I'm being sarcastic)

This problem is unfixable by me!!! 

The Exception is being thrown inside a method called GetTypes_Patch1 on System.Reflection.Assembly.System.Reflection.Assembly that does not exists for me.

The "RunSharp.dll" is, indeed, a tool for making easier to use System.Reflection.Emit, that it's a tool to generate code at runtime. So someone, somewhere, is generating Dynamic Assemblies using this stunt.

But what's causing the problem is something that was injected on System.Reflection.Assembly.System.Reflection.Assembly using something like Harmony or similar.

So I remembered that KSPCF once published a fix/work-around/whatever for the infamous Assembly Loader/Resolver, and I'm pretty sure that code would need to handle the .Location property (that it's known to trigger the Unsupported Exception on dynamic assemblies).

Checking KSPCF soure code, I found this line:

if (methodName.StartsWith("<SetupFSM>") && !methodName.Contains("_Patch"))

what suggests that KSPCF should be, indeed, be involved somehow on this mess.

I also found that KSPCF is, in fact, directly accesing the GetTypes method (see here, and here). So we have evidences enough to drop them this hot potato.

@Comrad_501, @matthias123, both of you should ask for further help on KSPCF. There's absolutely nothing I can do from my side, as the problem is that whoever applied the GetTypes_Patch1 thingy into System.Reflection.Assembly.System.Reflection.Assembly, didn't accounted for Dynamic Assemblies and, so, are getting screwed.

My code is borking because it was induced to call GetTypes_Patch1 (whatever it is) instead of the original GetTypes. Additionally, my code that got screwed does not tries to access the .Location property, only .Namespace and .Name - so, again, there's nothing I can do to even workaround the problem on my side.

It's important to keep in mind that this problem is affecting everybody and everything that calls System.Reflection.Assembly.System.Reflection.Assembly.GetTypes() as I do, being TweakScale only one of the victims.

I've been directed here by @Lisias as part of a painful mess involving Kopernicus being a pain in the (backface), which i completely do not understand. Sooo yeah, here's Lisias findings that might lead you somewhere. Message me if you need a log or something, because I think this aint enough buut, i don't know where to start.
 

Edited October 8, 2023 by Comrad_501

[Gotmachine]

@Comrad_501 So, I have no idea from which mod your actual issue comes from, but the root cause of your problem is a plugin failing to load, either because it is missing some dependency, or because it is build against an older version of KSP.

When such a plugin fails to load in such a way, it actually still is registered in the list of loaded assemblies, but most calls to it or about its metadata will fail in unpredictable ways.
Notably, this can can issues when another plugin tries to get information about that assembly metadata. Specifically, a call to `Assembly.GetTypes()` on such an assembly will fail with a `ReflectionTypeLoadException`, see official API docs.

This is a relatively well know failure mode in the modded KSP ecosystem, which is why plugins usually wrap such calls in a try/catch block to handle this gracefully. However, some plugins may be forgetting to do so, so as a part of its fixes, KSPCommunityFixes automatically intercept that exception, handle it gracefully (so only the problematic plugin are affected, not others), and present it to end users in a clear way during loading, so they are aware that some plugin is failing to load, for example like this :

However, the reason you got directed here is because the KSPCF handler for that error actually has a bug where it will in turn throw an exception when it tries to handle that original exception, in a corner case scenario involving dynamic assemblies. From the end user point of view, this doesn't change much, as an unhandled exception would have occurred either way if KSPCF wasn't installed.

This being said, KSPCF obviously fails at its purpose of providing  extra correction for that error (that, again, would have happened anyway if KSPCF wasn't present), so I've pushed a fix, and will try to make a release with it soon.

Edited October 8, 2023 by Gotmachine

[matthias123]

@Comrad_501 and myself have the same problem, i am happy to see how involve and active is the ksp community , thanks you for your work and help

[Comrad_501]

Quote

well, you presumed right - this insidious Exception appears to be part of the problem.

It appears to be something on Unity?

https://forum.unity.com/threads/finding-the-cause-of-system-notsupportedexception-error.1256958/

Humm…Yeah, something on Unity, definitively:

https://github.com/googlesamples/unity-jar-resolver/issues/362

https://github.com/googlesamples/unity-jar-resolver/commit/1b7a9a586796751227796a50277cab6b8c27c8d4

So, nope, KSPIE and TweakScale are innocent on this one. Something else is triggering this Unity bug, almost surely by doing something completely innocent but that by some arcane reason destabilised something inside this sad excuse of software called Unity3D.

What's unfortunate, because if it would be something I'm doing wrong, I would fix it ASAP.

On the bright (or less dark) side, your CPU is a i7-10700KF, a symmetrical CPU (i.e., all the cores are equal and runs at the same speed), what makes things slightly less worst to cope with.

However, we still need to find what's happening on your rig and try to work around it. I'm afraid that TweakScale is just the one winning a lottery here, ideally we need to zero in the problem or this crap will hit someone else later with someone else.

We are going to do combinatorial analysis here.

First, do a FULL BACKUP of the whole thing and from now on, only mangle with the backup. Do not try anything below on the original installation, as these changes are destructive!

• Remove Harmony and anything that dependes on it (KSPCF, Kopernicus, etc). Then fire up the test bed and try to reproduce the problem.
• If the problem is still present, remove KSPIE and try again.
• If the problem is still present, send me a new KSP.log, but also the output_log.txt this time.

In the mean time, I will try the opposite here. I will install KSPIE and see what happens. Then I will install Harmony and KSPCF, etc.

I suspect I will not find anything, because such an obvious error would be already caught in the field, but I need to try nevertheless - or we will risk a misdiagnose and I already had my share this month.  

Anyway, let me know whatever are your findings.

Good hunting!

— — POST EDIT — — 

This thing is happening around here since some time, even before I get here!!

https://forum.kerbalspaceprogram.com/search/?q="System.NotSupportedException"&quick=1&updated_after=any&sortby=newest&search_and_or=or

— — POST POST EDIT — — 

Aha, found something!

https://github.com/blizzy78/ksp_toolbar/pull/39

If I'm right, I have no choice but to cope with this mess on KSPe. Damn, another update fest as it appears.

— — POST POST POST EDIT — — 

@Comrad_501 wait!!! Found something about! Try to first delete the following file:

D:\Steam\steamapps\common\Kerbal Space Program\GameData\KopernicusExpansion\Plugins\RunSharp.dll

I have notice that this fixed the problem!

— — POST POST POST POST EDIT — — 

NO!  DO NOT DELETE THAT FILE!!! (source)

-- POST POST POST POST POST EDIT --

That's the history: KopernicusExpansion decides to add a tool to make Reflection handling easier, RunSharp. Apparently it is not using it itself, but some extensions to it are.

Why this thing is playing havoc on KSP I didn't checked yet (but I will). 

So, there's a possible quick&dirty work around for your problem: delete RunSharp.dll and then check if anything borks. If you find nothing wrong, good - you can play KSP while I cook something to cope with the problem. If something borks complaining about the absence of the RunSharp.dll, then you will need to remove TweakScale for while (as I' m assuming you is playing KopernicusExpansion already).

@Gotmachine, just posting it here, may be uselful, may not, but have it here

[Gotmachine]

v1.31.1 bugfix release is out :

• DragCubeGeneration : Actually enable patch by default, I somehow failed to push that change in the last release (Thanks @dok_377 for reporting)
• ReflectionTypeLoadExceptionHandler : Fixed the exception handler itself throwing an exception in a corner case situation where a dynamic assembly is loaded, causing a call to Assembly.Location to throw (Thanks @Lisias for reporting).

@matthias123@Comrad_501 If you grab that updated version, assuming the issue in your KSP install is actually an assembly that  failed to load, KSPCF should tell you during loading what what plugin is the root cause of your issue , like in the above screenshot (you can also check your KSP.log for `ReflectionTypeLoadException` entries).

[matthias123]

@Gotmachine hey, thanks for that great work, very fast thanks you so much, so im testing now, everything seems to work for the bug i got this :

KSPcommunityfixes Warning:

the following plugin(s) failed to load :

c218ef02-f1a1-4883-b697-98e2525aeb0f in "Dynamic"

[Comrad_501]

@Gotmachine

Nothing from me, the modpack works

[Gotmachine]

4 minutes ago, matthias123 said:

for the bug i got this

The issue is with Kopernicus Expansion. It uses a library (RunSharp) that is built against the .NET v2.0 runtime, and consequently can't be used on KSP 1.8 and newer (KSP switched to the v4.0 .NET runtime in KSP 1.8). I would suggest bringing that to the Kopernicus Expansion thread :

 

[Lathari]

Not sure if this a known issue but if I don't set 

ModuleIndexingMismatch = false

then on loading a vessel (or reverting to launch) all parts reset. Solar panels are retracted, fairings disappear, anything with B9PartSwitch returns to default etc.

Logs here but with ModuleIndexingMismatch=false set. (not willing to try with 'true' as vessels get borked)

https://drive.google.com/drive/folders/1mULD0gmwx2q_xkpKJiWh6-FS4N0EXpgQ?usp=sharing

Nothing more.

[JonnyOThan]

1 hour ago, Lathari said:

(not willing to try with 'true' as vessels get borked)

This may make the logs next to useless - generally you need to reproduce the problem and then post your logs.  You can easily make a backup save before toggling the switch, then turn it off again and load the save.  It may also be useful to post your save file itself.

FWIW, I leave that setting at default and I haven't seen that behavior, so it's something specific to your setup.

[Lathari]

2 hours ago, JonnyOThan said:

This may make the logs next to useless - generally you need to reproduce the problem and then post your logs.  You can easily make a backup save before toggling the switch, then turn it off again and load the save.  It may also be useful to post your save file itself.

FWIW, I leave that setting at default and I haven't seen that behavior, so it's something specific to your setup.

New logs and zipped save. Vessel 'Craft' was on the launchpad with panels extended and with fairing. After revert to launch, panels were retracted, fairing gone and tank went to default subtype.

It is as if the modules 'reset' to blank state on loading.

Hopefully this helps.

I found someone with same problem way back and nabbed the ModuleIndexingMismatch=false hack from their posts, but couldn't find the posts again. I was just reminded of this after updating the KKSPCF and forgetting to set flag false and losing a bunch stored experiments when loading a vessel.

[Gotmachine]

@Lathari This happens because you installed the StuckOnLoadingPartUpgradesFix mod, which is depreciated, useless in KSP 1.12.3+, and conflicts with mods using Harmony (such as KSPCF), I'm surprised you aren't getting more issues.
This is somewhat my mistake, I forgot to mark that mod as depreciated.

To uninstall it, in the KSP root folder, delete the "BepInEx" folder, the "doorstop_config.ini" file and the "winhttp.dll" file.

[Lathari]

@Gotmachine This is what I get for being lazy and just copying the updated steam install over the modded one, instead of starting with a blank copy and adding mods there...

Well, hopefully no other fixes for non-existing problems are present.

But anyways, Thank You and keep up the good work.

[Manul]

10 hours ago, Lathari said:

Well, hopefully no other fixes for non-existing problems are present.

Some instances of MiniAVC.dll might be hiding somewhere in mod folders