Lisias

NASA's Helical Engine. A Real Life (tm) Kraken Engine!

[snip] Problem preemptively solved !

I beg your pardon?

So KSPCF may be just another trigger for a internal KSP problem. What I'm getting from the support I did (and still do) is that, under certain conditions still to be determined, some very weird behaviours are detected: Double patching those only way to happen is having two module managers running in parallel Patching corruption on Localizations, where some nodes had copies of itself inside them. This started to happen on MM 4.2.2 (what makes sense, since patching Localizations was implemented on 4.2.2) EDIT: Only detectable by inspecting the Module Manager's ConfigCache. Unexpected and unexplained misbehavirours, some of them causing NREs on the KSP.log, and that I never managed to reproduce myself even by cloning the user's GameData and savegames on my rig. And I do not use KSPCF. On every single case, KSPCF was installed on user's machine. On every single attempt of mine (that didn't managed to reproduce the problem), KSPCF was not. The only common ground on every one of the KSP.logs I inspected about these problems are: The presence of problems related to Assemblies (not all of them being Reflection Exceptions) The presence of KSPCF The presence of the following lines on the log: [LOG 19:14:24.331] [KSPCF] Taking over stock loader. An exception will follow, this is intended. [EXC 19:14:24.337] Exception: Terminating stock loader coroutine, this is intended and not an error KSPCommunityFixes.Performance.KSPCFFastLoader.GameDatabase_SetupMainLoaders_Prefix () (at <757279e523bf49d5b10dffca7b72d0d8>:0) (wrapper dynamic-method) GameDatabase.GameDatabase.SetupMainLoaders_Patch1(GameDatabase) GameDatabase+<LoadObjects>d__90.MoveNext () (at <46478292153440df94e04a2a2ddd1062>:0) UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAddress) (at <ef038509c5b948af8d6049dcab97ad3f>: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() So the ToolbarBehaviour could be another symptom of the problem due the apparent "recursion" involved due uncontrolled (and unwanted) concurrency. All of that doesn't means necessarily that KSPCF is the cause of the problem - correlation is not causality. But it strongly suggests that KSPCF is a trigger or an enabler for the problem. It's perfectly possible (and perhaps probable) that by allowing the game to keep going on situations where the absence of KSPCF would trigger a fatal error demanding the immediate shutdown, another nasty problem starts to happen later as consequence. Anyway. Until further information is provided, my evidences still suggest that KSPCF is involved on the problem somehow.

And I complemented your the speculations using my own knowledge from some support I'm doing not only on TweakScale, but from users that also don't have it and had similars problems. Now it's a bug report.

Your professionalism on handling bug reports are remarkable.

None of the TSCo adds anything to the Toolbar, only the TweakScale itself does it - on Editor, never on Flight. So I think you found a bug on the KSPCF code that tries to fix the Assembly Loader/Resolver! Some of the TSCo (very few) ends up tied to a specific TS's dll that if changes too much, borks. It's the reason I'm delay some releases on CurseForge and SpaceDock - so when I do it, everything is updated. It's the only thing I can think may be influencing your problem - a dependency loading problem. Since you mangled the Assembly Loader/Resolver, it makes it a problem caused by KSPCF. The TSCo was the trigger for the problem, but the problem itself is that your interventions on Assembly Loader/Resolver are not working as expected. So, it's a problem being caused by KSPCF now.

I don't believe it's up to you do decide. If there's someone willing to maintain it, and the previous owner was willing to transfer it, and a third one is willing to publish it, I really fail to see where the problem is. Let users choose. Fuel Switches can be problematic. B9PS have a myriad of support tickets caused by 3rd parties. Not their fault, but the user can't play the game the same until the thing is fixed and it's hard to criticise a user that decides to look for alternatives and avoid the hassle for little things like a oxidiser tank. (it's exactly what I did too, by the way.) Not to mention KSP squashing the resources to prefab itself, forcing Fuel Switches to do things that make coexistence even harder - I know what I'm talking, I maintain TweakScale. Check the Companion's Source Code to see some borderlines situations and how I had to cope with them. Installing a Fuel Switch with the sole purpose of having a pure oxidiser tank can be a way overkill and expand the user's surface for attacks by unexpected (and surely undesired) problems.

@Spike88, I purposely installed an older UberPacket to see what happens on my rig by using the 2.4.7.0 TweakScale release, and nothing bad happened. Everything just worked fined. But then I remembered that I had uninstalled Waterfall from the test bed - and, so, the older Waterfall support just didn't was loaded at all. Well, bingo. Once I installed Waterfall, I got exactly the same Exceptions you got on your log, but my Toolbar didn't got any duplicated Icons!!! There's something else happening in your rig, one of the add'ons you have installed is the one borking on this one. This Companion mess up may be a trigger, but the real problem is somewhere else, hidden as a land mine, waiting someone to step on it!!

On the Kerbal way! Someone needs to create a Eiffel mod for KSP now! https://theaviationgeekclub.com/the-story-of-bill-overstreets-p-51b-berlin-express-the-mustang-that-flew-under-the-eiffel-tower-in-hot-pursuit-of-a-luftwaffe-messerschmitt-bf-109/amp/

Hummm… Now I understand… You may had found a "bug" on the improved Companion Checker I just coded. Checking it… <hack, hack, slice and hack again> EXACTLY. I shipped 2.4.7.0 with the wrong definitions file! GameData::KIS Kerbal Inventory System (KIS) TweakScaleCompanion_KIS KIS Thank you very much for your persistence, @ngx, sometimes my dull thick skull is a bit too thick for my own good. I'm fixing this and publishing 2.4.7.1 in the next few hours. In the mean time, please ignore the message. It should not pesky you too much, it will be shown only when the ModuleManager's ConfigCache is rebuilt to remember you about the respective Companion (or when it finds one of the very few add'ons that demands a Companion installed to prevent breakage, a rare situation but at least two 3rd parties add'ons fall on this class). Cheers and thanks again!

You also need to remove GameData/TweakScaleCompanion/Frameworks , or update to the latest one: https://github.com/net-lisias-ksp/TweakScaleCompanion_Frameworks/releases . @ngx, you probably need to do it too. Forgetting to update the Uberpaket was a bad move, my apologies. [edit]: Nope! Only the github repos were updated, both the Companion and TweakScale will be updated at the same time on CurseForge and Spacedock!!! I'm rushing it into the repository now.

ARGH… I forgot update CurseForge and SpaceDock!!! [edit] Nope! The UberPaket will be updated on CurseForge and SpaceDock when I update TweakScale, both need to be updated at the same time there. Currently only the github were updated!! You can ignore the message for while, and please keep an eye on https://github.com/net-lisias-ksp/TweakScaleCompanion/releases . I will update it in the next few hours!!!\ Or install KIAS manually (remember to delete the older KIS): https://github.com/net-lisias-ksp/TweakScaleCompanion_KIAS/releases That's weird, TweakScale only creates an Icon on the Editor's Toolbar. I'm inspecting your log. Same thing, you need to install the (futurely) latest TweakScaleCompantion UberPacket, that I forgot to upload. Ignore the message for some more hours, or update manually to KIAS using the link above. (Remember to remove the old KIS directory)

It's a known issue: you left the auto-scale feature activated. The parts didn't disapeared, they got too small to be seen. Undo the last action (ctrl-z or cmd-z or meta-z - depending of the OS you are using) and then turn off AutoScale as a work around. This issue is fixed on the beta branch, by the way. Or should be... I need to verify it again.... Cheers!

Yep, it's exactly this. [LOG 12:15:33.170] [AddonLoader]: Instantiating addon 'WaterfallData' from assembly 'Waterfall' [ERR 12:15:33.198] [AssemblyLoader] Exception when getting assembly attributes: Exception of type 'System.Reflection.ReflectionTypeLoadException' was t hrown. Additional information about this exception: System.TypeLoadException: Could not load type of field 'KerbalFoundries.KFGUIManager:appButton' (10) due to: Could not resolve type with token 01000017 (from typeref, class/assembly ApplicationLauncherButton, Assembly-CSharp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null) assembly:Assembly-CSharp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null type:ApplicationLauncherButton member:(null) signature:<none> What happens: there's a nasty bug on a thingy called Assembly Loader/Resolver inside KSP that is triggered everytime something fails to be loaded due a missing or inadequate dependency. From this point, everything and the kitchen's sink starts to bork while loading DLLs or using a thingy called Reflection, and TweakScale makes heavy use of both. In your specific case, the "Could not resolve type with token" thingy is telling us that whatever is the dependency KerbalFoundries needs, it's there but it's from a different revision from what KF was compiled because something the code is swearing it will find on that Assembly, it's not there! You need to reach Kerbal Foundries maintainers and ask them about that it's this DLL and what the version KF needs to have installed in order to work. Things can get messy pretty fast when some other add'on installs an older version of that DLL, because now, out of the blue, something that used to work is now broken and no one have a hint about the reason without some digging… Anyway, there's no other option: you need to reach KF maintainers in order to undestand what is too old (or too new) for KF and then fix the thing. In the mean time, KF is not working and you may want to remove it in order to get everything else to work again (including TweakScale). Good luck!