Lisias

There's an "o" (OH) in the place of an "0" (zero). And an extra "," (coma) at the and of the line scaleFactors = 0.1, 0.3,0.625,o.9375,1.25,1.5,1.875, 2.5,3.125,3.75, 5.0, And, yeah. Patching is picky this way. You can't do any error, or the thing borks. (and, yeah, the savegames....) -- post edit -- And I totally missed that :FOR mishap, I just didn't saw it besides seeing it. Thanks for the heads up, @Tonka Crash!

You are moving fast! The easiest way is to brute force your way on it, as it was made on Making History: @PART[LiquidEngineKE-1]:FOR[TweakScale] // Kerbodyne KE-1 'Mastodon' Liquid Fuel Engine { #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = stack defaultScale = 2.5 scaleFactors = 0.1, 0.3, 0.625, 1.25, 1.875, 2.5, 3.75, 5.0, 7.5, 10, 20 incrementSlide = 0.01, 0.025, 0.025, 0.025, 0.025, 0.05, 0.05, 0.1, 0.1, 0.2 } } The scaleFactors and incrementSlide are the keys here. A Scale Factor is a "default" scale slot, so you can "fast scale" the part using only one click. The Increment Slide is how much to the scale is added by fine tunning the scaling by clicking on the control between two "scale slots". We use the part's name between brackets, not the part's tittle. So trying to use the localised name from the part will just make MM ignore the patch, as it will not find the part. The Houston is happening because you are double patching it. There's something else patching the same part, check the KSP.log for every line mentioning "Applying patch" and "tantares_adapter_s0p5_s0_1". It's something else. You must think on the feature to be scaled on that part. For example, Solar Panels uses free_square (or stack_square, if you have a "tank" those walls are the solar panels) because the light is caught using... panels, and panels are 2D surfaces. If I have a Solar Panels with 2 x 2 m = 4m², by scaling to be the double of the size we would have 4x4 = 16 m² , and so it would catch 4 times the "amount of light" the original part does. A fuel tank, however, is scaled by volume. A tank with 2x2x2 = 8m³ being doubled will render 4x4x4 = 64m³ or 8 times the original amount of fuel capacity. It's purely semantics - you can use stack_square for a tank and free for a solar panel, but doing so will make your part scaling in a completely unrealistic way. There's no automated rule for it, you need to think on the problem the part solves to decide what to use (see my rationale about the Valve above). Yep, because the first patch was not working. The only patch working is the second, but it's stomping someone else's toes.

(thanks, @Gargamel! I missed this post!) Hi, Well, I'm happy that you figured it out. Being KIS, you probably forgot to delete TweakScale before updating - some files had changed or moved, and by just unzipping the new Release over the old one, some old files were left lingering on the system. I gave a peek on the new file, but it still have only part of the KSP.log - I could not use it to diagnose your problem if you already didn't did it. To better explain why it's important to send me the full KSP.log, let's see one "support ticket" I did in the past, when something similar happened: [LOG 13:17:46.227] Applying update TweakScale/patches/NF/NFS_TweakScale/@PART[solarpanel-blanket-1] to NearFutureSolar/Parts/Deprecated/solarpanel-blanket/solarpanel-blanket-1.cfg/PART[solarpanel-blanket-1] ... [LOG 13:18:06.053] Applying update TweakScale/Deprecating/patches/NF/NFS_TweakScale/@PART[solarpanel-blanket-1]:FOR[TweakScale] to NearFutureSolar/Parts/Deprecated/solarpanel-blanket/solarpanel-blanket-1.cfg/PART[solarpanel-blanket-1] (from a previous ticket) The part you pasted on the document tells me only what happened, but I need the rest of the log in order to understand why it happened. On the fragment above, we see a part being patched twice, one time by TweakScale/patches/NF/NFS_TweakScale and another one by TweakScale/Deprecating/patches/NF/NFS_TweakScale . Worse, the second patch had the ":FOR" thingy, something that only TweakScale 2.5 are using - the aftermath was that I mistakenly didn't cleaned up the the distribution folder when I switched branches while creating a release, and ended up distributing that file by accident. (yeah, I borked on that one!) And so I could diagnose the problem. Without the full KSP.log I would need to make a lot of guessing, asking the user to do a lot of tests to see what happens, and so I would end up taking way more time to figure out the problem (not to mention eroding the user's patience!), while by just looking the KSP.log I could detect the problem on the spot - and since this time it was something that should not had happened from my side, instead of something that usually happens on the user's side, that one would take a lot of exchanges until the diagnosis! (and it's the reason I choose this one for example!). Cheers!

NF currently has only the NFS published (the others are Work in Progress, almost done!), so perhaps you should wait a bit before using it as reference. Lots of new thingies being added - however, on NF patches I have the concerning of keeping backwards compatibility, so if I find something I would do differently, I just keep using it as is to avoid breaking ongoing savegames. I think that TweakScale "stock" Squad and SquadExpansion would be a better reference, specially for the new parts from Expansions. These ones guided the others in the past, at least. If you want to be on the bleeding edge, keep an eye on the KAS, KIS and Firespiter Companions. These are the ones where really new tricks are being implemented (besides respecting the legacy parts). For the stock resources and modules, yes. There're a lot of predefined ScaleExponents so you have the perception that things scales automatically - but they don't, they are scaled "transparently". Pods. I was hoping nobody would ask. Pods behave (mostly) like fuel tanks - think on the Crew as they were a "Resource" like fuel or as a kind of Cargo - but with individualised names per resource. BUT... There's code on KSP that doesn't allows scaling up Crew capacity, but you at least can scale the Pod down. This hurts a bit the feature, but whatever - it's how KSP was coded and trying to overcome it (using Harmony, for example) may create problems that I don't think the Stock TweakScale should handle (but an optional Companion will work on this later). In a nut shell, as long you don't mind being not able to scale up the Crew, handle them as an Stack Attached Part scaling volume.SURFACE. But, at least, KSP still allow us to scale it down...

I also understood. But, you know, my mind works in strange ways! Exactly. It was while reading what you wrote that I started to reconsider if my answer was really good enough to help the guy: "I'm telling him what he needs in order to accomplish this task, or I'm just answering mechanically that question?" Then I realised that I was just answering mechanically that question. (my mind, really, works in strange ways! really!)

I understood. But it was your comment that hinted me that I didn't propperly answered the guy! -- -- post edit -- -- Me too, by the way. But I didn't changed it because I would break savegames on the wild. With the Companion Program, however, we can have some degree of freedom to "reinvent the wheel" (pun not intended - kind of), as we can check for the presence of a hypothetical "TweakScale Companion Alternate Wheels Scaling" and block the loading of the savegame if it uses it! (yeah, future feature for TweakScale 2.5)

What hinted me that I didn't proper answered that question!! (obfuscated a phrase that should probably be omitted) Let's try again! What follows is something that should be on that page I suggested above, but I ended up choosing to first finish my "TweakScale Companion Program" series and add to it the lessons learnt from the Program (and believe me, there're a lot!). But doesn't hurts to upfront some hints. There're basically two main "receipts" for a TweakScale patch: for a surface attached part, and for a stack attached part (there are some weirdos on the basket, but let's start with the basics). Surface attached parts usually have the format: @PART[name-of-the-part]:NEEDS[TweakScale]:FOR[MyFancyAddon] // Here I usually put the Title of the part to make things easier when I have to update things { %MODULE[TweakScale] { type = free_square } } This is the free scaling (the % mentioned by Azic). You can freely scale down to ~3% (too small and things got rounded to zero on the physics engine, and Krakens feed on zeros inside the physics engine) to 400% (similar things happens above 400% - or at least, it used to happens in the past). Solar Panels, Radiators, Airbreakes parts are things in what you will, usually, apply this Receipt. When you scale Solar Panels, for example, the free type scales badly - while Radial Tanks should be scaled using a Cubic exponent (as you scale it on X, Y and Z and so , you change the total volume of the part), Solar Panels are thingies that you need to use a quadratic exponent, as the thing you want it to scale (the area used to catch light) has only two dimensions. In these situations, we use free_square as the type of the scaling. Wings also are something to use quadratic scaling (as we are scaling lifting surfaces, and a surface is an area!). So: you want to scale something in 3 dimensions (volume), you use free. you want to scale something in 2 dimensions (area), you use free_square. The other most common Receipt for scaling is for parts with stack attachment points. This one is a bit more tricky: @PART[name-of-the-part]:NEEDS[TweakScale]:FOR[MyFancyAddon] // Here I usually put the Title of the part to make things easier when I have to update things { %MODULE[TweakScale] { type = stack defaultScale = 2.5 // or any other number, see text } } Stack parts on KSP have well defined diameters. Some parts are 1.25M wide, others 2.5M, etc. (At the end of this article I will list them for you.) So, we need to tell TweakScale the default (stock) size of the part, so TweakScale can infer how much it will scale something related to the well known "bulkhead sizes" on KSP. And I'm talking about bulkhead because, nowadays (and thanks God!), most parts have an information called bulkheadProfile that will tell us the profile of the part, making easier our job of defining the defaultScale for it. I need to tell you that it's pretty important to set this value right at first try, because once people starts to use that part, changing the defaultScale will distort all the crafts scaling it (as, as I said, the defaultScale is used to calculate how much TweakScale needs to scale something up or down to reach the next bulkheadProfile). This is my work in progress table of known bulkheadProfiles (incomplete, I'm still working on that tutorial): size0 = 0.625 size1 = 1.25 size1p5 = 1.875 size2 = 2.5 mk1 = 1.25 mk2 = 2.5 mk3 = 3.75 So, in a nutshell, if you find a size0 on the bulkheadProfile of that part, you shove a 0.625 on the defaultScale, and so on. If you find srf on the buldheadProfile, it's a hint that you should use the first Receipt above. Sometimes, a part have more than one profile, as the Adapters. When this happens, pick the greater one - it's a convention used by TweakScale patches, always use the bigger number as the defaultScale . Some few parts can be also attached radially (some fuel tanks, for example). These parts will have srf together other names. When this happens, use the largest one. Only use the "free Receipt" when there's only srf on the bulkheadProfile. Some examples from TweakScale stock patches for Squad, using the format: an excerpt of the original PART config followed by the TweakScale patch for the part: PART { name = HeatShield0 module = Part author = RoverDude yada yada yadaa bulkheadProfiles = size0 } this parts is scaled as follows: @PART[HeatShield0]:FOR[TweakScale] // Heat Shield (0.625m) { %MODULE[TweakScale] { type = stack_square defaultScale = 0.625 } } See the bulkhead profile? Since it's a size0, we need to use the second Receipt. And since when we scale a HeatShield we are scaling the amount of heat the shield can take (a surface), we use the free_square. PART { name = fuelTankSmallFlat module = Part author = RoverDude yada yada yada bulkheadProfiles = size1, srf } @PART[fuelTankSmallFlat]:FOR[TweakScale] // FL-T100 Fuel Tank KSP >= 1.5 { %MODULE[TweakScale] { type = stack defaultScale = 1.25 } } This one is more interesting. See the bulkheadProfile ? It have srf and size1. So using the TweakScale convention of using the bigger profile (let's think of srf as zero), the defaultScale for it is 1.25. Since we are scaling a tank, those volume should be scale, the stack type is used (cubic). PART { name = adapterMk3-Mk2 module = Part author = Porkjet yada yada yada bulkheadProfiles = mk2, mk3, srf } @PART[adapterMk3-Mk2]:FOR[TweakScale] { %MODULE[TweakScale] { type = stack defaultScale = 3.75 } } This is the mk2 to mk3 fuel tank adapter. It's like the previous example, we just take the bigger profile, mk3 (3.75 on the defaultScale). Now, let's see a free typed Receipt: PART { name = ReleaseValve module = Part author = Squad yada yada yada bulkheadProfiles = srf } @PART[ReleaseValve]:FOR[TweakScale] // FTE-1 Drain Valve for KSP >= 1.9 { %MODULE[TweakScale] { type = free } } This one was tricky to define. Doing some research on hidraulics, I learnt that the capacity of the resource to be drained scales more alike cubicly, not quadratically - besides both options would be wrong on real life (it depends more on the pressure of the contained resource than only the size of the valve alone). So I took the "less wrong" approach. I think... These receipts will cover most parts on an Add'On. By using some clever receipts (called ScaleExponents inside TweakScale), most parts will have the Resources and Modules correctly scaled. But there are some Exceptions. Engines and decouplers the most notorious ones: @PART[LaunchEscapeSystem]:FOR[TweakScale] // Launch Escape System { #@TWEAKSCALEBEHAVIOR[SRB]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = stack defaultScale = 1.25 } } @PART[Decoupler_0]:FOR[TweakScale] { #@TWEAKSCALEBEHAVIOR[Decoupler]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = free } } The previous rules still applies, but you need to add that TWEAKSCALEBEHAVIOUR thingy to the patch when handling parts using stock engine modules, and stock decoupler modules. This is an instruction hinting TweakScale that this part is "uncommon", and it should use some extra instructions embedded on the "behaviour". For the sake of Curiosity, Firespitter modules demanded special behavirours . Custom ScaleExponents and Behaviours are something way more tricky than all of that, so let's left this for a next Opportunity. Feel free to ask for help every time you need! Cheers!

And it doesn't even need to be the complete game. A pretty reduced set of features, as the Demo used to have - a planet, a launch base, an airstrip, a moon and an asteroid. With that, I think that 80 to 90% of the Add'Ons would be able to start the works on the migration. This technical demo release doesn't need even to be static, can be something released once a month - so any breaking changes would be detected early. Break early, break often - breakage is not bad. Unexpected breakage is.

Duck typing. "If it walks as a sociopath, and talks as a sociopath, it should be a sociopath". An association of people cannot be more trustworthy than the least trustworthy of them - essentially, it's why good managers don't work for bad managers (as said by @K^2 above). A manager can replace untrustworthy people below him/her on the hierarchy, but can do little to who is above him/her - usually the price the guy/gal pays doesn't worths the wage. (been there, done that - never more). So, when dealing with Companies, it's wiser to handle them as they were, indeed, sociopaths - besides the people you are dealing are probably not. Such guys will eventually leave the company, and God knows who will be put in their places.

Yes. There's the canonical reference: https://github.com/sarbian/ModuleManager/wiki And there's my personal advices (TweakScale biased) here: http://ksp.lisias.net/blogs/tech-support/TweakScale/How-to-write-a-patch The problem is that the code that was electing the newest one broke last year with KSP 1.8, and nobody cared to fix or workaround the problem (assuming someone was even aware of it). Something on KSP or C#'s runtime decided to lie to us, faking loading any duplicated Assemblies while pinpoint it to the first one loaded instead - and this obliterated the solution. Weirdly, nobody cared to code a workaround - Module Manager already complains about a ancient Firespitter version, it would cost pretty little to deactivate the election code and issue a message box on KSP >= 1.8 when multiple Module Managers are loaded. It will waste a bit of memory and CPU, but the really bad problem is that sometimes it fails in a way that induces something else to fail (an idiosyncrasy on KSP internal guts, long story). Welcome!

You got a pretty good point here. Playing the Devil's advocate, I want to remember that Companies are essentially sociopaths: any one that would try by itself any if the dirty tricks a Company usually does, and this poor stand-up guy will face a hell of a backslash from friends to family. Do you would invite a relative to dinner with your kids if the guy is a drug dealer? Being all companies essential sociopaths entities, I'm starting to think this leakage to the press is part of a hidden agenda....

Fortunately, TweakScale has long Canadarms nowadays. I want to inform Wyvern's users that a TweakScale Companion was added today supporting this fine Add'On (both classic, on KSP 1.2 and 1.3, as the newer one on KSP >= 1.4). Download on TweakScale Companion Program Thead. @Tonka Crash, would you like to test drive it?

Announce Pre Release 0.0.1.0 for the new TweakScale Companion Multipass BETA are on the wild. Download on the OP or in https://github.com/net-lisias-ksp/TweakScaleCompanion_Multipass/releases/tag/RELEASES%2F0.0.1.0 . This Companion will support that myriad of small Add'Ons that would make too much of a hassle to support individually. Currently, supporting Arc Aerospace's Wyvern. The patches provided works for KSP 1.2.2 to the 1.9.1, by the way, with support for both the classic release from @zlsa to a new one adapted to modern KSP. TweakScale 2.4.4.0 will be the minimum supported release, and it's working fine on the TweakScale 2.5.0.x Beta, but you can try on TweakScale 2.4.3.x - no guarantees, however: i didn't tested it on 2.4.3. And use S.A.V.E. just in case. This thingy is Beta!

And now, for something completely different ™ : Now, pretending I'm ontopic... At the price they are asking, EA would harm them. Even KSP1 is having a bad time collecting the full fee, Steam Charts tell me that KSP1 user base grows only when the pack in on 50% promotion on GoG or Steam, hinting that the user's perception of value is 10 or 20 bucks maximum for KSP1 . I think T2 will play a slightly different game on KSP2.

No. It's always a Management problem. They agreed on a impossible deadline, or hired people unable to accomplish the task. In a way or another, it's ALWAYS a Management problem.

Yeah, I reproduced it. I borked something on KSPe, I'm updating the Tool and will advise ASAP. In the mean time, please note that the OP's official release also works fine with MM/L 4.1.3.1 - my fork have some niceties, but the OP's one still works! -- POST - EDIT -- @The Space Man, it's updated. 2.6.0.7 is on the wild.

As long you don't save back what you loaded, no harm is done - HOWEVER, this also applies to living crafts on the savegame. So, in a nutshell, craft files are ok. Just don't save after loading, they will "survive". But anything flying around became broken, and since KSP automatically save the game on quitting, without backups they are doomed. You can try to avoid it by hastily killing the KSP process using Task Manager - but now and them, this fails. It's the reason I push S.A.V.E. to everybody. I must say this is not inherent to TweakScale, but to KSP itself. Anything borks a module, it became kaput and so any data from it is discarded by KSP on loading things. And then the artefacts are saved back without that data, and the aftermath is what you just saw on your rig. Fixing small craft files is not that hard. just resize the part - but complex crafts and living crafts on the Universe, unfortunately, it's not feasible (besides theoretically possible). Sorry!

Got it. I hope you made backups of the savegames... [LOG 15:44:52.599] [TweakScale] INFO: WriteDryCost Concluded : 1481 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 3 Show Stoppers found; 9 Sanity Check failed; 682 unscalable parts. And the FATALities are: [LOG 15:44:52.395] [TweakScale] ERROR: **FATAL** Part KIS.Container1 (SC-62 Portable Container) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 15:44:52.395] [TweakScale] ERROR: **FATAL** Part KIS.Container2 (ILC-18k Container) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 15:44:52.395] [TweakScale] ERROR: **FATAL** Part KIS.Container3 (ISC-6K Container) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 Humm... Interesting. I recently released a Alpha for KIS on the TweakScale Companion Program. And, yeah, they are kinda of related. When you updated TweakScale, you forget to delete the older version. Things will change a lot on TweakScale in the next few months while I pave the way for TweakScale 2.5, and some files will be removed or moved. So you need to remove the old TweakScale folder before applying the update. [LOG 15:42:29.335] Config(@PART[KIS_Container1]) TweakScale/Deprecating/patches/KIS_TweakScale/@PART[KIS_Container1] [LOG 15:42:29.344] Config(@PART[KIS_Container1]) TweakScale/patches/KIS_TweakScale/@PART[KIS_Container1] Completely delete GameData/TweakScale then install it again and you will be fine. Cheers!

There're no patches on the Add'On, neither on TweakScale's "stock" patches. But you can ask for it on the TweakScale Companion Program thread. It will probably took some time due Real Life™ issues, but it will be eventually done.

I AM AN IDIOT!!! You had a double patched part because you have TWO COPIES of the patch on your instalment! [LOG 14:14:30.639] Load(Texture): Parts/Engines/AluminiumEngine/LiquidMetalInjectionEngine [LOG 14:16:13.347] Load(Texture): WarpPlugin/Parts/Engines/AluminiumEngine/LiquidMetalInjectionEngine MM is fine (at least, as much fine as it uses to be). WarpPlugin is fine. My patch is fine. I just was tired yesterday night, got focused on the bug I found on MM and didn't paid enough attention to simpler alternatives. Delete GameData/Parts from your game and things will be fine! What happened on your instalment follows: The parts affected has the following structure: PART { name = foobar yada yada yada } @PART[foobar]:FOR[WarpPlugin] { %MODULE[TweakScale]:NEEDS[TweakScale] { yada yada yada } } This was made this way so TweakScale would not be injected on the part when TweakScale is not installed, as well to order the patching on the new PASS patching mechanism from Module Manager. Since TweakScale 2.5 will be pulled out of the LEGACY patching, doing this way will help TweakScale to prevent double patching (that it was what was happening on a game installation of mine where I test drive TweakScale 2.5), as well any mishap would be easily detected (as it did, indeed). On your GameData, by some accident you ended up with two copies of the WarpPlugin/Parts - one on the right place, other on the root of the GameData (a pretty wrong place). So we ended up with two copies of the PART, but also with two copies of the Patch itself. So the patch was (correctly) ran two times, each time patching two parts - because Module Manager, when it finds two nodes with the same name, patch both (what's correct, Module Manager knows squat about PARTs, it only understands Nodes!). By a incredible lack of luck (of my part), this week I already had problems with some patches I applied on a PR to WarpPlugin (MM has, indeed, some idiosyncrasies that now and then bites me in the SAS - but this was not one of them!), so I jumped into the conclusion that I had, somehow, borked again (what I do now and then, but this one is not one of them). And how I, finally, detected the problem? Easy. I took some sleep and came back to the problem with a fresh mind, started to review what I already said to you and then the True hit me with the finesse of a piano falling from the 20th story. Oh, well. Case close. Cheers! -- -- -- A SERIE OF USELESS CRAP -- -- -- I ruled out WarpPlugin when I run it using my Experimental fork on my MacMini (not sure what of the options was the "fix") and it worked fine. As it worked fine when I issued the Pull Request on Warp Plugin to fix a double patching that would happen when TweakScale V 2.5.0.x will go gold, when it wold be pulled out from the LEGACY patching. TweakScale 2.5 is something that it's being worked out for a whole year already, and you can bet your SAS it's being rigorously tested (and not just by me, there're crazy brave Kerbonauts helping me on the matter - so it's not only "working on my machine"). In a way or another, there's only one thing applying patches on your rig, and this thing is Module Manager - so, until further information is gathered (check your private messages, I need your help on this) - and until further evidences are found, I think we found (another) bug on Module Manager. So right now, and except a handful of Add'Ons I didn't bored to download and install as I think I caught the problem, what follows are the only differences between my KSP 1.8.1test bed and yours: I'm running on MacOS, you are running on Windows 10 I'm using my personal Experimental fork for MM, you was running "stock" 3.1.1 and later 4.1.3 Initially I was thinking that perhaps one old copy of Module Manager would be running unattended in parallel, but quickly I realise I was wrong - the double patching would be happening everywhere, not only sometimes. [The text on the spoiler below was wrong - I was wrong, this was a good patching!] In a way or another, shove this patch into your GameData for while. It will force brute its way into a sane GameDatabase so you at least can play without TweakScale yelling on you: You will need to delete this stunt when (or if) we find a proper fix, so please remember where you put it (it's the reason I recommend using that __LOCAL thingy). (and check your private message)

I made some testings shoving every single DLL from MM I have on the same GameData. This is what I found: ModuleManager.2.7.6 v2.7.6.0 ModuleManager v3.0.4.0 ModuleManager v3.0.4.0 ModuleManager v3.0.4.0 ModuleManager v3.0.4.0 ModuleManager v3.0.4.0 ModuleManager v3.0.4.0 [LOG 20:54:53.735] [AddonLoader]: Instantiating addon 'ModuleManager' from assembly 'ModuleManager' [EXC 20:54:53.753] MissingMethodException: PopupDialog PopupDialog.SpawnPopupDialog(UnityEngine.Vector2,UnityEngine.Vector2,string,string,string,bool,UISkinDef,bool,string) ModuleManager.ModuleManager.Awake () (at <e40c6d8935f74be49802d520dee420c7>:0) UnityEngine.GameObject:AddComponent(Type) AddonLoader:StartAddon(LoadedAssembly, Type, KSPAddon, Startup) AddonLoader:StartAddons(Startup) <LoadObjects>d__89:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) <CreateDatabase>d__70:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) GameDatabase:StartLoad() <LoadSystems>d__11:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) LoadingScreen:Start() [LOG 20:54:53.754] [AddonLoader]: Instantiating addon 'ModuleManager' from assembly 'ModuleManager' [LOG 20:54:53.777] [ModuleManager] version 3.0.4.0 at /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.3.0.4.dll won the election against Version 3.0.4.0 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.3.1.1.dll Version 3.0.4.0 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.4.0.2.dll Version 3.0.4.0 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.4.0.3.dll Version 3.0.4.0 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.4.1.3.dll Version 3.0.4.0 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.dll Module Manager 2.7.6 is correctly detecting its version, but it's borking trying to call PopupDialog.SpawnPopupDialog that doesn't exists on the current KSP Version. So MM 3.0.4 is the next candidate, and by some weird reason, every single one of the others are also being tagged as 3.0.4.0 !!! So I decided to rename my fork's DLL to ModuleManager.1.0.0.dll to force it to be scanned first (and removed 2.7.6). And that's it: [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 Only the first Module Manager found wins the Election, no matter what. So I decided to pursue this problem, and compiled different versions of the /L Experimental to see what I get. And this is what I got: [LOG 21:48:52.126] [ModuleManager] INFO: version 3.0.4.0 at /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.3.0.4.dll won the election against Version 3.0.4.0 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.3.1.1.dll Version 3.0.4.0 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.4.0.2.dll Version 3.0.4.0 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.4.0.3.dll Version 3.0.4.0 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.4.1.3.dll Version 3.0.4.0 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.dll What's happening is that only the first Assembly found is loaded into memory, subsequent Assemblies earn an entry on the Reflection tables but pinpoints to the first Assembly loaded always. Interesting. So a light bulb sparked in my head, and I copied all that DLLs into my 1.7.3 testbed, and got this: [LOG 21:55:05.448] [ModuleManager] INFO: version 3.0.4.0 at /.users/lisias/Workspaces/KSP/runtime/1.7.3/GameData/ModuleManager.3.0.4.dll won the election against Version 4.1.3.1 /.users/lisias/Workspaces/KSP/runtime/1.7.3/GameData/ModuleManager.dll 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 Not only the order of the DLLs changed on the listing, and now they are correctly identified. Interesting, because I had changed the election so the LAST assembly on the list wins and with the Assemblies correctly identified (and sorted), the 3.0.4 ended up being elected again. So I fixed the code to elect the First of that list again. And now things came back to work as expected 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 Since my fork works fine downto KSP 1.2.2, I decided to reproduce this test on 1.3.1. And got the exact same behaviour from 1.7.3. So this thing used to work in the past, but stopped working when 1.8.0 arrived changing how Assemblies are handled. In a way or another, this mechanism doesn't works anymore. I altered the code to sort the list only by the pathname, in the hopes that the Version would be a flaw and that the remaining Assemblies would be still on memory. And came to this: [LOG 22:25:46.692] [ModuleManager] INFO: version 3.0.4.0 at /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.3.0.4.dll won the election against Version 3.0.4.0 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.dll Version 3.0.4.0 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.4.1.3.dll Version 3.0.4.0 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.4.0.3.dll Version 3.0.4.0 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.4.0.2.dll Version 3.0.4.0 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.3.1.1.dll But, frankly, I could had detected this sooner if I had paid attention to my own log messages: [LOG 22:25:53.067] [ModuleManager] Version 3.0.4.0 /L Experimental [LOG 22:25:53.067] [ModuleManager] Version 3.0.4.0 /L Experimental [LOG 22:25:53.067] [ModuleManager] Version 3.0.4.0 /L Experimental [LOG 22:25:53.067] [ModuleManager] Version 3.0.4.0 /L Experimental [LOG 22:25:53.067] [ModuleManager] Version 3.0.4.0 /L Experimental [LOG 22:25:53.067] [ModuleManager] Version 3.0.4.0 /L Experimental Since every one of that copies were a propperly compiled DLL (with the Version matching the name, as you can check from the logs from KSP 1.7.3), we have confirmation that only the first Assembly is being loaded with the remaining ones receiving a new entry on the Reflection tables, but pinpointing to the first one loaded. Pretty nasty behaviour, as it is giving us false information. So this settle up the matter. From the next releases, no Add'On of mine will deliver Module Manager anymore. In its place, a utility will check if more than one Module Manager is installed and, if it found more than one, will halt the loading informing the user of the problem. Users of CKAN will not be affected, as CKAN correctly copies only what the NetKAN metadata tells it to copy, and my NetKAN metadata doesn't copy the embedded ModuleManager DLL (it was meant to make the life of manual installers easier, but as we can see, it backfired on me).

I'm still trying to reproduce this problem, I'm downloading every single Add'On mentioned in your KSP.log and installing them to see what I get. Until this moment, I didn't managed to reproduce it - so I'm kinda lost on it yet. Going bag to that double patching I quoted from that post: [LOG 14:18:08.193] [ModuleManager] Applying update Parts/Engines/AluminiumEngine/LiquidMetalInjectionEngine/@PART[AluminiumLiquidMetalEngine]:FOR[WarpPlugin] to Parts/Engines/AluminiumEngine/LiquidMetalInjectionEngine/PART [LOG 14:18:08.223] [ModuleManager] Applying update Parts/Engines/AluminiumEngine/LiquidMetalInjectionEngine/@PART[AluminiumLiquidMetalEngine]:FOR[WarpPlugin] to WarpPlugin/Parts/Engines/AluminiumEngine/LiquidMetalInjectionEngine/PART See, we have the same patch (Parts/Engines/AluminiumEngine/LiquidMetalInjectionEngine/@PART[AluminiumLiquidMetalEngine]) being applied twice on the same node (WarpPlugin/Parts/Engines/AluminiumEngine/LiquidMetalInjectionEngine/PART) on an interval of 30 milliseconds. This is a pattern, and it happened too on the other parts that got a FATALity. Initially, I though it would be a MM doppelgänger running in parallel, it happened once on TweakScale (when the user unadrevtidly placed a copy of the DLL somewhere else and forgot about), by so every patch would be applied twice, not only these parts and not only TweakScale - and, of course, that "Election" stunt my be electing the wrong guy, but it appears to be correctly ruling out the ones that lost the election. I'm really reticent on thinking this is a problem on some Add'On because by the time the problem happens, there's not too much thingies running on the system. These two log entries above are also consecutive, there's nothing between these two lines , as an exception or something. Currently, my only guess is MM itself. I'm using my own Experimental fork on a MacOS - and, by some previous experience supporting some fellow Kerbonauts used to run KSP on multiple environments, I know that there's some significant differences on the Task Switchers involved (TL;DR: Linux and MacOS appears to have more reliable task switchers, while Windows appears to be slightly faster on switching contexts). Since right now the only significative differences between my 1.8.1 test bed and your setup are that I'm running MacOS and my Experimental MM fork, I'm tempted to suggest you use my experimental fork for debugging purposes. In the mean time, I'm writing a brute-force "solution" to keep your game running in the mean time - it's Friday night, by God's sake, you wanna play.

Got it. And, boy, what a marvelous collection of FATALities we have here! Mortal Kombat is childish play near this! [LOG 23:25:45.815] [TweakScale] INFO: WriteDryCost Concluded : 3533 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 1092 Show Stoppers found; 9 Sanity Check failed; 1874 unscalable parts. But such amount of FATALities is, usually, a problem while installing things, see: [LOG 23:13:41.178] [ModuleManager] Applying update B9PartSwitch/CopyEventsPropagator/@PART:FOR[zzzzzz-B9PartSwitch] to Bluedog_DB/Parts/Titan/bluedog_UA1207/PART [LOG 23:13:41.331] [ModuleManager] Applying update B9PartSwitch/CopyEventsPropagator/@PART:FOR[zzzzzz-B9PartSwitch] to Gamedata/Bluedog_DB/Parts/Titan/bluedog_UA1207/PART You have bluedog (and probably others) installed twice on the system. Delete GameData/GameData and you should be fine. In time, I also detected the very same problem from the last post above: [LOG 23:04:38.802] [ModuleManager] version 3.1.1.0 at E:\KSP - KSSRS\GameData\ModuleManager.3.1.1.dll won the election against Version 3.1.1.0 E:\KSP - KSSRS\GameData\Gamedata\ModuleManager.4.1.3.dll Version 3.1.1.0 E:\KSP - KSSRS\GameData\ModuleManager.4.1.0.dll Version 3.1.1.0 E:\KSP - KSSRS\GameData\ModuleManager.4.1.1.dll Version 3.1.1.0 E:\KSP - KSSRS\GameData\ModuleManager.4.1.3.dll As I mentioned above, MODULE MANAGER IS ELECTING THE OLDEST VERSION ON YOUR SYSTEM TO BE USED. This is unbelievable, but it's true, MM is utterly broken. Please delete every ModuleManager from your instalment but the latest one, 4.1.3 . (and these stunts is the reason I decided to ditch this thing and I'm using my own experimental fork). -- POST EDIT -- Additionally, install ZeroAVC. Really, MiniAVC is causing lots of troubles on KSP >= 1.8 and your instalment have some copied on it scattered on the folders.

Got it. [LOG 14:26:03.329] [TweakScale] INFO: WriteDryCost Concluded : 1596 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 5 Show Stoppers found; 0 Sanity Check failed; 386 unscalable parts. And the parts are: [LOG 14:26:03.288] [TweakScale] ERROR: **FATAL** Part AluminiumLiquidMetalEngine (Aluminium Liquid Metal Injection Engine) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 14:26:03.289] [TweakScale] ERROR: **FATAL** Part AluminiumMonopropellantEngine (Aluminium Monopropellant Engine) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 14:26:03.289] [TweakScale] ERROR: **FATAL** Part AluminiumPneumaticEngine (Aluminium Pneumatic Fuel Feed Engine) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 14:26:03.293] [TweakScale] ERROR: **FATAL** Part kspiIHRMOR7HRM (Aluminium Hybrid Rocket Engine) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 14:26:03.294] [TweakScale] ERROR: **FATAL** Part kspiIHRMOR7HRMhalf (Aluminium Hybrid Rocket Engine 3/4) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). And that was interesting.... [LOG 14:18:08.193] [ModuleManager] Applying update Parts/Engines/AluminiumEngine/LiquidMetalInjectionEngine/@PART[AluminiumLiquidMetalEngine]:FOR[WarpPlugin] to Parts/Engines/AluminiumEngine/LiquidMetalInjectionEngine/PART [LOG 14:18:08.223] [ModuleManager] Applying update Parts/Engines/AluminiumEngine/LiquidMetalInjectionEngine/@PART[AluminiumLiquidMetalEngine]:FOR[WarpPlugin] to WarpPlugin/Parts/Engines/AluminiumEngine/LiquidMetalInjectionEngine/PART Every part affected has this Modus Operandi. What makes this thing interesting is that the same patch is being applied twice. What makes it yet more interesting is that I wrote this patch myself and applied a Pull Request recently to KSPIE, to prevent a (future) problem when TweakScale 2.5 will be released (for the tech savvy: TweakScale will be moved out from the LEGACY patching from MM, and this will break some old patches). And I tested this thing, this obvious mistake would not had passed through. But, I just downloaded the most recent release and tried again on my test rig, and I didn't reproduced the issue here. So whatever is happening on your rig, is not something from WarpPlugin neither TweakScale. What's not that good, because I would have a solution for you already if it did. So let's keep digging. Unfortunately, this diagnosis is now a phishing expedition. I'm now looking for weird things in the hope one of the weirdness is the problem - or at least, the trigger for the problem. I did a look on the DLLs loaded on your rig: Mod DLLs found: Stock assembly: Assembly-CSharp v0.0.0.0 Scale_Redist v1.0.0.0 / v2.4.3.10 ModuleManager v3.1.1.0 ModuleManager v3.1.1.0 ModuleManager v3.1.1.0 ModuleManager v3.1.1.0 MiniAVC v1.4.0.2 FilterExtensions v3.2.4.0 / v1.0.0.0 USITools v1.0.0.0 B9AnimationModules v1.6.0.0 / vv1.6.0 B9PartSwitch v2.12.1.0 / vv2.12.1 InstallChecker v1.0.0.0 CCK v5.0.0.0 / v4.1.0.0 for KSP 1.6.0 DecouplerShroud v1.0.0.0 DistantObject v1.9.1.29406 Atmosphere v1.8.0.2 CelestialShadows v1.8.0.2 CityLights v1.8.0.2 EVEManager v1.8.0.2 PartFX v1.8.0.2 PQSManager v1.8.0.2 ShaderLoader v1.8.0.2 Terrain v1.8.0.2 TextureConfig v1.8.0.2 Utils v1.8.0.2 _BuildManager v1.8.0.2 Launchpad v6.7.2.0 / v6.7.2 Firespitter v7.3.7240.11089 MiniAVC v1.4.0.2 MiniAVC v1.4.0.2 KEX-Common v1.0.0.0 Kopernicus.Parser v1.0.0.0 ModularFlightIntegrator v1.0.0.0 / v1.2.7.0 Kopernicus v1.0.0.0 KEX-EmissiveFX v1.0.0.0 InterstellarFuelSwitch v3.13.3.5 MiniAVC v1.4.0.2 RasterPropMonitor v0.31.2.39964 KAS-API-v2 v2.0.7239.35367 / vKAS API v2 KAS v1.5.7239.36651 / v1.5 for KSP 1.8+ KSPDev_Utils.2.0 v2.0.7231.38433 / v2.0 for KSP v1.8+ MiniAVC v1.4.0.2 DeployableAeroSurfaces v1.0.0.0 KIS v1.24.7279.41031 / v1.24 for KSP 1.8+ KSPDev_Utils.2.1 v2.1.7279.39857 / v2.1 for KSP v1.8+ MiniAVC v1.4.0.2 MiniAVC v1.4.0.2 NFPropUtils v1.0.0.0 Interstellar_Redist v1.3.0.0 MiniAVC v1.4.0.2 PhotonSail v1.4.11.5 Scale_Redist v1.0.0.0 / v2.4.3.10 BackgroundResources v1.8.0.0 MiniAVC v1.4.0.2 DeepFreeze v0.27.0.0 Restock v0.1.0.0 scatterer v0.0.0.0 MiniAVC v1.4.0.2 SmokeScreen v2.8.9.0 Stock assembly: KSPSteamCtrlr v0.0.1.35 MiniAVC v1.4.0.2 MiniAVC v1.4.0.2 TarsierSpaceTech v7.9.0.0 TrajectoriesBootstrap v1.0.0.0 KerbalAlarmClock v3.12.0.0 KSPe.Light.TweakScale v2.1.0.17 Scale v2.4.3.10 Konstruction v0.0.0.0 USILifeSupport v1.0.0.0 KolonyTools v1.0.0.0 Interstellar v1.25.10.5 Interstellar_Redist v1.3.0.0 MiniAVC v1.4.0.2 Install ZeroAVC. Really, MiniAVC is causing lots of troubles on KSP >= 1.8 I also found something wrong on Kopernicus: [LOG 14:13:43.112] [AddonLoader]: Instantiating addon 'ShaderInit' from assembly 'KopernicusExpansion.EmissiveFX' [LOG 14:13:43.114] [Kopernicus] ShaderLoader: Loading asset bundle at path C:/Program Files (x86)/Steam/steamapps/common/Kerbal Space Program/KSP_x64_Data/../GameData/Ko pernicusExpansion/Shaders\emissivefx-windows.unity3d [ERR 14:13:43.173] Unable to open archive file: C:/Program Files (x86)/Steam/steamapps/common/Kerbal Space Program/KSP_x64_Data/../GameData/KopernicusExpansion/Shaders/e missivefx-windows.unity3d [EXC 14:13:43.227] NullReferenceException: Object reference not set to an instance of an object Kopernicus.Components.ShaderLoader.LoadAssetBundle (System.String path, System.String bundleName) (at <0882401b48d84227ad9c2bbcf4ce8401>:0) KopernicusExpansion.EmissiveFX.ShaderInit.Awake () (at <514cb877ddec4c1781406e60905add56>:0) UnityEngine.GameObject:AddComponent(Type) AddonLoader:StartAddon(LoadedAssembly, Type, KSPAddon, Startup) AddonLoader:StartAddons(Startup) <LoadObjects>d__89:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) <CreateDatabase>d__70:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) GameDatabase:StartLoad() <LoadSystems>d__11:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) LoadingScreen:Start() And this is making Kopernicus bork terribly later, and this is hindering your FPS for sure, because the exception is happening on an Update event from Unity [EXC 14:44:27.485] NullReferenceException: Object reference not set to an instance of an object Kopernicus.Components.KopernicusStar.LateUpdate () (at <0882401b48d84227ad9c2bbcf4ce8401>:0) [EXC 14:44:27.642] NullReferenceException: Object reference not set to an instance of an object Kopernicus.Components.KopernicusStar.LateUpdate () (at <0882401b48d84227ad9c2bbcf4ce8401>:0) [LOG 14:44:33.847] [UIApp] OnDestroy: I think it's unlikely this is causing the problems you are complaining, but this is also hurting your game for sure. So you need to fix Kopernicus or delete it at all from the GameData. And there's FOUR ModuleManagers 3.1.1 on your instalment??? Whatahell? I dig a bit more on the KSP.log and found this: [LOG 14:13:38.908] Load(Assembly): /999_Scale_Redist [LOG 14:13:38.910] AssemblyLoader: Loading assembly at C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\999_Scale_Redist.dll [LOG 14:13:38.973] Load(Assembly): /ModuleManager.3.1.1 [LOG 14:13:38.973] AssemblyLoader: Loading assembly at C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\ModuleManager.3.1.1.dll [LOG 14:13:39.034] AssemblyLoader: KSPAssembly 'ModuleManager' V2.5.0 [LOG 14:13:39.035] Load(Assembly): /ModuleManager.4.1.0 [LOG 14:13:39.035] AssemblyLoader: Loading assembly at C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\ModuleManager.4.1.0.dll [LOG 14:13:39.093] AssemblyLoader: KSPAssembly 'ModuleManager' V2.5.0 [LOG 14:13:39.093] Load(Assembly): /ModuleManager.4.1.1 [LOG 14:13:39.093] AssemblyLoader: Loading assembly at C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\ModuleManager.4.1.1.dll [LOG 14:13:39.161] AssemblyLoader: KSPAssembly 'ModuleManager' V2.5.0 [LOG 14:13:39.161] Load(Assembly): /ModuleManager.4.1.3 [LOG 14:13:39.161] AssemblyLoader: Loading assembly at C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\ModuleManager.4.1.3.dll [LOG 14:13:39.224] AssemblyLoader: KSPAssembly 'ModuleManager' V2.5.0 I'm not exactly thrilled on this issue, as there's code on MM to elect a "winner" when more than one is alive on Unity's guts, and this code depends of the correct Versioning to work correctly. And, right now, the wrong MM is being used! [LOG 14:13:42.646] [ModuleManager] version 3.1.1.0 at C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\ModuleManager.3.1.1.dll won the election against Version 3.1.1.0 C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\ModuleManager.4.1.0.dll Version 3.1.1.0 C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\ModuleManager.4.1.1.dll Version 3.1.1.0 C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\ModuleManager.4.1.3.dll DAMNIT, THIS IS UNBELIEVABLE. I urge you to delete all Module Managers but the 4.1.3 one. I wil continue to dig for problems, perhaps we have some conflict on some other Add'On, but, right now I urge you to implement the fixes I'm proposing above, as these ones are known sources of problems (one of them, a very nasty one! - damnit!). If by some reason this fixes the FATALities, please, please, let me know.

I see your point, but I want to share my own - harsh, heavy hand attitudes may not be polite or nice, but on the other hand they are not always evil. In the early 2k, I was working on a technology park where a few big tech companies were taking out sourcing contracts from some really big players on that era, as Nokia, Siemens Mobile at all. On a project I was working, we had a problem - my boss was involved on a CMM homologation process and had personal interests on the matter, to the point that he ended up hindering my deliveries, as the development process was still too immature to real life application. The client was getting somewhat impatient, and I was the one between two colliding forces. So the CTO of the client came to my working station, and gave me a hell of a cheeks bash. He almost yelled to me that he was the one paying the bills there, he was the one calling the shots and he was the one firing people on that company. And made absolutely clear that I would be held responsible for the outcome of the project I was working on. Dude, and all of that with my team mates with their white faces looking into each other. One may think that the client's CTO was too harsh on me, even utterly unfair. You can bet your mouse it was what I thought at the time. Now, 20 years later and with a wiser version of me looking back, let me explain what he did: he set me free. Once I was entirely responsible for the outcome of the project I was working, I also became the one calling the shots and, yes, I overrun my boss every single time he decided something that would affect my project. Pretty nasty, I must say - at that time I had no other place to work (small park, the companies had an agreement of not hiring each other employees) and I did everything I could to do not lose that job (I had a kid to rise). The after math? The project was delivered on time and on budget. Some time later, due unrelated happenings, the Business Unit I was working was disbanded and a lot of people, unfortunately, lost their jobs. I stayed and was moved to another Business Unit - to tell you the true, I could choose the B.U. I wanted to go. So, without further (and reliable) information, it's way premature to call T2 evilness. As I said on other post, there are evilness on this industry (see what Konami did to Kojima), but not all evil deeds are meant to accomplish evil purposes - see the history I told above.