Lisias

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.

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)