Lisias

Or perhaps a borderline situation that caught CKAN with its pants down? There's a file where CKAN does logging as KSP does? Inspecting such log would surely pinpoint the cause (or at least the symptom) allowing people to do something about!

So what leaded you to the conclusion that it would be KSP and/or Unity the problem and not some other process running on that specific rig?

I'm not talking only about one MM copy being installed, but about more than one instance being running. It looks nuts, but I have at least one situation in which multiple (at least two) copies of MM were running concurrently in memory and I only found one Module Manager DLL in the whole KSP.log. I detected this problem due a screwed up patching on the Localization file (a node containing another copy of itself inside it), that I only detected by eye balling the ConfigCache file. I should had write a full report at that time, however, now I do not recall how the KSP.log was looking like, I don't recall if an occurrence I detected of a unique patch being applied twice to a part were logged twice on the KSP.log or not - thinking a bit more about the problem, it may be a problem inside MM that by some reason is firing up more than one MMPatchLoader threads. Anyway, back to the problem at hands. By the time Module Manager's MonoBehaviour is started, KSP had already loaded, resolved and linked every single Assembly from every single DLL in the GameData (as long it's not inside a PluginData directory). Loading KSP plugins is as simple as calling "AssemblyLoader.LoadPlugin" , so I'm betting this is the call KSP is using for loading the KSP Assemblies. When I load Assemblies for inspection, I do something like this: System.Reflection.Assembly.ReflectionOnlyLoad(System.IO.File.ReadAllBytes(filepath)) but someone else could use too: using (System.IO.FileStream fileStream = new System.IO.FileStream(filepath, System.IO.FileMode.Open, System.IO.FileAccess.Read)) { byte[] rawbytes = new byte[fileStream.Length]; int n = fileStream.Read(rawbytes, 0, rawbytes.Length); // n should be equal to rawbytes.Lenght now, or something went South. System.Reflection.Assembly.ReflectionOnlyLoad(rawbytes) } In both situations, the file will be closed after the operation (you need to call Dispose on Streams, and using do it automatically for you). So, we have now two possible situations in which the DLL files would be still opened by the time Module Manager calculates the SHA : An external program is, deterministically, keeping the damned files opened at that time - probably an anti-virus KSP is leaking file handlers in objects still to be collected by the Garbage Collector. Given that you, by using a small delay, was able to open the file, I think it's reasonable to assume option 2 (as long we agree to rule out multiple MM threads running concurrently). But in order to KSP be leaking file handlers, it should be loading DLLs more or less like this: void loaddll(string filepath) { System.IO.FileStream fileStream = new System.IO.FileStream(filepath, System.IO.FileMode.Open, System.IO.FileAccess.Read); byte[] rawbytes = new byte[fileStream.Length]; int n = fileStream.Read(rawbytes, 0, rawbytes.Length); System.Reflection.Assembly.ReflectionOnlyLoad(rawbytes) } What's, frankly, a very, very, very stupid move. The filestream will be lingering in memory until being collected by the GC. Now, and assuming this is the problem afflicting MM right now, you are experiencing the problem on the bigger rig not exactly because it's faster, but because it probably have way more memory and so there's less pressure over the Garbage Collector to collect memory, delaying the disposing of the filestreams that were leaked by the hypothetical shoddy code I posted above. The way you used to cope with the situation (by opening the files in share mode with sharing write privileges), besides not addressing the root problem, is also: being potentially flagged by antivirus as you is opening a DLL file with write permissions, what's a very suspicious move that antivirus look for, triggering some monitoring code that would not be triggered otherwise you are using a slower call. opening a file for sharing is always slower than just opening the thing. reading from it, too. what makes loading KSP slightly slower than otherwise - and I want to stress that KSP loading times are a common cause of complains. So, before pushing into the upstream a solution that will make loading KSP slightly slower for everybody no matter they are being affected or not, I would try to pinpoint the root cause of the problem and try something that would tax only the affected rigs. Being the reason I suggest so: making all the DLLs inside GameData read/only to see if anything changes r/o files are handled in a less strictly way by the O.S., as it knows that no one is going to be able to write on it. (your O.S.'s mileage will vary, of course) call GC.Collect() before starting the SHA computations. If I'm right about the leaking file handlers, this may mitigate the problem. On UNICES listing the open files immediately before and after the SHA computation is relatively trivial, but I don't have the slightest idea about Windows. if feasible, dumping the process's opened files before and after the SHA computation may help to correctly diagnose the problem on a UNIX, I would have a second process waiting for a signal, and then dumping the open files from the KSP process, and then I would, so, send this signal from Module Manager before starting the SHA computations.

Ah, yes! You also is using LShipParts! Please install TweakScale Companion for SMCE. You will need to replace one of the files from the LShipParts with the one on the zip file.

Such an abnormal high number of fatalities, nowadays, sounds more like having TweakScale installed twice on the system. KSP.log way more convenient, but it will do. And nope, didn't found more than one copy of the Scale.dll on your rig. But I found this: [LOG 15:58:17.627] Applying update TMasterson5/tweakscaleConfigPatch/@PART[mtaAWACSRadar] to MTW/Parts/AWACS Radar/awacs.cfg/PART[mtaAWACSRadar] TweakScale's patches from TMasterson5 didn'd aged very will. Delete GameData/TMasterson5/tweakscaleConfigPatch.cfg and you will be fine. Cheers!

With all due respect, sir, opening any kind of executable code with a Write option enabled is for anti-virus what honey is for honeybadgers - and I assumed that someone that worked on I.T. infrastructure would be aware of that. Additionally, by the time Unity starts to call the Awake method on the Monobehaviours, everything was already loaded into memory. KSP (at least the latest ones) first loads all the available DLLs, then it links them in memory (this is where missing dependencies are detected), and only then KSP starts to call code inside it. By the time ModuleManager opens a DLL for reading its contents, everything should be set for some time already and it's pretty awkward that KSP would keep these files opened after resolving all the dependencies. Granted, not impossible (but that would be another flaw on KSP, I think). Did you monitored the opened files in the system in order to determine who had these files opened at the time of the occurrence? Did you tried to make all the DLLs read/only on the file system to see if the problem goes away (or if a new one is created)? In a way or another, instead of opening everything using a Write enabled share option (potentially attracting undesired attention from antivirus monitors), would not be better and safer putting the whole SHA thing inside a try catch, inside a loop, and doing a small busy wait if the problem happens and trying again?

Unlikely, because the thing was wrote over Unity and we are tied to whatever Unity runs on. But if someone manages to port Unity to an ARM3 CPU (used by calculators by some time already, they are using emulators to run legacy firmware), yeah - it's theoretically possible. You will probably fly crafts with 4 or 5 parts only, however.

It was scheduled to be fixed at this time, but problems unrelated to TweakScale (or the Companions) completely screwed up my last window of opportunity for it (this year's early holidays), and so I had to postpone it again. It will be fixed only for the (hopefully) near coming TweakScale 2.5 series, the current 2.4 doesn't have the features I need to carry the tasks (it's the reason the fix wasn't coded yet). The current 2.4 series should be considered legacy by now, I will not publish new features (or fix bugs that need new features). I screwed up a little bit on a previous KSP-Recall, and that was the reason of some borkage in the field while creating new crafts and subassemblies (existent ones weren't affected, and this is the reason I let this crap pass trough). Other than that, I had no problems on my tests on updating KSP-Recall. However, and this is very important, one problem still to be solved is a new (old) bug I found recently (less than a month ago!!) on Editor since KSP 1.8 on the reroot feature. By some reason rerooting the craft or the subassembly completely screw up the attachment points (and I have notice that it screws up the internals of at least one Add'On pretty badly). Since rerooting a subassembly is almost essential when attaching subassemblies to the main hull, I think we have an explanation for a lot of bug reports I had received in the past that I never managed to reproduce, because only recently one user had the presence of mind to meticulously describe how to reproduce the problem step by step and I finally noticed the involvement of the reroot on the mess. The rerooting problem was not tackled down yet, and this is a problem for everybody using subassemblies. However, this is affecting everybody since KSP 1.8, so upgrading to KSP-Recall will not make things any worse. On a side note: it will not hurt if you backup your whole installation before upgrading and then spend some time toying with the upgrade before deciding to keep it. I will speak openly about this: I never tested upgrading TweakScale or KSP-Recall more than one or two releases, so your use case (upgrading from a pretty old TweakScale without KSP-Recall) was never really tested. I remember coding features for this use case a long time ago, so it's intended to work - if you find some problem while doing this, please file a bug report and I will fix it (I will need a copy of your original savegame so I can have something to work with. Sending me the screwed one will also help, as I will have something to compare with in less time). Cheers!

Strictly and technically speaking, yes. "Linux" is the name of the Kernel, what we are used to call "Linux" among us, users, are technically a "Gnu/Linux" distribution, because it's an amalgam with the Linux (the Kernel) and the Gnu toolchain (bash, gcc, bintools, etc). As a matter of fact, there are some people using the BSD toolchain over the Linux Kernel in some applications - as well as using the Gnu toolchain in other kernels (as Dyson, a distro using a kernel derivate from the OpenSolaris into Debian). Android is an Linux based Operating System, make no mistake about (see it as a Google/Linux distribution). It only happens that Google wrote a huge abstraction layer on top of it, to the point they are trying to replace the kernel with a new custom one (Zircon) on a thingy called Fuchsia.

This is a long term fight, we are not going to get it next week even if we would be exceptionally successful on the endeavour. The first step is to mass promote the idea on the social media, including your personal ones. Twitter, Facebook, GETR, reddit, tiktok, you name it. We need to demonstrate people that if we can do good right now, we would be able to do a lot better having (legal) access to the source code. We need to prove that we are able to help, so P.D. can perceive value on the movement - no Company does things just to be nice (well, Sun did some in the past and then Oracle bought them), they need to earn something on this bargain. Again, see ID Software, that published the sources for Wolf3d, Doom and Quake series and are still rock solid nowadays: every time someone ports Doom to something, they are promoting ID indirectly and keeping the Doom franchise alive. Additionally, "full" (please note the quotes) rights to the Source Code is not mandatory, besides being desirable. P.D. have plans to the future and they may be unsure if Opening (in the OSI conception) the Source will not mangle these plans, so preventing the reuse of the code like Unity does with its licensing terms is still an option. My opinion is that going OSI will not be damaging, they would not be waving the Kerbals as Intelectual Property, no one will be able to (legally) republish KSP and earn money at their expenses - and people are already pirating the game on the wild without (legally access to) the Source, so nothing to loose on this end - and if they release the thing as a GPL-like license, anyone publishing anything using this code will be forced to publish any modification they did on the code, what will help to improve the engine - that may be outdated and even crappy right now, but it still cuts it and so, it's still useful. And by people improving the OSI source code, they will be generating knowledge that will be useful into improving KSP2 in the future (since part of KSP2 had feed from the KSP(1) code), not to mention the console problem right now. By this time, KSP(1) source code is not a technological feature asset per se, is more like a commodity. We aggregate value on it using I.P., and this is sill tremendous strong on KSP. Kerbal is still a thing, a powerful name - no one cares for the code, other than programmers - we care for Jebediah, Valentina, Bill and Bob (and the randomly created Kerbals we acquired on gaming), and they are the real value of the Franchise, not the code. See Linux, anyone can fork and make a derivative, but how many succeeded on it other than Google (and even they had to create a strong name on Android first)? But, yet, we can live for now without KSP going OSI - what we really need is access to the Source so we can understand what's happening and what we need to do on our side to keep this thingy healthy (these are not mutually exclusive solutions anyway, they can go OSI later). Our task, right now, is to promote this idea: that going OSI is not the only option, even by going Unity everybody will still be immensely beneficed (including them), and that we can manage to do it (just look what we managed to accomplish without reading the Source, now imagine what we can do with). It would be interesting to exchange ideas about how to do it. Videos on Youtube and Tiktok? Someone here knows someone on Ars Technica? Do you guys know Slashdot, someone with a better score than me (not to mention a better English) would like to write an article on Slashdot about it?

It's BDArmory, they have a mishap on one of their patches. [LOG 19:51:40.033] [TweakScale] ERROR: **FATAL** Part BDA.EJ200 (TFJ-EJ200 "Typhoon" Afterburning Turbofan) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 Rollback BDArmory to the previous release for while, I heard they are aware of the problem and it should be fixed Soon™ https://github.com/TweakScale/TweakScale/discussions/301

The real issue if that Module Manager is being instantiated twice (or even more). If only one copy of ModuleManager would be in execution, the situation in which it would try to compute the SHA for a given file in different threads would just not happen. Having multiple Module Managers running at the same time on the rig is terrible, with some patches ending up being corrupted (by some reason, the Localization ones are specially prone to the problem). I had said before, and I will say it again: there must be only ONE Module Manager running in memory, and without solving this problem, people will still be screwed by bad patching happening randomly across the system. Once you secure only one ModuleManager running at a given time, you don't need to scramble patching every single place where code that was meant to run solo subtly is facing concurrency with itself.

Hi! You was bitten by a nasty internal KSP bug on a thingy called Assembly Loader/Resolver - this bug is triggered when something tries to load a dependency and fails, and from this point, everything and the kitchen's sink gets screwed when trying to load a DLL or use a thingy called Reflection, that is exactly what TweakScale and the Companions do a lot. In your case, the problem is ScrapYard_ContractConfigurator.dll. You probably don't have Contract Configurator installed, and so it's failing to be loaded, and the AL/R bug is triggered. Install Contract Configurator or delete GameData\ScrapYard\Plugins\ScrapYard_ContractConfigurator.dll and you will be fine. Cheers.

Well, CKAN problems should be reported to CKAN themselves, as I don't have control about how they do things there. All I can do is try to do a preflight check about what their robot is doing and save some time. The NetKAN file looks good: https://github.com/KSP-CKAN/NetKAN/blob/master/NetKAN/DistantObject.netkan My repository is online: https://github.com/net-lisias-ksp/DistantObject/releases And the meta files are fine too: https://github.com/KSP-CKAN/CKAN-meta/tree/master/DistantObject https://github.com/KSP-CKAN/CKAN-meta/tree/master/DistantObject-default In special: https://github.com/KSP-CKAN/CKAN-meta/blob/master/DistantObject/DistantObject-v2.1.1.12.ckan https://github.com/KSP-CKAN/CKAN-meta/blob/master/DistantObject-default/DistantObject-default-v2.1.1.12.ckan So, nope. CKAN itself is looking fine. Perhaps SpaceDock? https://spacedock.info/mod/2274/Distant Object Enhancement / Humm… Nope, it looks fine too. I tried a direct download using the download link from the CKAN file, https://spacedock.info/mod/2274/Distant Object Enhancement /L/download/2.1.1.12 , and it worked too. So I don't have the slightest idea about what could be happening, but it looks link something on the CKAN application itself. You will need to reach CKAN guys for help.

Hi. Recently, a mishap on BDArmory injected a double patch problem that was flagged by TweakScale. Since you have BDArmory installed, I'm betting this is your case. Try to rollback BDArmory to the previous version and see what happens, it worked for some people. https://github.com/TweakScale/TweakScale/discussions/301 Additionally, posting the KSP.log is way better than the mod list - in 95% of the times, the KSP.log have enough information for diagnosing the problem without the need of reproducing your installment and firing up KSP, what saves a huge amount of time. In this case, I was able to (probably) quick diagnose your problem because I have a flood of other people with this problem. Anyway - the solution is to rollback BDArmory to the previous release for while - and don't forget to file a bug report for the BDArmory's manintainers if it works for you. If it didn't solve your problem, publish your KSP.log and I will inspect it! Good luck!

There's an ongoing battle on reddit. The OP's post there is being continuously upvoted and downvoted! It reached 10 upvotes somewhere in the morning, then got to 5, then upvoted to 8, now is on 5 again. Apparently we had hit some nerve… @WhatALovelyNick, you earned one week on the r/lounge. It's nothing special, other that frequented by very fewer people. Perhaps you could get more traction there, with less people trolling you? Click in your Profile Picture top right in the page (on Desktop), then Account Settings on the DropDown Menu, then Signature on the Left Panel. — — Post Post Edit — — Now it's on 8 again! Now it's on 5! Now it's on 4! Now it's on 6! Now it's on 9! Now it's on 8 again! I may not look like, but the thing is kinda on fire - lots of people downvoting and upvoting the thing - each reload is a new score!

Sometimes nothing happens, sometimes you get royally screwed, sometimes even KSP goes to a CTD - it depends on what parts is being double patched and what PartModules it uses. Since it's impossible to write a code that could analyse every single combination (not to mention being aware of them before they happens!), the less worst solution is to bark on every double patch being found. I agree it's a pain in the SAS, but it's better than losing your savegames. Even by doing backups, you lose your progression since the last one so it's still an annoyance. Well, back to business: this is the list of patched being applied to the offended part: [LOG 10:54:24.953] Applying update 999_KSP-Recall/patches/fundskeeper/@PART[*]:HAS[!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA]]:NEEDS[KSPRECALL-FUNDSKEEPER] to BDArmory/Parts/EJ200/caesar_hone_60.cfg/PART[BDA_EJ200] [LOG 10:54:25.109] Applying update 999_KSP-Recall/patches/refunding/@PART[*]:HAS[!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA]]:NEEDS[KSPRECALL-REFUNDING] to BDArmory/Parts/EJ200/caesar_hone_60.cfg/PART[BDA_EJ200] [LOG 10:54:25.279] Applying update 999_KSP-Recall/patches/stealbackfunds/@PART[*]:HAS[!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA]]:NEEDS[KSPRECALL-STEALBACKFUNDS] to BDArmory/Parts/EJ200/caesar_hone_60.cfg/PART[BDA_EJ200] [LOG 10:54:25.577] Applying update BDArmory/MMPatches/000000_HitpointModule/@PART[*] to BDArmory/Parts/EJ200/caesar_hone_60.cfg/PART[BDA_EJ200] [LOG 10:54:26.380] Applying update BDArmory/MMPatches/BDA_battledamage/@PART[*]:HAS[@MODULE[ModuleEnginesFX]] to BDArmory/Parts/EJ200/caesar_hone_60.cfg/PART[BDA_EJ200] [LOG 10:54:26.601] Applying update BDArmory/Parts/EJ200/caesar_hone_60_TS/@PART[BDA_EJ200] to BDArmory/Parts/EJ200/caesar_hone_60.cfg/PART[BDA_EJ200] [LOG 10:54:36.352] Applying update SimpleRepaint/Patches/SimpleRepaint/@PART[*]:HAS[~SR_Ignore[]]:FOR[zzzzzzSimpleRepaint] to BDArmory/Parts/EJ200/caesar_hone_60.cfg/PART[BDA_EJ200] [LOG 10:54:36.595] Applying update SimpleRepaint/Patches/SimpleRepaint/@PART[*]:HAS[~SR_Ignore[],~SR_RepaintType[]]:NEEDS[B9PartSwitch]:FOR[zzzzzzSimpleRepaint] to BDArmory/Parts/EJ200/caesar_hone_60.cfg/PART[BDA_EJ200] [LOG 10:54:37.302] Applying update SimpleRepaint/Patches/SimpleRepaint/@PART[*]:HAS[~SR_Ignore[],#SR_RepaintType[B9PS],#SR_MaterialMask1[*]]:NEEDS[B9PartSwitch]:FOR[zzzzzzSimpleRepaint] to BDArmory/Parts/EJ200/caesar_hone_60.cfg/PART[BDA_EJ200] [LOG 10:54:51.930] Applying update SimpleRepaint/Patches/SimpleRepaint/@PART[*]:HAS[~SR_Ignore[],@MODULE[ModuleB9PartSwitch]:HAS[#moduleID[SimpleRepaint]]]:NEEDS[B9PartSwitch]:FOR[zzzzzzSimpleRepaint] to BDArmory/Parts/EJ200/caesar_hone_60.cfg/PART[BDA_EJ200] [LOG 10:54:52.744] Applying update SimpleRepaint/Patches/SimpleRepaint/@PART[*]:HAS[#SR_RepaintType[*]]:AFTER[zzzzzzSimpleRepaint] to BDArmory/Parts/EJ200/caesar_hone_60.cfg/PART[BDA_EJ200] [LOG 10:54:52.940] Applying update SimpleRepaint/Patches/SimpleRepaint/@PART[*]:HAS[#SR_WhitelistOnly[*]]:AFTER[zzzzzzSimpleRepaint] to BDArmory/Parts/EJ200/caesar_hone_60.cfg/PART[BDA_EJ200] [LOG 10:54:53.219] Applying update KSPCommunityFixes/MMPatches/ModSupport/KSPRecall/@PART[*]:HAS[@MODULE[Refunding]]:LAST[999_KSP-Recall] to BDArmory/Parts/EJ200/caesar_hone_60.cfg/PART[BDA_EJ200] [LOG 10:54:53.561] Applying update KSPCommunityFixes/MMPatches/ModSupport/KSPRecall/@PART[*]:HAS[#hasRefundingOnRecovery[?rue]]:LAST[999_KSP-Recall] to BDArmory/Parts/EJ200/caesar_hone_60.cfg/PART[BDA_EJ200] [LOG 10:54:53.900] Applying update KSPCommunityFixes/MMPatches/ModSupport/KSPRecall/@PART[*]:HAS[#hasRefundingOnRecovery]:LAST[999_KSP-Recall] to BDArmory/Parts/EJ200/caesar_hone_60.cfg/PART[BDA_EJ200] [LOG 10:54:54.145] Applying update 999_KSP-Recall/patches/attached-on-editor/@PART[*]:HAS[!MODULE[ProceduralPart],!MODULE[WingProcedural],!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA]]:LAST[KSPRECALL-ATTACHED-ON-EDITOR]:NEEDS[TweakScale] to BDArmory/Parts/EJ200/caesar_hone_60.cfg/PART[BDA_EJ200] KSP-Recall and KSPCommunityFixes don't touch TweakScale, so we can rule them out for sure. So we have BDArmory itself, or SimpleRepaint as possible suspects. Temporarily remove SimpleRepaint and see if the problem goes away. If yes, then file a bug report to SimpleRepaint maintainers, as it has somehow a buggy patch on it involving TweakScale. On the other hand, if by removing SimpleRepaint you still get the problem, then the only remaining suspect is BDArmory itself, and then you need to reach them to file a bug report and ask for the fix. Where the fix is to look on their patches and remove the double patching - the log excerpt above tells exactly what are the possible offenders, so I think they can zero in the culprit pretty fast! Let me know when the problem is solved! — — POST EDIT — — Another Kerbonaut have the same issue, reported on github. The only add'ons you and they have in common is KSP-Recall (that doesn't applies TweakScale patches, so it's ruled out) and BDArmory itself on the following patches: BDArmory/MMPatches/000000_HitpointModule/@part[*] BDArmory/MMPatches/BDA_battledamage/@part[*]:HAS[@module[ModuleEnginesFX]] BDArmory/Parts/EJ200/caesar_hone_60_TS/@part[BDA_EJ200] I think we can declare BDArmory as the current main (and only) suspect!

A image with Valentina dressed as the Princess would be nice, no?

Sure thing! As soon as someone send me the KSP.log so I can check the patches and see what's happening!

Spreading the word in the social networks. Twitter, Facebook, TikTok, you name it. Giving some awards on the reddit will also help the cause. — post edit — The Source must flow!!

Something is double patching your GameData. Send me your KSP.log as well your ModuleManager's patch log and I will diagnose the problem. In time, this is not a TweakScale problem. TweakScale is the one telling you about the problem.

It originally intent to meant that the installation was faulty and something was forgotten to be copied, but then we found a bug on KSP on a thingy called Assembly Loader/Resolver - a component responsible for loading DLL and resolving dependencies. The bug is that once anything fails to be loaded (by absolutely any reason, from missing dependencies to borked DLLs), it triggers this bug and from that point, everything else trying to be loaded fails too no matter what - it's terribly annoying. CKAN makes things worse because they don't really have a proactive approach on QAS, they just reacts when people complains - not rarely blaming the wrong author for the problem, what ends up perpetuating it. So, back to your problem: if TweaakScale is installed correctly (an 99.9% of the times, it is), then CKAN updated something that broke a 3rd party that leades to the AL/R problem, that screwed TweakScale that so is yelling about the problem - and make no mistake, it's not only TweakScale being affect, but everybody else (it only happens that TweakScale prefers to alert you instead of making believe nothing is happening and letting you get screwed later on the savegame). You will find the trigger for the problem (not necessarily the cause of it) by looking for every occurrence of a Reflection or Loading exception in your KSP.log. If you don't have MechJeb installed, the first occurrence will pinpoint the cause - you will need to diagnose it or to remove it. With MJ installed, things get a bit messy because MJ do some things internally that ends up shuffling the order in which things are logged on the KSP.log, I found that it's easier to temporarily remove MJ to reproduce the error without the shuffling, fix the problem, and then install MJ2 back instead of trying to figure out where the problem ends up going when MJ2 is installed. Alternatively, you can post your KSP.log here (without MJ2 installed, please - reinstall it later when fixed) and I will do the heavy lifting for you! Cheers!

If we are talking about the issue reported here: Then you need to remove GameData/TweakScaleCompanion and then reinstall it. TweakScale is not the problem, it the one telling you about the problem. The previous TSCo was shipped with a faulty component, that I removed on the ..4 release, and so you need to completely remove the TweakScaleCompanion folder in order to be fine. Remove TweakScaleCompanion this time and try again. If anything goes south, you will find the KSP.log on the same folder the KSP's .exe is. You will find further instructions on this link.

Completely remove all the TweakScaleCompanion directories and files, then install the latest one - a faulty component was removed, and if you just install the new one over the older, the faulty component will still be there. If by completely removing the older contents before installing the new release the problem is solved, then you found a problem on CKAN. Otherwise, post the KSP.log on the TweakScale's thread and I will inspect it. Cheers!

We need every single bit of help possible, and yours will be hugely appreciated! Thank you!