[1.8 - 1.12] KSPCommunityFixes - Bugfixes and QoL tweaks

[Lathari]

27 minutes ago, Manul said:

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

Thank doG for ZeroMiniAVC.

[dok_377]

@Gotmachine FYI, you probably need to set an ignore flag or something like that in the dragcube generation patch for decals from Conformal Decals. With the patch enabled, these parts act like wings and create a lot of force, especially if set at an angle. Doesn't really matter if they are inside a fairing either.  Maybe it's because they have no drag model at all, it's set to dragModel = NONE and the patch doesn't know how to handle that.

The easiest way to see the effect is to build a simple rocket with a decal at an angle and launch it, the rocket will veer off course almost immediately.

Edited October 27, 2023 by dok_377

[Comrad_501]

Yeah so uhmmm, its this thing again, anyone got any ideas?

Edited November 6, 2023 by Comrad_501

[JonnyOThan]

37 minutes ago, Comrad_501 said:

Yeah so uhmmm, its this thing again, anyone got any ideas?

You had an incompatible mod installed.  I think the only thing KSPCF could do is harden the stock GetSubclassesOfParentClass function so that it doesn't explode when you have a failed mod installed, but this is unlikely to fix *all* the problems caused by doing this.

[Lisias]

2 hours ago, JonnyOThan said:

You had an incompatible mod installed.  I think the only thing KSPCF could do is harden the stock GetSubclassesOfParentClass function so that it doesn't explode when you have a failed mod installed, but this is unlikely to fix *all* the problems caused by doing this.

But yet, KSPCF ended up taking the hit by naively patching DLLs without caring about.

Ideally, KSPCF should print a nice message telling the thing could not be patched, instead of throwing a nasty exception that would trigger something on the flimsy KSP's loading system, making things harder to diagnose.

[JonnyOThan]

12 minutes ago, Lisias said:

But yet, KSPCF ended up taking the hit by naively patching DLLs without caring about.

Ideally, KSPCF should print a nice message telling the thing could not be patched, instead of throwing a nasty exception that would trigger something on the flimsy KSP's loading system, making things harder to diagnose.

That's not what happened.  The stock GetSubclassesOfParentClass function will break if any DLL throws an exception from GetTypes.  KSPCF happens to *use* this function in one of its other patches.

Edited November 6, 2023 by JonnyOThan

[Lisias]

48 minutes ago, JonnyOThan said:

That's not what happened.  The stock GetSubclassesOfParentClass function will break if any DLL throws an exception from GetTypes.  KSPCF happens to *use* this function in one of its other patches.

So KSPCF ended up taking the blame for a Stock misbehaviour, now I understand.

Anyway, since this is going to happen again (you can bet you SAS on it), it would be a good idea to have this documented on some FAQ to allow faster troubleshooting before hitting you guys here. Perhaps a try-catch on the calling function, and logging an URL on the KSP.log? It helped a bit on KSP-Recall.

[JonnyOThan]

7 minutes ago, Lisias said:

So KSPCF ended up taking the blame for a Stock misbehaviour, now I understand.

Anyway, since this is going to happen again (you can bet you SAS on it), it would be a good idea to have this documented on some FAQ to allow faster troubleshooting before hitting you guys here. Perhaps a try-catch on the calling function, and logging an URL on the KSP.log? It helped a bit on KSP-Recall.

As I said, if KSPCF wanted to, it could actually fix GetSubclassesOfParentClass.  But it's like patching one hole in a vessel made from chickenwire.  Anyone who knows how to read logs would see the ReflectionTypeLoadExecption and immediately know what the culprit was.  And KSPCF does print the names of DLLs that are throwing this exception on the loading screen, but I would argue it doesn't use strong enough language to let the user know their game is likely completely broken.

[Gotmachine]

From the mentioned tweakscale thread :

6 hours ago, Lisias said:

Suggesting that SolarSailNavigator is not loaded. But apparently it was!!!

It was loaded, and failed to load correctly, likely because it was a pre-1.8 plugin compiled against the v2.0 of the .NET Framework, there is nothing wrong with what KSPCF is reporting.
Loading an assembly can fail for a variety of reasons, usually either a missing dependency or a dependency version mismatch.
When this happen, the assembly will still be loaded in the AppDomain (and KSP will report it as such), but trying to access it (such as calling `GetTypes()` on it) or use its code will usually fail.

1 hour ago, JonnyOThan said:

The stock GetSubclassesOfParentClass function will break if any DLL throws an exception from GetTypes.  KSPCF happens to *use* this function in one of its other patches.

Nope, it won't thanks to KSPCF. If you look at the log, there is no exception thrown, just a [WRN].
Due to above mentioned behavior (exception thrown on calling GetTypes() on an assembly that failed to load), and to prevent plugins that are calling that method (which a common thing to do when doing some type checking on loaded assemblies) from breaking as a side effect, KSPCF actually handle that exception correctly, inform the user on screen during loading, and in the logs :

Quote

[WRN 15:24:04.746] [KSPCF] A ReflectionTypeLoadException thrown by Assembly.GetTypes() has been handled by KSP Community Fixes.
This is usually harmless, but indicates that the "SolarSailNavigator" plugin failed to load (location: "GameData\SolarSailNavigator\Plugins\SolarSailNavigator.dll")

As for the other exceptions (in Kerbalism and KerbalEngineer), loading a plugin compiled against the wrong framework version will cause all sort of nonsensical issues, this isn't a situation that can be recovered from.
We all remember way too well how the pre-1.8 MiniAVC bundled in tons of other mods broke the whole ecosystem when 1.8 dropped, this is the same issue here.

1 hour ago, Lisias said:

Ideally, KSPCF should print a nice message telling the thing could not be patched, instead of throwing a nasty exception that would trigger something on the flimsy KSP's loading system, making things harder to diagnose.

It doesn't throw any exception, prints a nice message, and makes things easier to diagnose.
@Comrad_501 fixed his install by doing what KSPCF was suggesting : remove the outdated SolarSailNavigator plugin.

Edit : this being said, I agree the wording of the log entry, especially the "This is usually harmless" might not be the best choice (this only appear in the logs, the on screen message is more straightforward).
The fact is that in most cases, a ReflectionTypeLoadException on GetType() is due to a missing dependency, and in that case is indeed harmless for the mod calling it, as long as the exception is try catched (which is why KSPCF automatically try catch it for everyone).
However, in the case of a .Net framework version mismatch, this definitely has unpredictable, and generally game-breaking consequences. I will try to look into detecting that specific case and adapting the error messages in the logs and on screen.

See https://github.com/KSPModdingLibs/KSPCommunityFixes/issues/168

Edited November 6, 2023 by Gotmachine

[JonnyOThan]

54 minutes ago, Gotmachine said:

Nope, it won't thanks to KSPCF. If you look at the log, there is no exception thrown, just a [WRN].

Oh oops!  Somehow I completely missed how that patch actually works.  Quite clever.

[Comrad_501]

Hmm

KSPCF Keeps on "[LOG 22:02:57.869] [KSPCF] Taking over stock loader. An exception will follow, this is intended." back tracing to "[EXC 22:02:57.870] Exception: Terminating stock loader coroutine, this is intended and not an error
    KSPCommunityFixes.Performance.KSPCFFastLoader.GameDatabase_SetupMainLoaders_Prefix () (at <c08d6ea084ba41369dbf89fe1fba85db>:0)
    (wrapper dynamic-method) GameDatabase.GameDatabase.SetupMainLoaders_Patch1(GameDatabase)
    GameDatabase+<LoadObjects>d__90.MoveNext () (at <4b449f2841f84227adfaad3149c8fdba>:0)
    UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAddress) (at <12e76cd50cc64cf19e759e981cb725af>:0)
    UnityEngine.DebugLogHandler:LogException(Exception, Object)
    ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
    UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator)
    <CreateDatabase>d__71:MoveNext()
    UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator)
    GameDatabase:StartLoad()
    <LoadSystems>d__11:MoveNext()
    UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator)
    LoadingScreen:Start()"

is there more to this that i should add, let me know...

Edit: So its an RO issue, and the track stops there

[EXC 22:21:21.243] NullReferenceException: Object reference not set to an instance of an object
    RealismOverhaul.VesselModuleRotationRO.StoreRot () (at <55d043cd0881488788cf2f91c4eedd21>:0)
    RealismOverhaul.VesselModuleRotationRO.OnAwake () (at <55d043cd0881488788cf2f91c4eedd21>:0)
    VesselModule.Awake () (at <4b449f2841f84227adfaad3149c8fdba>:0)
    UnityEngine.GameObject:AddComponent(Type)
    <>c:<CompileModules>b__4_0(Type)
    LoadedAssembly:TypeOperation(Action`1)
    LoadedAssembyList:TypeOperation(Action`1)
    VesselModuleManager:CompileModules()
    <LoadObjects>d__90:MoveNext()
    UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator)
    <CreateDatabase>d__71:MoveNext()
    UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator)
    GameDatabase:StartLoad()
    <LoadSystems>d__11:MoveNext()
    UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator)
    LoadingScreen:Start()

Edited November 9, 2023 by Comrad_501

[JonnyOThan]

56 minutes ago, Comrad_501 said:

this is intended and not an error

Without a crystal ball, I'd need to see the full logs to help.  But it looks like the RO thread might be the right place to post it.

[Comrad_501]

10 minutes ago, JonnyOThan said:

Without a crystal ball, I'd need to see the full logs to help.  But it looks like the RO thread might be the right place to post it.

I've fixed it, but now the dictionary files dont work, so im trying to fix that

[AmanitaVerna]

Something in KSPCF 1.32.0 breaks the popup menus in the CraftManager GUI in KSP 1.12.5. The popup menu opens and then immediately disappears, and options in it can't be clicked on. This happens whether right clicking on a craft in the list of crafts in the VAB/SPH, or clicking a button that opens a popup menu in the CraftManager GUI. Further, the next time it is attempted, nothing happens at all. The time after that, the popup menu opens and then disappears again. Presumably the menu isn't being closed, KSP is just forgetting to perceive it. The regular KSP popups seem to work fine still.

This works fine in 1.31.1, and I confirmed that KSPCF 1.32.0 was the culprit by rolling it back to 1.31.1. (It also broke right after updating KSPCF, so it was kind of obvious)

(CKAN lists the maximum KSP version of CraftManager as 1.9.9, but after some work I had got it working perfectly in 1.12.*, and the main obstacle, iirc, was actually CKAN, rather than KSP itself.)

Edit: The problem appears to be the IMGUIOptimization option. Setting it to false makes the problem go away.

Edited December 7, 2023 by AmanitaVerna

[Brigadier]

@AmanitaVerna You might also consider using the still-supported KSP Craft Organizer Improved.  @linuxgurugamermaintains the mod.

[Gotmachine]

3 hours ago, AmanitaVerna said:

The problem appears to be the IMGUIOptimization option. Setting it to false makes the problem go away.

Thanks for reporting. This should be fixed in the just released KSPCF 1.32.1

[stk2008]

Sorry to keep posting this but any one got any ideas on this
when I fly below 150m (ground hight its best to fly over the sea as thats level so makes it easier to do) I get a consistant 50+ FPS

But as soon as i touch 150m FPS drops a lot around the 30 to 40 FPS

the game does it on a completely vanilla game to you need to disable any FPS capping so V sync off and disable the FPS cap and you will see a pretty big FPS drop as well.
EDIT
if testing on vanila game the hight is higher I think its 250m or some thing but can be easily tested look for an FPS drop.

Thanks in advance

 

Edited December 7, 2023 by stk2008

[Gotmachine]

10 hours ago, stk2008 said:

Sorry to keep posting this but any one got any ideas on this

Such performance variations are usually due to the floating origin / krakensbane changing engagement modes on various altitude / speed thresholds.
Not much can be done about it, this is a structural consequence to how KSP handle floating point precision limits.

[stk2008]

ahh fair enough just thought I would throw it out there.

shame because if it was some thing that could be tweaked would gain a huge amount of performance.

its very odd though as long as I stay below 150m i can have 50+ FPS constantly no matter where I fly or how fast but as soon as I hit 150 and above FPS drops.

 

Thanks for the reply

[Gotmachine]

2 hours ago, stk2008 said:

its very odd though as long as I stay below 150m i can have 50+ FPS constantly no matter where I fly or how fast but as soon as I hit 150 and above FPS drops.

In the end the cases where the performance overhead is lower are exceptions, you're gonna experience the lower FPS in the vast majority of situations.
I'm not the best expert of the subject, but If I'm not mistaken, the reason this is needed is because the piece of code causing the performance overhead is required to prevent non-physical loss of velocity (which would notably cause orbital decay).
You could argue that you don't care about such small physics inaccuracies when flying a plane, but in the end, that piece of code is required in most situations, and trying to do weird heuristics to prevent it from running in some corner cases is gonna cause more issues and frustration than anything.

Also note that this performance overhead actually *does* happen anyway, as long as you're moving. The code just runs less often than every frame, so the tradeoff for a better average FPS figure is a more stuttery, unstable framerate, which isn't so great either.

Edited December 8, 2023 by Gotmachine

[swjr-swis]

Control surfaces randomly and spontaneously deciding (in the editor or once spawned in flight scene) to pick a different deployment direction than before, including mirror-symmetric control surfaces deploying in opposite directions - as if they had been placed in radial symmetry. Any chance that this could be looked at/fixed in KSPCF, or is that not in scope?

It's a rather significant bug that once it happens, and it inevitably happens almost guaranteed while working on (space)planes, renders the craft unfliable. To say it's frustrating having this happen after a couple of hours editing a craft is an understatement.

 

 

[JonnyOThan]

3 hours ago, swjr-swis said:

Any chance that this could be looked at/fixed in KSPCF, or is that not in scope

I’m sure that if you could find a series of steps to reproduce the problem then it’s something that would be looked at.  But without that, it’s orders of magnitudes more difficult to go hunting for a bug based off a description like that.

[swjr-swis]

6 hours ago, JonnyOThan said:

I’m sure that if you could find a series of steps to reproduce the problem then it’s something that would be looked at.  But without that, it’s orders of magnitudes more difficult to go hunting for a bug based off a description like that.

The 'random' part in the description kinda already gives away that a straight steps list isn't going to make it happen. Heck it happens simply loading an already existing non-edited craft sometimes. And unfortunately the first clue you get it has happened is when you take out a craft for another test and it crashes on take off because it keeps rolling instead of pitching.

Best I can do is provide craft files in which it has already occurred.

This happens so often though; I keep wondering how anyone else is able to fly a craft. I guess there's not many flying stock anymore.

 

[dok_377]

There has to be a more specific way of reproducing it. I'm not that much of a plane builder, though I have built enough to see what this is about, but I never had control surfaces that were rolling instead of pitching. The WASDQE controls are always as I set them up to be. It's the deployment feature that's inverting and it only can be seen through pressing "deploy", not through controlling the craft. You must have a certain way of building for them to be inverted even with direct controls.

[swjr-swis]

1 hour ago, dok_377 said:

I never had control surfaces that were rolling instead of pitching

I didn't say control surfaces, I said the craft.  Although I can see how I could've worded that less ambiguously. I do however mention deployment, not control authority.

I use control surfaces as wings quite regularly, because they allow setting a very specific small AoI by deploying them, something the stock rotate gizmo doesn't offer. Bonus, it also allows control of deployment, now AoI, on the fly by say, binding to up/down or fwd/bck keys in the action keys. Giving one control over lift/drag ratios in-flight. So yes, this bug shows up with deployed control surfaces, and it causes unexpected and uncontrollable roll on the plane when it happens.

So maybe that's the thing I do more than others that makes me experience this bug more. Control surfaces as wings, deployed, with a small deployment angle (usually because I want something in the range of 1-3 degrees). And at some point, the game decides to make mirror-symmetric 'wings' to be deployed in opposition, as if they were placed in radial symmetry. The only fix at that point is throwing the part out, because even taking it off the plane and placing it back again will continue to give the mirror part the wrong deployment.

Craft file exhibiting this bug, This one started showing the bug after I emptied the tanks to check on full/empty CoM. The bug is in the second-from-front Big-S Elevon 2. Move the deployment sliders back and forth to see it. That whole wing was 4x copy of the same set of parts, and the other three don't have the problem.

https://www.dropbox.com/scl/fi/p3nvosdunmqsnzig4i3qt/SWiS-WHA-3NS.craft?rlkey=b1xe3ee8quf3y4ax5g6cvmkof&dl=0

Edited December 13, 2023 by swjr-swis
added example craft file with the bug