Lisias

Well, I finally take a look on your KSP.log. (could not sleep, I had a crash on a production server this week and I'm cleaning up things there, and this takes a lot of time...) What follows are things that can or not be affecting you. But they are mistakes nevertheless, so it worths the trouble of fixing it. I found some instances of this error: [LOG 16:02:42.449] AssetLoader: Loaded bundle 'C:\Users\t8491\Documents\Kerbal Space Program - copia\GameData\Squad\KSPedia\kspedia_variantswitcher.ksp' [ERR 16:02:43.478] The file can not be loaded because it was created for another build target that is not compatible with this platform. Please make sure to build AssetBundles using the build target platform that it is used by. File's Build target is: 6 [ERR 16:02:43.479] Unknown error occurred while loading 'archive:/CAB-7ec8318d487c56e2a1778473f347f933/CAB-7ec8318d487c56e2a1778473f347f933'. [ERR 16:02:43.479] The AssetBundle 'file://C:\Users\t8491\Documents\Kerbal Space Program - copia\GameData\BDArmory\KSPedia\bdac addons.ksp' can't be loaded because it was [ERR 16:02:43.479] Error while getting Asset Bundle: The AssetBundle 'file://C:\Users\t8491\Documents\Kerbal Space Program - copia\GameData\BDArmory\KSPedia\bdac addons.k [ERR 16:02:43.479] AssetLoader: Bundle is null [ERR 16:02:43.982] The file can not be loaded because it was created for another build target that is not compatible with this platform. Please make sure to build AssetBundles using the build target platform that it is used by. File's Build target is: 6 We have two problems here, both from your KSP itself. There's a race condition on accessing the Unity Log, that it's not thread safe. Install KSPApiExtensions/L (or just the 000_KSPe.dll from the package), this fixes this and we will start to get better logs from your instalment Apparently KSP is trying to load something that was intended to be used on a previous version! I checked my own test beds (yeah, I have a test bed for every KSP version released since 1.1.3! How do you think I learn so much??? ), and this message is not there, so it's not a fsckup from Squad for sure. I think you copied some things from other KSP version by accident. If I am right, we have an excellent suspect for your problems, we may had found that Oldie playing havoc on your system! Download a clean copy of KSP 1.8.1, and move only things not from Squad and SquadExpansion from this "copia" . Leave the savegames, screenshots, etc, on the original place for while, then start doing crazy things on the new copy you know for sure had caused problems for you in the past. Good hunting!

Hi. I have kicked out TweakScale Companion Program exactly for these situations. Post a request on that thread, linking me to where to fetch the Add'Ons you are interested on have support, and I (or someone else, if I find a volunteer) will tackle it down as time allows.

Got it. [LOG 20:02:45.189] [TweakScale] INFO: WriteDryCost Concluded : 4836 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 36 Show Stoppers found; 68 Sanity Check failed; 2620 unscalable parts. Well, pretty decent instalment. 4836 parts, being 2620 parts that will not scale due lack of patch (or a problem detected, see the 36 and 68 ones, they are on this basket). That 68 parts are parts that TweakScale needs to implement proper support, most of the time. Trying to scale them now would lead to problems, so TweakScale withdraws itself from that parts. Some os that parts are already fixed on TweakScaleCompanion for Firespitter (roll that wall of text until you see it) if you are interested. The problematic parts are that 36 ones, with FATALities: Let's check one of them, KSRO-SITVC-RCS: [LOG 19:52:03.350] Applying update Contares/Patches/CONTARES_TweakScale/@PART[KSRO-SITVC-RCS] to Contares_IND/Parts/KSRO/KSRO-SITVC-RCS.cfg/PART[KSRO-SITVC-RCS] [LOG 19:52:03.588] Applying update Contares_IND/Patches/Contares_IND_TweakScale/@PART[KSRO-SITVC-RCS] to Contares_IND/Parts/KSRO/KSRO-SITVC-RCS.cfg/PART[KSRO-SITVC-RCS] [LOG 19:52:06.856] Applying update ModularFuelTanks/Propellants/@PART[*]:HAS[@MODULE[ModuleEnginesFX]] to Contares_IND/Parts/KSRO/KSRO-SITVC-RCS.cfg/PART[KSRO-SITVC-RCS] [LOG 19:52:16.375] Applying update StationScience/MKSEffects/@PART:NEEDS[MKS] to Contares_IND/Parts/KSRO/KSRO-SITVC-RCS.cfg/PART[KSRO-SITVC-RCS] [LOG 19:52:28.696] Applying update UmbraSpaceIndustries/MKS/Patches/ScrapParts/@PART[*]:HAS[!MODULE[FlagSite],!MODULE[KerbalEVA]] to Contares_IND/Parts/KSRO/KSRO-SITVC-RCS.cfg/PART[KSRO-SITVC-RCS] [LOG 19:52:30.493] Applying update WildBlueIndustries/Pathfinder/ModuleManagerPatches/MM_Skills/@PART[*]:NEEDS[Pathfinder]:HAS[!MODULE[KerbalEVA],!MODULE[ModuleAsteroid]] to Contares_IND/Parts/KSRO/KSRO-SITVC-RCS.cfg/PART[KSRO-SITVC-RCS] [LOG 19:52:32.552] Applying update AtmosphereAutopilot/csurf_sync/@PART[*]:HAS[@MODULE[ModuleGimbal]]:FOR[AtmosphereAutopilot] to Contares_IND/Parts/KSRO/KSRO-SITVC-RCS.cfg/PART[KSRO-SITVC-RCS] [LOG 19:52:42.109] Applying update Contares_IND/Patches/Contares_IND_plume/@PART[KSRO-SITVC-RCS]:FOR[RealPlume]:NEEDS[SmokeScreen] to Contares_IND/Parts/KSRO/KSRO-SITVC-RCS.cfg/PART[KSRO-SITVC-RCS] [LOG 19:52:45.114] Applying update RealPlume/000_Generic_Plumes/000_EFFECTS_Remover/@PART[*]:HAS[@PLUME[*]]:AFTER[RealPlume]:NEEDS[SmokeScreen] to Contares_IND/Parts/KSRO/KSRO-SITVC-RCS.cfg/PART[KSRO-SITVC-RCS] [LOG 19:52:45.264] Applying update RealPlume/000_Generic_Plumes/000_EFFECTS_Remover/@PART[*]:HAS[@PLUME[*],@MODULE[ModuleEngines*],!MODULE[ModuleRCSFX]]:AFTER[RealPlume]:NEEDS[SmokeScreen] to Contares_IND/Parts/KSRO/KSRO-SITVC-RCS.cfg/PART[KSRO-SITVC-RCS] [LOG 19:52:52.126] Applying update RealPlume/000_Generic_Plumes/000_zRealPlume/@PART[*]:HAS[@PLUME[*]]:FOR[zRealPlume]:NEEDS[SmokeScreen] to Contares_IND/Parts/KSRO/KSRO-SITVC-RCS.cfg/PART[KSRO-SITVC-RCS] [LOG 19:52:57.013] Applying update RealPlume/000_Generic_Plumes/Deprecated/Hypergolic-Upper/@PART[*]:HAS[@PLUME[Hypergolic-Upper]:HAS[~processed[*]]]:AFTER[zRealPlume]:NEEDS[SmokeScreen] to Contares_IND/Parts/KSRO/KSRO-SITVC-RCS.cfg/PART[KSRO-SITVC-RCS] [LOG 19:53:00.744] Applying update RealPlume-Stock/Global Patches/@PART[*]:HAS[@PLUME[*],@MODULE[ModuleEngines*]]:FOR[zzzRealPlumeStock] to Contares_IND/Parts/KSRO/KSRO-SITVC-RCS.cfg/PART[KSRO-SITVC-RCS] Interesting. The first two patches appears to reveal the problem, Contares and Contares_IMD are patching it. So I checked another part (only the first two updates): [LOG 19:52:03.392] Applying update Contares/Patches/CONTARES_TweakScale/@PART[KhiSP_SZ] to Contares_KHI/Parts/KhiNa/KhiSP_SZ.cfg/PART[KhiSP_SZ] [LOG 19:52:03.604] Applying update Contares_KHI/Patches/CONTARES_KHI_TweakScale/@PART[KhiSP_SZ] to Contares_KHI/Parts/KhiNa/KhiSP_SZ.cfg/PART[KhiSP_SZ] Now we have a double patching from Contares and from Contares_KHI. So I checked another one, RK-Z-0110 : [LOG 19:52:03.460] Applying update Contares/Patches/CONTARES_TweakScale/@PART[RK-Z-0110] to Contares_RUS/Parts/UNION-2/RK-Z-0110.cfg/PART[RK-Z-0110] [LOG 19:52:03.848] Applying update Contares_RUS/Patches/Contares_RUS_TweakScale/@PART[RK-Z-0110] to Contares_RUS/Parts/UNION-2/RK-Z-0110.cfg/PART[RK-Z-0110] Now we have a double patching from Contares and from Contares_RUS. Well, we have a pattern. Let's go for the trusses (truss-octo-01) and see what we get: [LOG 19:52:03.575] Applying update Contares/Patches/CONTARES_TweakScale/@PART[truss-octo-*] to NearFutureConstruction/Parts/Truss/truss-octo/truss-octo-01.cfg/PART[truss-octo-01] [LOG 19:52:09.738] Applying update NearFutureConstruction/Patches/NFConstructionCRPTrusses/@PART[truss-octo-01]:NEEDS[CommunityResourcePack&CryoTanks] to NearFutureConstruction/Parts/Truss/truss-octo/truss-octo-01.cfg/PART[truss-octo-01] [LOG 19:52:16.469] Applying update StationScience/MKSEffects/@PART:NEEDS[MKS] to NearFutureConstruction/Parts/Truss/truss-octo/truss-octo-01.cfg/PART[truss-octo-01] [LOG 19:52:23.169] Applying update TweakScale/patches/NF/NFC_TweakScale/@PART[truss-octo-01] to NearFutureConstruction/Parts/Truss/truss-octo/truss-octo-01.cfg/PART[truss-octo-01] [LOG 19:52:28.782] Applying update UmbraSpaceIndustries/MKS/Patches/ScrapParts/@PART[*]:HAS[!MODULE[FlagSite],!MODULE[KerbalEVA]] to NearFutureConstruction/Parts/Truss/truss-octo/truss-octo-01.cfg/PART[truss-octo-01] [LOG 19:52:30.602] Applying update WildBlueIndustries/Pathfinder/ModuleManagerPatches/MM_Skills/@PART[*]:NEEDS[Pathfinder]:HAS[!MODULE[KerbalEVA],!MODULE[ModuleAsteroid]] to NearFutureConstruction/Parts/Truss/truss-octo/truss-octo-01.cfg/PART[truss-octo-01] [LOG 19:52:37.978] Applying update NearFutureConstruction/Patches/NFConstructionCRPTrusses/@PART[truss-octo-01]:NEEDS[CommunityResourcePack]:FOR[NearFutureConstruction] to NearFutureConstruction/Parts/Truss/truss-octo/truss-octo-01.cfg/PART[truss-octo-01] [LOG 19:53:01.025] Applying update B9PartSwitch/PartInfo/@PART[*]:HAS[@MODULE[ModuleB9PartSwitch]]:FOR[zzzzzz-B9PartSwitch] to NearFutureConstruction/Parts/Truss/truss-octo/truss-octo-01.cfg/PART[truss-octo-01] And again, Contares. (sigh) I think you should file a bug report on Contares, as I did here. But until (or if) they fix it, delete Contares/Patches/CONTARES_TweakScale.cfg . This file is double patching everything, including TweakScale's default patches. It's the same problem I diagnosed previously, but with steroids. Welcome. Yeah, the warning is really meant to me scary - a fellow Kerbonaut recently lost a 2.5 years savegame recently due a mishap while trying to fix his rig. Things can go down through the tubes pretty fast, as an inconsistent GameDatabase will corrupt the savegame on loading, and once it's loaded and corrupted, it's doomed as it will be saved over the previous one. It's the reason I push S.A.V.E. for everybody. The scary part is that TweakScale only tries to avoid the problems that affect it. Any other Add'On are susceptible to this problem, as Fuel Switches. KSP overwrites the Module data with a corrupted copy on every part on every craft on a savegame, how you will restore it? Some savegames has hundreds or thousands on parts on the Universe... And unfixed older versions of Add'Ons means old conflicts. Now we mix them, and we have a whole new set of conflicts to handle. Patching in the old days was a mess, I detected parts with 3, 4 copies of the patching data and if you install or deinstall something, the data changes and then everything that use that part goes kaput on the next load.

Please publish on DropBox, Google Drive or something the full KSP.log, otherwise I can't help you. Don't use pastebin, gist or similar as they truncate the file, rendering it useless. See the OP (on the Support spoiler) for instructions about how to proceed.

Yes. I was orbiting Kerbin while taking care of my own business when that piece of rock that calls itself Mün, completly drunk, crossed my way came from nowhere and blowed everything. And it ran away as nothing had happened. Humpf.

These 9 are parts with Module Part Variant with Mass - something that was causing problems in the past. This is expected to be fixed on TweakScale 2.4.4, hopefully to be released in a couple weeks. You can ignore these ones

Well... apparently it worked... [LOG 16:58:42.418] [ModuleManager] INFO: Applying update __LOCAL/TweakScale/Tantares/virgo_fuel_tank_s1_2/@PART[virgo_fuel_tank_s1_2]:NEEDS[Tantares,Tw eakScale] to Tantares/Parts/LOK/_virgo_fuel_tank_s1_2/PART And there's no error after. Follows an excerpt from the ModuleManager.ConfigCache: UrlConfig { name = virgo_fuel_tank_s1_2 type = PART parentUrl = Tantares/Parts/LOK/_virgo_fuel_tank_s1_2 PART { name = virgo_fuel_tank_s1_2 module = Part author = Tantares yada yada yada MODULE { name = TweakScale type = stack defaultScale = 1.25 scaleFactors = 0.1, 0.3, 0.625, 0.9375, 1.25, 1.5, 1.875, 2.5, 3.125, 3.75, 5, 10, 20 incrementSlide = 0.01, 0.05, 0.05, 0.05, 0.05, 0.05, 0.05, 0.05, 0.5, 0.05 } } } So things apparently are working. And... It works for me! Follows a exact copy & paste from my config file: @PART[virgo_fuel_tank_s1_2]:NEEDS[Tantares,TweakScale] // Tantares Size 0.5 to Size 0 Adapter { %MODULE[TweakScale] { type = stack defaultScale = 1.25 scaleFactors = 0.1, 0.3, 0.625, 0.9375, 1.25, 1.5, 1.875, 2.5, 3.125, 3.75, 5, 10, 20 incrementSlide = 0.01, 0.05, 0.05, 0.05, 0.05, 0.05, 0.05, 0.05, 0.5, 0.05 } } It's exactly as yours , only better whitespaced. Check if you installed TweakScale, or if there's something missing on it. I just borked the first try because I forgot to install 999_Scale_Redist.dll on a clean KSP 1.9.1 (yeah, it happens even to me!)

It's a good guess. I will check it by night. Or perhaps they are the ones being borked by something else. That problem works both ways. It's a wild guess, because there're different custom modules doing the same task (as wheels), but still a good guess. KSI! Once we pinpoint a viable suspect, someone needs to check the code for source of problems. Once a problem is found, someone needs to fix it, and it will depend on the license of the thing. ARR and CC-ND thingies are things hostile to collaboration (to fix that thing, I would need to download and change it and send it to someone to test - effectively creating a derivative and so, violating the license). But once the license permits, yes - someone (me, other guy or the author) will fix the code and publish a new version. Be aware that things can be a bit more complicated than that. Some code shares things that are not obvious, as a GUI helper or some library to calculate physics, whatever. So the "Similar" criteria, besides useful sometimes, is not accurate. On this specific case, we are looking for something allocating things on Update, FixedUpdate or LateUpdate and forgetting to deallocated i, as hinted by this log line: [WRN 16:25:46.084] Internal: JobTempAlloc has allocations that are more than 4 frames old - this is not allowed and likely a leak This can be happening due a old code that used to do so on a time which Unity didn't cared about this, or may be something inducing other thing to bork on one of the Updates code (and so, the code is interrupted before deallocating the memory). Pretty messy, uh?

I kinda managed to reproduce it on vanilla KSP toying with the Landing Legs. The landing legs (and the Wheels) are trembling badly,, inducing the craft to turn. It appears to be a bug on the stock module itself, my guess is something wrong with the ModuleWheelSuspension. I managed to reproduce it pretty easily, on a pure stock instalment (no add'ons, only Squad and SquadExpansion): https://imgur.com/cSC1MeQ The craft could not be simpler: The trembling is way worse than appears on the GIF above. I used 50 ms per frame on that animation, I think I would need about 5ms per frame to correctly show the trembling. It may help you because if you deactivate the auto-adjust and set the Springs to max, things started to explode here, and the craft started to turn violently. It appears to be something on the Springs - they keep trembling, and so the feet lose contact with the ground, friction is reduced, and it moves. Interesting that Wheels trembles in a way that the craft turns counter-clockwise, while these landing legs moves the craft clockwise. And.... yes, this is not exactly off-topic. As TweakScale scales these Modules, it may potentialise the effect. I was wise on keeping the Wheels scaling only on TweakScale Beta, as something appears to had gone backwards on KSP 1.9 (or perhaps 1.8 - I'm really not playing these new versions, I just testing on it). On KSP 1.7 I don't remember seeing something like this.

Spoiler: he survives.

Hi. Without the full KSP.log and, since you machine is crashing, the Player.log too, we can't do too much. Please publish KSP.log and Player.log on a file sharing service as DropBox or Google Drive. Using snippets sharing services as gist or pastbin will not do, as they have limits on the file size to be shared and these log files are way bigger than that. Give a peek on TweakScale's OP under the Spoiler Support in order to learn where to get those files.

Every time you add or remove an Add'On, yes. Not that much. KSP (correctly) writes every DLL being loaded on startup, so there's only one place to look when we are searching for this specific problem. The Reflection system lies about the from which DLL the current Assembly was loaded, but tells the true about the DLLs that have an Assembly with that name, so this is still useful to diagnose this problem - essentially, it will pinpoint every DLL with an Assembly with that name, being it the loaded one or not. Almost it. The first Assembly loaded is really loaded. The second copy of that Assembly is not, but an entry on the "Pool" is created as it were, besides pinpoint the first one. Let me exemplify to you using that problem with MM that bitten me in the SAS recently: This is the log of MM trying to elect the correct one to be used on KSP 1.7.3: [LOG 22:11:56.202] [ModuleManager] INFO: version 4.1.3.1 at /.users/lisias/Workspaces/KSP/runtime/1.7.3/GameData/ModuleManager.dll won the election against Version 4.1.3.0 /.users/lisias/Workspaces/KSP/runtime/1.7.3/GameData/ModuleManager.4.1.3.dll Version 4.0.3.0 /.users/lisias/Workspaces/KSP/runtime/1.7.3/GameData/ModuleManager.4.0.3.dll Version 4.0.2.0 /.users/lisias/Workspaces/KSP/runtime/1.7.3/GameData/ModuleManager.4.0.2.dll Version 3.1.1.0 /.users/lisias/Workspaces/KSP/runtime/1.7.3/GameData/ModuleManager.3.1.1.dll Version 3.0.4.0 /.users/lisias/Workspaces/KSP/runtime/1.7.3/GameData/ModuleManager.3.0.4.dll And this is what happens on KSP 1.8 and above: [LOG 21:03:53.892] [ModuleManager] INFO: version 4.1.3.1 at /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.1.0.0.dll won the election against Version 4.1.3.1 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.3.0.4.dll Version 4.1.3.1 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.3.1.1.dll Version 4.1.3.1 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.4.0.2.dll Version 4.1.3.1 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.4.0.3.dll Version 4.1.3.1 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.4.1.3.dll The DLLs used are the same on both KSPs (my Add"Ons works fine on both, and I recompiled MM to be used this way). "Version" is fetched from the Assembly, the pathname is where the Assembly were loaded. The filename is irrelevant from the Assembly point of view, you cane name the DLL "ModuleManager-Forever-666.666.666.dll" and this will means nothing on the runtime, the Assembly still will be named "ModuleManager" and the Version will be fetched from the Assembly the same. So, on KSP >= 1.8, we can conclude that only the first Assembly is really loaded (as I forced a 4.1.3.1 one to be loaded from a file named "ModuleManager.1.0.0.0.dll"), and all remaining ones were ignored but yet a entry on the Pool was created pinpoint the first one - and the thing lies to us telling that it was loaded from that other file. Would would be a better choice of words. We are speculating about a possible explanation for the problem, as the M.O. of this known bandit is pretty similar to what is happening to you. It may be a new bandit copycatting the known one - but if we don't give this a try, we will never know. Yeah - this is pretty similar to a crime scene. It will not work because the order of file loading. KSP sorts the whole GameData, and starts loading things using this list. So, you install AddOn "GameData/FancyPants/MyDll.dll" and then "GameData/UglyPants/MyDll.dll" - whatever is being loaded on UglyPants, will be loaded always after the FancyPants because of the ordering. So things are, thanks God, deterministic about the order of loading. What we are looking for, however, is about duplicated Assemblies inside that dlls. Let's suppose that on UglyPants/MyDll.dll we have the Assembly "Pants" Version 1.0 , but FancyPants/MyDll.dll have the "Pants" Version 0.5 , let's say it's from the time it was still Alpha. You install only Fancy Pants, things do work - because the FancyPants code was written matching that old version of Pants. You install only Ugly Pants, things do work - because the UglyPants code was written matching the new version of Pants. Things goes kaput only when you install both - Fancy Pants will still work, but Ugly Pants will suddenly borks because it needs something that exists only on Pants 1.0 and it's absent from 0.5 (that was already loaded, and then shadowed everything "loaded" later) . However, since it's UglyPants the one borking, you can think it is the problem. We will just diagnose the source of this problem by installing both, then each one of them separately, and comparing the results. 3 installs. But this example is too much simplistic. When we have 40, 50 Add'Ons installed, we would need to do a Combinatorial Analysis of every possibility in order to mechanically determine the problem (and, again, assuming this is the problem - it may be something else....). This is why is less worst to analise multiple KSP.log and Player.log, observing what is installed and when the thing blows up. There's a chance that the last module logged could hint about the problem, as I did about the music file on that last report of yours.

Yep. An old MiniAVC, bugged, was being used besides newer, fixed ones, being present on the system. Since there's no more a way to select the good from the bad apples, we need to get rid of thr whole basket. From my (many,many) tests, this is unrelated to Unity itself. Now or then something really old borks on Unity by doing wrong things that Unity was tolerating in the past, but nowadays is not anymore. But most of the time it was code that used to work in the past, but stop working due some change in KSP itself. Then a new version was released, fixed and works with new KSP versions - but then suddenly a old copy of that code appears from nowhere, and then everybody starts to used it without being aware (as the Reflection system "lies" to us telling us that the code was read from a the right DLL, but it was not). To make things more complicated, a lot of Assemblies in the past (including KSP ones) were used to be released without a proper Version number, so the only way to be sure about the Assembly would be to inspect the DLL pathname it was loaded, but since we are being lied about it, this door is now shut for us. It's my current thesis, at least. And it should be something pretty specific to Windows, as at least MacOS is not being affected - apparently. It's the reason I don't believe it's something related to a bugged old code, but to a old code that uses something that now is broken somewhere pretty deep on KSP or Unity. I'm a long time KSP abuser and I also use some pretty old AddOns without problems on MacOS, as well new Add'Ons in KSP as old as 1.2.2. And I never was caught by this one. And, dude, believe me: I push my luck. This is why we need the most recent KSP.log and Player.log always. By comparing the new ones with the previous ones we can try to detect if a difference between them can help on the diagnosis. Or the other way around, it can be a small and apparently harmless thing present on them. We just don't know until we find something interesting. It how I started, I was trying to make a Space Shuttle to take of using Whiplahses as booosters when I was caught by the Zero Mass problem. welcome aboard. We have coffee. Sure thing. KSP Recall was born exactly this way!

Modus Operandi. On CSharp, DLLs are only containers. A facy ZIP file for Assemblies. The Assembly would be a file on that ZIP, and its contents are the code you wanna run. That Assembly is what really matters on C#, and they are a collection of procedures and functions packed in things called Classes. When you have many copies of a DLL, KSP tries to retrieve each one of the Assemblies inside them - but since these Assemblies have the same name, you have a name colision. On KSP 1.7.3 and previous, all the Assemblies were being loaded on a "Pool", and you could select one of them by Version or even by the filename it was loaded from, so the colision could be mitigated: you could inspect the Pool and get rid of things you don't want there, as old versions of Module Manager. Now, the first Assembly loaded always "wins" on a colision, so there's no way to try to select what you really want to run. So, if you install a Mod with an old copy of an Assembly (even using a differently named DLL), and this thing is loaded before the others, you will have a outdated code being run by newer code besides the newer code being installed together the correct Assembly for it. This is what killed MM's "election" and played havoc on some TS users. In the past, and even nowadays, most Add'Ons were released with depencies included, to make things easier for people installing things by hand, but this also means that as time goes by, that embedded dependencies became outdated. And then people ended up installing old copies of things on a KSP instalment where the newer copies that were there are silently phased out. MiniAVC is another victim of this problem. You install an Add'On with an older version of it (bugged on KSP 1.9), and suddenly all the other copies of the system are phased out, and things that were fine stops working everywhere.

I'm still playing on KSP 1.7.3, sir. For this exact reason. Too much bugs, too much annoying changes on the physics engine - I just didn't managed to update my savegames to KSP 1.8 or 1.9, some of the crafts just don't work anymore. From ships with hidrofails taking of at Mach 2 to hidroplans that lose all drag after splashing down, I came to terms that KSP 1.10 (as 1.8 and 1.9 I'm just jumping over) will be used only for new savegames, when my current ones are finished. But I expect KSP2 will be on the wild by this time! Some changes on the KSP guts are also hurting (be absolutely sure to have only one DLL for each Assembly, Module Manager caused me some sadness on TweakScale). Humm... Check if you have any duplicated DLLs on your system. The current M.O. on KSP >= 1.8 is to load the new DLL, add it to the Assembly pool pinpointing to the first one loaded, and then discard (or ignore) the code. Perhaps this could be triggered by something similar.

The interesting thing about it is that on MacOS I do not get any of these problems, and some os my test beds are so terribly overloaded that they takes 20 minutes or more to load. We may be facing some problems from Unity 2019, pretty probable on the Garbage Collector. [WRN 16:25:46.084] Internal: JobTempAlloc has allocations that are more than 4 frames old - this is not allowed and likely a leak [WRN 16:25:46.084] To Debug, enable the define: TLA_DEBUG_STACK_LEAK in ThreadsafeLinearAllocator.cpp. This will output the callstacks of the leaked allocations These lines suggests me that we are not facing a problem with some Add'On, but some bug on the CPP code of KSP itself. The fact that on MacOS I just don't get any of these problems (besides sometimes using more and less the same add'ons you do) appears to corroborate my thesis - something bad on the C# code would blow up in both systems. (I presume this thread is a follow up from this one, right?)

The factory of the future will have only two employees, a man and a dog. The man will be there to feed the dog. The dog will be there to keep the man from touching the equipment. Warren Bennis

That's your perception of the KPS's value. I know people that spends thousands of USD on Apple products, but "don't waste" money on games (Forum rules prevent me to explain how they get their games). Go figure it out... You must be new around here.

Thx! It's easier than you think. That harsh part is to get in touch with all the info you need to accomplish the task. On this case, I think that the the first step is to understand what happens when a part explodes. KSP fires up an event to communicate the modules about the exploding part, so knowing when it happens is easy. The next step would be to figure out how the Force Vector being injected on the surviving craft is calculated. This could be something like that Zero Mass problem I detected two years ago (man, time runs fast!), perhaps some value is going underflown or overflow, and this could be injecting a NaN or a INF on the code that calculates the angular acceleration on the part. On this case, merely mangling that Vector would work around the problem (like I did on KSP Recall).

Changes!

I also have a report on TweakScale thread that removing all Module Managers DLLs except the one you really want to use can be a solution. The code on MM that used to prevent old copies of MM to work is not working since KSP 1.8, and apparently is even failing to detect really old ones. -- post edit -- Whoops! The report is from @MajorTom74 himself!

You mean this one? Yep, sounds like some scaling is going to be supported - by the DLC at least. This could be an explanation for the recent changes introduced on the Editor and that triggered the development of KSP Recall. (Looking into the past, Infernal Robotics came to my mind.) We will have to wait and see, but that Resources and Radial Attachments overwrite that started to happens on KSP 1.9.x (and stomped the toes of almost everybody, not only TweakScale) hints me that this can be somewhat problematic on the wild - but that's something that could be handled by KSP Recall, hopefully.

What happened because you are not in Brazil, where pricing is different - what, look, ends up corroborating my argument: Warcraft Bundle is more expensive (with discount) here than KSP at full fee. See spoiler for details. What's just another way of saying "Perception of Value".

Interesting. Here at Brazil its being sold as R$ 72,69 (with 15% off), that it's almost the full price of KSP. It's absolutely the other way around - it's, indeed, about Perception of Value. This game appears to worth way more on Brazil than on USA!

You could not be more wrong, sir. Age is meaningless - just check the huge amount of money being spend on old games (and video games consoles). Warcraft I & II Bundle with the current discount costs exactly the same as KSP at full price on GoG (at least, for me) - and let me tell you, the only reason I didn't bought it is because I still have my originals from the golden times. The magic words are "Perception of Value", not age. One can consider that perhaps GoG is a failing business model. It's a good argument, it could be true. However, the stock price of CD Projekt (the parent organisation) appears to be doing pretty well (besides some falls now and then), so if they are failing, they are not there yet. By the sake of comparison, the T2I stock price is way more stable on the timeline, besides sharing some dropouts more or less at the same time (suggesting external events equality affecting them), offering a more consistent value growth (forget the numbers, look the curve's slopes - one is being traded on Europe, other in USA). This hints me that the GoG business model is a bit less stable than T2I's one. But, at least for while, way from failing. On a wild guess, I think that KSP1 will always have a roof over its head on GoG for the years to come - but not at the currently asked fee.