Search the Community

Now I'm worried. Let's see your logs... (hack, hack, slash and hack again) Well, most of the problems are like this: [LOG 15:09:36.222] [TweakScale] ERROR: **FATAL** Part rocketNoseConeSize4 (Protective Rocket Nose Cone Mk16A) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 What suggests there're more than one dude patching these parts with TweakScale. Digging around, I found: [LOG 15:06:59.350] Applying update SquadExpansion/MakingHistory/Aero/@PART[rocketNoseConeSize4]:NEEDS[SquadExpansion,TweakScale] to SquadExpansion/MakingHistory/Parts/Aero/protectiveRocketNoseMk16/rocketNoseCone_size4.cfg/PART[rocketNoseConeSize4] [LOG 15:07:03.513] Applying update TweakScale/patches/SquadExpansion/MakingHistory/Aero/@PART[rocketNoseConeSize4]:NEEDS[SquadExpansion,TweakScale] to SquadExpansion/MakingHistory/Parts/Aero/protectiveRocketNoseMk16/rocketNoseCone_size4.cfg/PART[rocketNoseConeSize4] Confirming my hypothesis. We have TweaScale pathing things (<KSP>/GameData/TweakScale/Patches/SquadExpansion/yadayada), but also something else inside <KSP>/GameData/SquadExpansion itself, and whatever it is, it should not be there!! I think you will find a rogue file inside your SquadExpansion called <KSP>/GameData/MakingHistory/SquadExpansion/Aero.cfg. Delete it, please, if it's there. As well the following ones: <KSP>/GameData/MakingHistory/SquadExpansion/Aero.cfg <KSP>/GameData/MakingHistory/SquadExpansion/Coupling.cfg <KSP>/GameData/MakingHistory/SquadExpansion/Engine.cfg <KSP>/GameData/MakingHistory/SquadExpansion/FuelTank.cfg <KSP>/GameData/MakingHistory/SquadExpansion/Ground.cfg <KSP>/GameData/MakingHistory/SquadExpansion/Payload.cfg <KSP>/GameData/MakingHistory/SquadExpansion/Pods.cfg <KSP>/GameData/MakingHistory/SquadExpansion/Propulsion.cfg <KSP>/GameData/MakingHistory/SquadExpansion/Structural.cfg <KSP>/GameData/MakingHistory/SquadExpansion/Thermal.cfg If they are not there, well, we have a hell of a problem to diagnose then… I also noticed that the KSP-Recall patches are installed on the wrong place!!! Currently, they are on <KSP>/GameData/patches, a completely wrong place. Please remove <KSP>/GameData/patches and everything inside, and install KSP-Recall properly! As a matter of fact, the whole KSP Recall thingy is messed up! Right now, I would suggest you to take a completely clean GameData from what you had download, and reinstall everything from scratch - following the install instructions to the letter: https://github.com/net-lisias-ksp/KSP-Recall/blob/master/INSTALL.md https://github.com/TweakScale/TweakScale/blob/master/INSTALL.md I also suggest you to update ModuleManager to the latest, 4.3.4, as it have some important bug fixes that besides not affection you right now, it will eventually! Let me know if you need help on this process!

Yep, you got caught by what appears to be a new batch of bad patching. I found the log entries that are bothering you: [LOG 22:57:17.281] [TweakScale] WARNING: Duplicate TweakScale module on part [US.1C10.Wedge.Quadcore] Universal Storage: QuadCore [LOG 22:57:20.084] US.1C10.Wedge.Quadcore added to ship - part count: 2 [LOG 22:57:20.102] [TweakScale] WARNING: Part US.1C10.Wedge.Quadcore has a Rogue Duplicated TweakScale! [LOG 22:57:20.240] [TweakScale] WARNING: Duplicate TweakScale module on part [US.1C10.Wedge.Quadcore] Universal Storage: QuadCore [LOG 22:57:23.210] [TweakScale] WARNING: Part US.1C10.Wedge.Quadcore has a Rogue Duplicated TweakScale! Misteriously, this part was deleted by someone right after these messages: [LOG 22:57:31.396] deleting part US.1C10.Wedge.Quadcore And I assure you it wasn't by me (everything I do is logged and have a tag identifying who has done it). So I kept digging, and found this: [LOG 22:38:15.892] Applying update 999_KSP-Recall/patches/attached-on-editor/@PART[*]:HAS[!MODULE[ProceduralPart],!MODULE[WingProcedural],!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA]]:LAST[KSPRECALL-ATTACHED-ON-EDITOR]:NEEDS[TweakScale] to UniversalStorage/Parts/US_1C10_Wedge_Quadcore/US_1C10_Wedge_Quadcore.cfg/PART[US_1C10_Wedge_Quadcore] < some other logs> [LOG 22:38:15.892] Applying update 999_KSP-Recall/patches/attached-on-editor/@PART[*]:HAS[!MODULE[ProceduralPart],!MODULE[WingProcedural],!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA]]:LAST[KSPRECALL-ATTACHED-ON-EDITOR]:NEEDS[TweakScale] to UniversalStorage/Parts/US_1C10_Wedge_Quadcore/US_1C10_Wedge_Quadcore.cfg/PART[US_1C10_Wedge_Quadcore] I mentioned this because KSP-Recall is mine, and you can bet your mouse I care about my patchings. So this tends to rule out any addon as a source of the bad patchings, because I know for sure the above patch is solid - because I wrote and tested it myself. With this in mind, I kept digging for who would be being induced to bork the same - more as curiosity than anything else, because at this point I was thinking I already knew what's happening: [LOG 22:37:35.167] Applying update UniversalStorage/Compatability/US Tweakscale/@PART[US_*] to UniversalStorage/Parts/US_1C10_Wedge_Quadcore/US_1C10_Wedge_Quadcore.cfg/PART[US_1C10_Wedge_Quadcore] <some more log entries> [LOG 22:37:35.167] Applying update UniversalStorage/Compatability/US Tweakscale/@PART[US_*] to UniversalStorage/Parts/US_1C10_Wedge_Quadcore/US_1C10_Wedge_Quadcore.cfg/PART[US_1C10_Wedge_Quadcore] And now we have found the patch involved in the mess. I didn't cared to look on the patching itself, because the KSP-Recall entries above had already hinted this is a bad process of patching, not bad patches. This looks like having two ModuleManagers in memory at the same time - I had already diagnosed this once, I even wrote a tool to detected that. But I didn't found any rogue DLL on your rig, so this apparently this is not the reason, because I didn't found any rogue DLL listed in your KSP.log… So I choose a random part, nfa-atomic-jet-25-1, and tracked all the patchings this part had and: Applying update 999_KSP-Recall/patches/attached-on-editor/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update 999_KSP-Recall/patches/attached-on-editor/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update 999_KSP-Recall/patches/refunding/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update 999_KSP-Recall/patches/refunding/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update AtmosphereAutopilot/csurf_sync/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update AtmosphereAutopilot/csurf_sync/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update Diazo/AGExt/part/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update Diazo/AGExt/part/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update InterstellarFuelSwitch/PatchManager/ActiveMMPatches/IntegratedDecoupler/@PART[*]:FINAL to NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update InterstellarFuelSwitch/PatchManager/ActiveMMPatches/IntegratedDecoupler/@PART[*]:FINAL to NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update KSPCommunityFixes/MMPatches/ModSupport/KSPRecall/@PART[*]:HAS[@MODULE[Refunding]]:NEEDS[KSPRECALL-REFUNDING]:FINAL to NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update KSPCommunityFixes/MMPatches/ModSupport/KSPRecall/@PART[*]:HAS[@MODULE[Refunding]]:NEEDS[KSPRECALL-REFUNDING]:FINAL to NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update NearFutureAeronautics/Patches/NFAeroCTT/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update NearFutureAeronautics/Patches/NFAeroCTT/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update ProbesBeforeCrew/Mod Support/ZsNF-AeronauticsPatch/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update ProbesBeforeCrew/Mod Support/ZsNF-AeronauticsPatch/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update StationScience/MKSEffects/@PART:NEEDSto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update StationScience/MKSEffects/@PART:NEEDSto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update TweakScale/Deprecating/patches/NF/NFA_TweakScale/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update TweakScale/Deprecating/patches/NF/NFA_TweakScale/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update TweakScaleCompanion/PKMC/NFA/patches/000_CleanUp/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update TweakScaleCompanion/PKMC/NFA/patches/000_CleanUp/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update TweakScaleCompanion/PKMC/NFA/patches/000_CleanUp/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-multimode-25-1.cfg/PART[nfa-atomic-multimode-25-1] Applying update TweakScaleCompanion/PKMC/NFA/patches/000_CleanUp/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-multimode-25-1.cfg/PART[nfa-atomic-multimode-25-1] Applying update TweakScaleCompanion/PKMC/NFA/patches/Engine/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update TweakScaleCompanion/PKMC/NFA/patches/Engine/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update UmbraSpaceIndustries/Konstruction/Patches/EVAConstructionTweaks/@PART[*]:HAS[!MODULE[ModuleCargoPart],#mass]:Final to NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update UmbraSpaceIndustries/Konstruction/Patches/EVAConstructionTweaks/@PART[*]:HAS[!MODULE[ModuleCargoPart],#mass]:Final to NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update UmbraSpaceIndustries/MKS/Patches/ScrapParts/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update UmbraSpaceIndustries/MKS/Patches/ScrapParts/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update WarpPlugin/Patches/OreTanksFix/@PART[*]:FINAL to NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update WarpPlugin/Patches/OreTanksFix/@PART[*]:FINAL to NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] (I removed the timestamps to allow ordering the logs and making the double patch better detectable). Wow… EVERYTHING IS BEING PATCHED TWICE. Absolutely everything. This is a Module Manager issue. I suggest you cry for help on MM's Thread, as I can't help further on this one!

I don't believe. I know it. I'm not really fixing things for now, I'm patching them up to prevent the worst scenarios. There're no easy way out of this. I'm not masochist , I really didn't found a better solution other than that Big Refactoring from Krakens of mine. That's interesting. I will investigate. [Reproduced. See the POST EDIT below] I think this is a good time to explain that Module Manager is not the problem. It only happens that it doesn't have, at least to the momento, any features that would allow it to be part of the Solution (at least, the Solution I managed to cook). The problem are rogue patches. And the only sane fix is to detect and fix the patches. Clutches to cope with the rogue patches will just make things worst, as the clutches themselves can induce new colateral effects in a chain reaction - sometimes without perceptible symptoms until the crash and/or game corruption. Thanks for your efforts. We don't need to agree on every step to recognize the huge efforts you are doing for TweakScale. If a purely stock with TweakScale is borking, you are right on pinpointing TweakScale as the source of the bork. I should had done this again after the new discoveries of past few weeks to tell you the true. What I know for sure is that TweakScale doesn't add itself to any part (and only recently I added code to withdraw itself from some nasty detectable scenarios), so the source of the glitch (to say the least) are the patches. This will be a dirty and gruesome task, but another one I need to accomplish is to test adding the patches gradually (it's a bit less painful using a binary tree search approach) in order to reduce the scope of the hunt. But, on the other hand (and again), that BFR (Big Fine Refactoring ) would render this task unneeded, as Add'On support will be dismembered, drastically reducing the surface of attack for such bugs. So I'm kind of uncertain if I should waste yet more time on patching new roles on the dam instead of solving the thing properly. This is where I'm get some reserves with. This will not fix the rogue patches, this will hide them. The reasons for that follows: A bad standard is better than no standard. It's TweakScale the reference for scaling. Instead of blindly patching it to cope with random Add'Ons, it's that random Add'Ons that should, ideally, be patched to cope with TweakScale. By doing this, everybody will be on the same page. If TweakScale would cope with rogue patches by demand, so we would have no standard or expected defaults to cope with - and that would be a unholy mess of biblical dimensions. It's already hard to cope with the current patches (as you are pinpointing above). Now try to imagine the huge colateral effects we would have by blindly changing the patches. See below for a technical explanation This will not prevent rogue patches to exist. It will make them harder to detect. Right now, it's feasible to monitor MM as it applies patches in order to catch who is duplicating things once you have named a part with double data. It's one of the features I'm planning for somewhat in future, by the way. Without this, I would have to instrument Module Manager itself so he would raise an exception when such part is detected - but this would need to inject more knowledge on MM than it really needs to work, and a already complex piece of software would had it's already huge surface of attack for bugs even wider without not direct benefit for its core business Dismembering the patch support will drastically reduce that surface of attack to manageable levels, as the majority of the users will not be exposed to more patches than they need. This appears to be the biggest lesson we can take from your reports. That technical reason I mentioned is due the way ConfigNode handles "arrays". When you add an array to a ConfigNode, you have a ordered (but not necessarily sequential) collection of data with the same name. You need to use a specific call to get all the values under that name, and if you use the call for singleton values you get the last value. But I'm used to see code that uses the "array version" of the call and then getting the first value (I wonder if by similar reasons). This last scenario would break beautifully if I edit an value that people are used to get duplicated and selecting the first one, and then people start to get the value from the later adders instead of the expected value added by the first one! And since by the ASCII ordering TweakScale tends to be the last guy on the chain, it also tends to be prevalent on that scenario - i.e., any guy that have a disagreement with TweakScale on something and is used to get the first value will get suddenly "wrong values" came from nowhere. So… It will accomplish very few, can potentially break expected behaviour (wrong behaviour, but a expected one nevertheless - remember when I said that a bad standard is better then no standard at all?) and the rogue patches will still be there. And the real problem are the rogue patches. Patches getting old without proper supervision. The dismembering will help on this too. You need to understand a bit about Module Manager patches first. A TweakScale config is nothing more than a patch. Unless you are considering support TweakScale directly, and then TweakScale would be a hard dependency for your parts. If this is the case, I would suggest you to rethink this. Not everybody wants to use TweakScale - this could limit your audience. In my humble opinion, the best approach is to write MM patches for your Add'On and include them on the release, and tell MM to ignore such patches when TweakScale is not installed (see the :NEEDS clausule). Or give a peek on the github directly, and make use of the auto-formatting features of the site. https://github.com/net-lisias-ksp/TweakScale/blob/master/GameData/TweakScale/Examples.cfg https://github.com/net-lisias-ksp/TweakScale/blob/master/GameData/TweakScale/documentation.txt @Tyko - some text editors are using proportional fonts as default nowadays, messing up beautifully the visualization of the good, old and faithful text files. It's one of the reasons I, by default, use TABs and not spaces on my projects - my colleagues can set up the TAB width in pixels as they want, and (almost) everybody end up happy. — — — POST EDIT — — — I reproduced the problem described above (with a screenshot). Things are a bit hairy, by the way. This is the grep for my KSP.log looking to EnginePlate4 (the internal name for the EP 50): $ cat KSP.log | grep "EnginePlate4" [LOG 00:31:43.977] Config(PART) SquadExpansion/MakingHistory/Parts/Coupling/EnginePlate_4/EnginePlate4 [LOG 00:31:44.020] Config(@PART[EnginePlate4]) TweakScale/patches/SquadExpansion/MakingHistory/Coupling/@PART[EnginePlate4] [LOG 00:31:51.727] [ModuleManager] INFO: Applying update TweakScale/patches/SquadExpansion/MakingHistory/Coupling/@PART[EnginePlate4] to SquadExpansion/MakingHistory/Parts/Coupling/EnginePlate_4/PART [LOG 00:32:32.018] PartLoader: Compiling Part 'SquadExpansion/MakingHistory/Parts/Coupling/EnginePlate_4/EnginePlate4' [LOG 00:32:32.048] PartLoader: Part 'SquadExpansion/MakingHistory/Parts/Coupling/EnginePlate_4/EnginePlate4' has no database record. Creating. [LOG 00:32:32.055] DragCubeSystem: Creating drag cubes for part 'EnginePlate4' [WRN 00:33:17.429] [TweakScale] Removing TweakScale support for EnginePlate4. [ERR 00:33:17.429] [TweakScale] Part EnginePlate4 didn't passed the sanity check due having a ModulePartVariants with Mass - see issue #13 https://github.com/net-lisias-ksp/TweakScale/issues/13. This confirms my thesis de the MM is not on the guilty list for this problem. I used MM3 by the way, to prevent any worries due the new parallelized patching routines. On the MM cache I found this: UrlConfig { name = EnginePlate4 type = PART parentUrl = SquadExpansion/MakingHistory/Parts/Coupling/EnginePlate_4 PART { name = EnginePlate4 module = Part author = RoverDude rescaleFactor = 1 node_stack_top = 0,0.4,0,0,1,0,4 node_stack_bottom = 0,0,0,0,-1,0,4,0,0,1,0 breakingForce = 2500 breakingTorque = 2500 fx_gasBurst_white = 0.0, 0.0650517, 0.0, 0.0, 1.0, 0.0, decouple sound_vent_large = decouple TechRequired = metaMaterials entryCost = 3000 cost = 300 category = Coupling subcategory = 0 title = EP-50 Engine Plate [ CUT -- CUT -- CUT -- CUT -- ] MODULE { name = TweakScale type = stack defaultScale = 5.0 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 TWEAKSCALEEXPONENTS { mass = 2 } TWEAKSCALEEXPONENTS { name = TweakScale DryCost = 0.5 } } } } Well. we have a problem: a duplicated TWEAKSCALEEXPOENTS thingy. This is fixed on the development branch, and was identified by @Tonka Crash here. The hairy situation is that TweakScale 4.1.0 is detecting the EnginePlate4 as an unsupported part, and then it's withdrawing itself from the prefab. However, the thingy somehow survived to tell the history on the GUI. Twice, as we can see. The double slider appears to be due the double TWEAKSCALEEXPOENTS , but frankly, the while shebang should had been deleted from the prefab by now. Need some time to figure my way out of this. The good news is that a new maintenance release for TweakScale is on the works to have this solved. The bad news is that EnginePlate, as any Part using MODULEVARIANTPART with Mass on the variants, is not supported and the patch will be withdrawn on startup. I'm sorry for this, but this part is one of the probably causes for the KSP crashes due improperly mangled mass.

ANNOUNCE Release 2.4.5.2 is available for downloading, with the following changes: Raise the bar to KSP 1.12.2 (Finally) adds support for Parts and Modules from KSP 1.11 and newer. Implements the TweakScaleExperimental Patches Program. A lot of patches are not fully tested, and some Exponents will probably need revising. Since both these patches as well the unavoidable revisions that will follow may unbalance current crafts in savegames, it’s advised discretion on activating the Experimental features. Closes Issues: #186 Check and implement all Modules left behind from 1.4.0 up to 1.10.1 #184 Scale some unsupported parts on EXPERIMENTAL status #182 Get rid of TODOs related to updating scale types. #181 Support the new Parts introduced on KSP 1.12 and Update Scale Exponents to the new Modules #128 Support the new Parts introduced on KSP 1.12 and Update Scale Exponents to the new Modules #120 Support the new Parts introduced on KSP 1.10 #50 Support the new Parts introduced on KSP 1.11 and Update Scale Exponents to the new Modules See OP for the links. (Previous announce) Highlights TweakScaleExperimental support for parts and modules From 2.4.5.2, TweakScale is starting to support, as possible, all KSP modules - and not only the most visible ones, as well parts. In order to pursue that goal without risking your ongoing savegames (as changing Exponents will unbalance your designs, potentially ruining your crafts), some parts and modules scalings are only available on Experimental mode. Such mode will patch almost all KSP parts and modules (but Serenity/Breaking Ground as this one will be tackled down later, see the backlog for more information), including some that I’m unsure should be scaled - not to mention Exponents that I’m pretty sure will need some rebalancing. In order to toy with these parts and modules, you need to create a directory called TweakScaleExperimental in your GameData. The directory may be empty, it’s enough to have it on GameData so Module Manager will register it, satisfying the :NEEDS that enable such patches and Exponents. Please only enable these patches on disposable or non valuable KSP installments. These patches are going to change for sure in the near future, and these changes will be incompatible with savagames created with the previous set of Experimental patches. Standard mechanism to control TweakScale availability From 2.4.5.0 and up, it’s possible to deactivate TweakScale on some (or even all) parts by patching or on the user interface without affecting living crafts on the savegame (or even already existent craft files). A patching only feature can lock up TweakScale on the current state, making easier to create artefacts to automatically reconfigure a savegame for Challenges with specific rules. Again, without affecting existent crafts or savegames - once the craft is launched, it’s not affected by these options. See the Documentation for details. Parts with Variants Variants that change Cost and/or Mass are now fully supported, but TweakScale is struggling to support Parts with Variants that changes Attachment Nodes. I had planned to withdraw TweakScale support from such parts as I did in the past, but then I realised that most Version 2 parts from already scalable parts (as Terrier…) would had TweakScale withdrawn, and this would render some crafts and savegames corrupted. Since most of these parts didn’t misbehave on a noticeable way, I decided to just let it go as is for while. Just a few stock parts are misbehaving into a noticeable way, and these parts are (until the moment): The Mastodon engine The Structural Tubes T-12 T-18 T-25 T-37 T-50 And probably more, as Add'Ons starts to use such feature. The only workaround at the moment is to descale these parts before applying the variant and then scaling them again. Alternatively, just detach and reattach the misbehaving parts. A proper fix is Work in Progress, and is expected to be released on 2.4.4.1. Deprecating Patches Support for all non Squad parts are on a deprecating status and will be definitively removed on TweakScale 2.5. The TweakScale Companion Program will be the source for supporting third-parties add'ons. It’s advised to install the needed Companions as they reach Gold status. Sanity Checks Parts using Firespitter’s FSbuoyancy needs the latest TweakScale Companion for Firespitter, as only the Companion has the specific code that knows how to handle it. Overrules A overrule, as the name says, is a patch the overrules TweakScale (and anything else) in order to make things broken in a deterministic way. A complete essay can be found here. Hot Fixes A Hot Fix is a hand crafted patch that fixes by brute force patching problems, forcing the original intended result for a given KSP installment. The difference from an overrule is that Hot Fixes don’t break compatibility with sane installments, so you can start new savegames and share your crafts without worries. A complete essay can be found here. New Scaling Behaviour A new TWEAKSCALEBEHAVIOUR, ModuleGeneratorExtended , is available for parts using ModuleGenerator that wants to scale the INPUT_RESOURCES too. This feature wasn’t introduced directly into the ModuleGenerator’s TWEAKSCALEEXPONENTS to prevent damage on Add'Ons (and savegames) that rely on the current behaviour (scaling only the output), as suddenly the resource consumption would increase on already stablished bases and crafts. Just add the lines as the example below (the output resources scaling is still inherited from the default patch!). @PART[my_resource_converter]:NEEDS[TweakScale] { #@TWEAKSCALEBEHAVIOR[ModuleGeneratorExtended]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = free } } WARNINGS The known Unholy interaction between modules (Kraken Food), rogue patches or known incompatibilities between third parties Add'On that can lead to disasters are being detected on the Sanity Checks with a proper (scaring) warning being shown. A full essay about these issues can be found here. Unfortunately, such issues are a serious Show Stopper, potentially (and silently) ruining your savegames. This is not TweakScale fault, but yet it’s up to it to detect the problem and warn you about it. If this happens with you, call for help. A Cancelbutton is available for the brave Kerbonauts willing to fly unsafe. TweakScale strongly recommends using S.A.V.E.. Special procedures for recovering mangled installments once the TweakScale are installed (triggering the MM cache rebuilding) are possible, but keep your savegames backed up. And DON`T SAVE your crafts once you detect the problem. Reach me on Forum for help. TweakScale stills mangles further affected crafts and savegames with some badly (but recoverable) patched parts so when things are fixed, your crafts preserve the TweakScale settings without harm. THIS DOES NOT FIX THE PROBLEM, as this is beyond the reach of TweakScale - but it at least prevents you from losing your crafts and savegames once the problem happens and then it is later fixed. You will detect this by KSP complaining about a missing TweakScaleRogueDuplicate module (previously TweakScaleDisabled, renamed for clarity). You can safely ignore this. Keep an eye on the Known Issues file. — — — — — This Release will be published using the following Schedule: GitHub, reaching first manual installers and users of KSP-AVC. Right now. CurseForge. Right now. SpaceDock (and CKAN users). Right now. The reasoning is to gradually distribute the Release to easily monitor the deployment and cope with eventual mishaps.

Whoa.... Your craft have 144 Rogue TweakScale sections! (from the 752 Parts used). Gosh. First, the good news: this is annoying, but right now is not dangerous. Nothing bad will happens. BUT Your kind of rogue patching is the dangerous one, both sections have different receipts! Look what I have for SYdecouplerRadial1_4290221204 : MODULE { name = TweakScale isEnabled = True currentScale = 2 defaultScale = 1 defaultTransformScale = (1, 1, 1) DryCost = 7104 stagingEnabled = True EVENTS { } ACTIONS { } UPGRADESAPPLIED { } } MODULE { name = TweakScaleRogueDuplicate // Programatically tainted due duplicity or any other reason that disabled this instance. Only the first instance above should exist. This section will be eventually deleted once the craft is loaded and saved by a bug free KSP installment. You can safely ignore this section. isEnabled = True currentScale = 1 defaultScale = 1 defaultTransformScale = (0, 0, 0) DryCost = 888 stagingEnabled = True EVENTS { } ACTIONS { } UPGRADESAPPLIED { } } currentScale , defaultTransformScale and DryCost are different between the the used and the rogue section. This means that if we 'fix" the patch that patched it first (let's suppose a toe stomping patch from an Add'On those name starts with "S" - they are patched earlier than TweakScake ones on the LEGACY pathing phase), all your crafts and savegame will be corrupted, like this: Do you see why I code these pesky warnings now? On the bright side, after running a report on your log file, it ends up that only two parts are, effectively, being rogue patched - so it just happened that you used that parts a lot. macmini62:1 lisias$ cat KSP.log | grep -oP "Duplicate TweakScale .+\[(.+)\]" | sort -u Duplicate TweakScale module on part [SYdecouplerRadial1] Duplicate TweakScale module on part [SYejectatron] This make things way easier. This is the patching for the SYdecouplerRadial1 : [LOG 23:15:54.232] Applying update ModRocketSys/Patches/MRS_TweakScale/@PART[SYdecouplerRadial1]:NEEDS[TweakScale] to SpaceY-Lifters/Parts/Decouplers/SYdecouplerRadial/SYdecouplerRadial1.cfg/PART[SYdecouplerRadial1] [LOG 23:15:54.564] Applying update SpaceY-Lifters/Patches/0_TechTree/@PART[SY*]:NEEDS[!CommunityTechTree&!HPTechTree] to SpaceY-Lifters/Parts/Decouplers/SYdecouplerRadial/SYdecouplerRadial1.cfg/PART[SYdecouplerRadial1] [LOG 23:15:54.612] Applying update SpaceY-Lifters/Patches/SpaceY_TweakScale/@PART[SYdecouplerRadial1]:NEEDS[TweakScale] to SpaceY-Lifters/Parts/Decouplers/SYdecouplerRadial/SYdecouplerRadial1.cfg/PART[SYdecouplerRadial1] [LOG 23:16:02.889] Applying update 999_KSP-Recall/patches/resourceful/@PART[*]:FINAL to SpaceY-Lifters/Parts/Decouplers/SYdecouplerRadial/SYdecouplerRadial1.cfg/PART[SYdecouplerRadial1] [LOG 23:16:02.983] Applying update BetterBurnTime/SRBurnTime/@PART[*]:HAS[@RESOURCE[SolidFuel],@MODULE[ModuleEngines]:HAS[@PROPELLANT[SolidFuel]]]:FINAL to SpaceY-Lifters/Parts/Decouplers/SYdecouplerRadial/SYdecouplerRadial1.cfg/PART[SYdecouplerRadial1] [LOG 23:16:03.180] Applying update InterstellarFuelSwitch/PatchManager/ActiveMMPatches/IntegratedDecoupler/@PART[*]:FINAL to SpaceY-Lifters/Parts/Decouplers/SYdecouplerRadial/SYdecouplerRadial1.cfg/PART[SYdecouplerRadial1] From this report, I learn that SYdecouplerRadial1 is a part from SpaceY Lifters. And that this fine Add'On has its own TweakScale patches (there're no embedded support for them on TweakScale). However, the ModRocketSys Add'On also patches this part - and this is where things get hairy as they are being applied before the canonical ones from the SpaceY. Messy. Since no one of the involved Add'Ons have git public repositories, I will need to download them to eyeball the patches - what I cannot do right now on working time. I will go back to this issue later, don't worry. Right now, DO NOTHING. I will code a custom HOTFIX to you in order to have this sorted out for you, and then I will see what can be done to solve the problem for everybody on the Add'On themselves. Stay tuned! @renejant, here is your HotFix. Download this file (click on the Raw button!) or copy and paste the contents of this box into notepad or some other text editor: @PART[SYdecouplerRadial1,SYejectatron]:NEEDS[SpaceY-Lifters,ModRocketSysLite]:FINAL // Space-Y Radial Decoupler, regular { -MODULE[TweakScale],* { } %MODULE[TweakScale]:NEEDS[TweakScale] { type = surface HOTFIX = https%3A%2F%2Fforum.kerbalspaceprogram.com%2Findex.php%3F%2Ftopic%2F179030-ksp-141-tweakscale-under-lisias-management-24315-2020-0622%2F%26do%3DfindComment%26comment%3D3812504 } } Save the file on somewhere inside your GamData I strongly suggest GameData/__LOCAL/TweakScale/HotFixes , so it's easy to keep track of any hotfixes and to get rid of them when needed. Essentially, this patch deletes any TweakScale support from the affected parts and install a fresh copy, based on the SpaceY-Lifters (identical to the rogue patch on ModRocketSysLite). This will fix your issue, but there's one caveat: if anyone else repatches that part, even by following every good practice, this patch will obliterate any change and brute force that one instead. Ideally, this should be removed from your instalment as soon as ModRocktSysLite is fixed so you don't have to keep remembering about it. Cheers!

NOTAM A bug on a workaround code for an old problem was found on TS 2.4.6.22 . TL;DR: in the past, bad patches were plaguing the TweakScale ecosystem, and one of that bad patching is injecting TweakScale twice in a part. I don't need to explain what would happen with two TS modules trying to scale the same part at the same time. We can easily reproduce this using the following patch somewhere in your GameData @PART[strutCube]:FINAL { MODULE { name = TweakScale type = screwed defaultScale = 3125 } } From this point, all strutCube parts will have two TweakScale sections in your craft and sfs files: Everything was fine for some years, until I had changed something on 2.4.6.22 to solve another issue, and created this one by accident. A fix is currently work in progress: https://github.com/net-lisias-ksp/TweakScale/issues/290 The workaround for this problem is to revert back to 2.4.6.21 until the next release is published - or to fix your patching. I may had created a bug on the workaround code for this problem, but the trigger for it is still a bad patch. I would recommend to @AlonzoTGto double check his installation, as I had said initially - or perhaps just stop modding your KSP, if you don't know how to do it properly. @Luna Cat, @Professor K, please send me your Logs/ModuleManager/* contents and your GameData/ModuleManager.ConfigCache for inspection. You guys do have rogue patchings in your rig, and these are a known source of problems. This doesn't excuse TweakScale from this problem, but ideally you should get rid of those too! I will gladly help on the task. Last, but not least, I want to give a huge thank you to @GoAHead for their invaluable help on diagnosing this one. I had completely forgot about this TweakScaleRogueDuplicate stunt, I would never be able to diagnose this one without such marvellous help. TweakScale 2.4.6.23 is on the works, and it will be issued as soon as possible™.

Recently, I explained about Overrules and HotFixes. Today I want to explain exactly what are the problems that were affecting TweakScale in the past (or still are), and that ended up motivating the Warnings, Alerts, Overrules and HotFixes. Mass Zero mass is evil. Negative mass too. And these affect every part that has mass, i.e., everything and the kitchen's sink. Including the Modules. And this is not exclusive for TweakScale, every single Add'On that mangles with the mass are prone to this glitch (as Fuel Switches). This is not a problem, but a fact: we can't have parts with negative or zero mass. So we must be careful to avoid such situations (at least, by accident), or we end up injecting divisions by zero into the Physics Engine. And divisions by zero are bad, really bad. It injects NaNs on everything, and the games goes crazy. Really crazy. Negative mass inverts the forces on that part - specially thrust. This is the reason some crafts get "stuck" in the launchpad . You apply the thrust on a part, this part "pushes" the next, but that next part has negative mass and the force vector is negated and then it pushes back the first part. If we are talking a heavy fuel tank, that pushing back is enough to over stress everything and so things goes to space in the most unpleasant and undesirable way. Zero mass zero the forces, so the part became unmovable. Same thing. Since TweakScale, when scaling a part, obviously scales the mass, TweakScale is the preferential victim of the problems I will describe below. But make no mistake, TweakScale can be the preferential victim, but it's not the only one. Gravity appears to be affected too, as the statics around the launch pad start to explode by itself if you leave the craft lingering time enough on the launchpad - even with engines off. Related issues: https://github.com/pellinor0/TweakScale/issues/83 Every single problem below can, eventually, end up with Zero or Negative mass. And that's the reason I need to tackle down them before doing any further development. So, in a nutshell: don't blame the Screaming Victim. Unsupported Parts New parts, new code. This is on me. Real Life and that pesky Toe Stomping Fests I will describe below prevented me to carry on these tasks, so I decided to withdraw, in runtime, TweakScale from that parts to prevent breakage. Any part (stock or not) that has ModuleVarianPart with mass. Issue #13. Well, scaling parts with Variant is working - except for mass. The (clever) algorithm that applies the exponents to the datuns doesn`t knows (yet) about ModulePartPariant that have mass. And so, applies the exponent only on the root part and ignore the Variant. It happens that on some parts, the root mass is negative or zero, and the mass on the selected Variant is applied to it to get the final mass of the part. Well, if I scale the negative mass enough, the Variant mass would no be enough to make the total mass above zero (or can make it equals zero). Any part with B9PartSwitch and Modular Fuel Tanks. Issues #54 and #56. Patching a part with more than one fuel switch is bad enough. Instead of play cat-and-mouse with problems with Fuel Switches, is more sensible to do not patch a part with more than one Fuel Switch! Any part with FSBuoyancy. Issue #9. Don't have a clue yet about what's happening. These are things that I want to solve, but not before getting patches right. It's nuts to fight a two front war. The present iteration, TweakScale 2.4.3.x , is finishing with that patch problems. The next iteration, 2.4.4.x will have these (and more, as Serenity) parts supported. Rogue Patching This is, easy, the worst problem at the moment. And this is not on me, as TweakScale depends of correctly written patches in order to correctly do its job. Rogue patching happens when one or more patches apply the same (or slightly different) patch on the same part by accident; by something that changed somewhere, sometime; or by plain disregarding anything else. I'm pretty sure these patches worked fine on that time on the developer's machine - but we need to have these patches working fine now and on the users' machine, otherwise things may go kaput. Of course some of the default TweakScale patches were also defective. The detected ones are already fixed, and besides I had eye balling all of them by now, some of the default patches relates to Add'Ons I don't find for downloading anymore. So, yeah, these will be deprecated on the 2.4.4.0 release, but they will be available on the Extras folder on the distribution ZIP - just in case. These patches renders any Add'On using bad or unintended rules for doing the job. Worse, since rogue patching usually is unintended, it's not controlled and so you can have the GameDatabase mangled into a bad configuration without notice, and once you load Crafts and Savegames using that ruined GameDatabase, you have corrupted Crafts and Savegames in your installment. The really nasty side effect of this is that, sometimes, by fixing the GameDatabase you ruin your Savegames that became "addicted" to the ruined one. Besides affecting any Add'On, TweakScale by its nature and popularity ends up being the most usual Screaming Victim of these rogue patches -TweakScale need correct rules in order to scale things, including mass - and as I explained above, making errors on handling the mass of a part is ruinous. Of course, not every rogue patching ends in disaster. Some of them are just annoyances. But it's easier (and more feasible) to detect any rogue patching and fix them, than to try to workaround in code every single possibility of bad patching in order to overcome the effects - not to mention that this would be a fool's errand, as it's not possible to automatically guess the right patching with accuracy except on the most simple mistakes. The following issues are related to this problem: Issue #12. Issue #15. Issue #20. Issue #24. Issue #30. Issue #34. Issue #45. Issue #49. Issue #56. Issue #58. Issue #60. Issue #62. Issue #63. Issue #67. Issue #69. Issue #70. And the list is growing. Please note that not a single one of that issues is related to the TweakScale (the Module). None of this is TweakScale's fault, but it happens that since TweakScale is injected on every Add'On on an installment, and are somewhat popular, TweakScale has a huge exposition to the problem, and so, it's the most usual Screaming Victim of these problems. And, boy, TweakScale is screaming nowadays. Unholy Interactions Between Modules This one, thanks Krakens, are not that usual nowadays. But when it happens… What happens is that some Modules, besides working fine by themselves, now and then borks (or make bork) with a second Add'On. The most interesting case is about a Fuel Switch that, when have his toes stomped by a second Fuel Switch, injects Zero Mass into TweakScale computing. This one was somewhat… interesting… to isolate and detect - besides being simple to workaround. However, not always these problems are due mistakes or flaws. One very hard to get rid nowadays is this one: some Add'Ons (TweakScale between them) uses the Main Menu scene to trigger a lot of initialization procedures, what nowadays happens concurrently (since 1.4.0, I think). Some of them (including TweakScale) needs to read the GameDatabase. But others (including TweakScale) needs to write something into the GameDatabase. And when you have more than one Add'On writing into the GameDatabase at the same time and without controlling the concurrency, we have a Toe Stomping Fest. By some reason (and I don't know if the one that can explain this is Squad or Unity), when an Add'On overwrites something into the GameDatabase, any other guy trying to read that same data at the same time gets an NRE. It's a wild, wide guess, but I think that when you iterate over the GameDatabase, you iterate over a copy of pointers to the data structures. And when someone writes a new version of a data structure, the old version is deallocated and any previous copy of that collection of pointers now have some invalid pointers - and we bork relentlessly on a Null Reference Exception while trying to read that pointer. In a way or another, I managed to mitigate the problem by delaying my turn on the GameDatabase using some heuristics that I managed to make to work most of the time, but not always. Again, this is a fool's errand : every single time a new Add'On decides it needs to configure something on the GameDatabase when the game starts, it's risking stomping the TweakScale's toes. To tell you the true, I think that TweakScale must not be the only one being stomped, but anyway - TweakScale needs to be the last one to check the GameDatabase in order to detect any problems and to setup some needed data before the user loads a savegame - since TweakScale fixes things on the GameDatabase, these fixes need to be applied before any savegame is loaded! Related issues: Issue #2. Issue #15. Issue #31. Issue #36. Issue #37. In a nutshell - if the Add'On has this decorator [KSPAddon(KSPAddon.Startup.MainMenu, <a_boolean_value>)] on a MonoBehaviour and access the GameDabase on its event handlers, this dude is a serious candidate to be a victim, a perpetuator or both on this problem. Again, I want to stress that this is not exactly TweakScale's fault. And it's not a third part Add'On's fault neither - every single one of them work fine by themselves. But yet we need some way to manage the access to the GameDatabase in order to prevent this Toe Stomping Fest, and this is not something that any Add'On Author can do by him/herself - we depend on each other on this. This is the reason I proposed a new feature on Module Manager, by the way: https://forum.kerbalspaceprogram.com/index.php?/topic/50533-140-17x-module-manager-403-august-9th-2019-right-to-ludicrous-speed/page/260/&tab=comments#comment-3611228 Conclusions We, as a Community, have some work to do. In the mean time, I'm writing workarounds. Link to my site where this essay will be updated now and then http://ksp.lisias.net/blogs/tech-support/TweakScale/Issues-that-can-plague-TweakScale

Wow! 167 show stoppers!!! [LOG 10:32:15.837] [TweakScale] INFO: WriteDryCost Concluded : 4194 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 167 Show Stoppers found; 12 Sanity Check failed; 2032 unscalable parts. [LOG 10:32:15.852] [TweakScale] "Houston, we have a Problem!" about show stoppers on patching was displayed Usually such amount of FATAlities are related to duplicated patches by user errors on installing. Exactly. Removing the rogue duplicates will shut up the Houstons. @Darkuss, this is the patching process of just one of the affected parts (Box.Sensor.GasAnalyzer): [LOG 10:10:46.095] Applying update FMRS/FMRS_MM/@PART[*] to Interkosmos/Parts/Box_Sensor_GasAnalyzer.cfg/PART[Box_Sensor_GasAnalyzer] [LOG 10:10:48.270] Applying update Interkosmos/Compatibility/Tweakscale/Interkosmos_Tweakscale 2/@PART[Box_Sensor_GasAnalyzer]:NEEDS[TweakScale] to Interkosmos/Parts/Box_Sensor_GasAnalyzer.cfg/PART[Box_Sensor_GasAnalyzer] [LOG 10:10:48.629] Applying update Interkosmos/Compatibility/Tweakscale/Interkosmos_Tweakscale 3/@PART[Box_Sensor_GasAnalyzer]:NEEDS[TweakScale] to Interkosmos/Parts/Box_Sensor_GasAnalyzer.cfg/PART[Box_Sensor_GasAnalyzer] [LOG 10:10:48.869] Applying update Interkosmos/Compatibility/Tweakscale/Interkosmos_Tweakscale 4/@PART[Box_Sensor_GasAnalyzer]:NEEDS[TweakScale] to Interkosmos/Parts/Box_Sensor_GasAnalyzer.cfg/PART[Box_Sensor_GasAnalyzer] [LOG 10:10:49.099] Applying update Interkosmos/Compatibility/Tweakscale/Interkosmos_Tweakscale/@PART[Box_Sensor_GasAnalyzer]:NEEDS[TweakScale] to Interkosmos/Parts/Box_Sensor_GasAnalyzer.cfg/PART[Box_Sensor_GasAnalyzer] It was parched 5 times alone. This another one, KIS.Container3, was even multiple patched by more than one AddOn! [LOG 10:10:46.134] Applying update FMRS/FMRS_MM/@PART[*] to KIS/Parts/container3/part 2.cfg/PART[KIS_Container3] [LOG 10:10:46.134] Applying update FMRS/FMRS_MM/@PART[*] to KIS/Parts/container3/part.cfg/PART[KIS_Container3] [LOG 10:11:10.256] Applying update TweakScale/Deprecating/patches/KIS_TweakScale 2/@PART[KIS_Container3] to KIS/Parts/container3/part 2.cfg/PART[KIS_Container3] [LOG 10:11:10.256] Applying update TweakScale/Deprecating/patches/KIS_TweakScale 2/@PART[KIS_Container3] to KIS/Parts/container3/part.cfg/PART[KIS_Container3] [LOG 10:11:10.367] Applying update TweakScale/Deprecating/patches/KIS_TweakScale 3/@PART[KIS_Container3] to KIS/Parts/container3/part 2.cfg/PART[KIS_Container3] [LOG 10:11:10.367] Applying update TweakScale/Deprecating/patches/KIS_TweakScale 3/@PART[KIS_Container3] to KIS/Parts/container3/part.cfg/PART[KIS_Container3] [LOG 10:11:10.480] Applying update TweakScale/Deprecating/patches/KIS_TweakScale 4/@PART[KIS_Container3] to KIS/Parts/container3/part 2.cfg/PART[KIS_Container3] [LOG 10:11:10.481] Applying update TweakScale/Deprecating/patches/KIS_TweakScale 4/@PART[KIS_Container3] to KIS/Parts/container3/part.cfg/PART[KIS_Container3] [LOG 10:11:10.641] Applying update TweakScale/Deprecating/patches/KIS_TweakScale/@PART[KIS_Container3] to KIS/Parts/container3/part 2.cfg/PART[KIS_Container3] [LOG 10:11:10.642] Applying update TweakScale/Deprecating/patches/KIS_TweakScale/@PART[KIS_Container3] to KIS/Parts/container3/part.cfg/PART[KIS_Container3] [LOG 10:12:35.727] Applying update XyphosAerospace/Plugins/BuoyancyControl/BuoyancyControl 2/@PART[*] to KIS/Parts/container3/part 2.cfg/PART[KIS_Container3] [LOG 10:12:35.728] Applying update XyphosAerospace/Plugins/BuoyancyControl/BuoyancyControl 2/@PART[*] to KIS/Parts/container3/part.cfg/PART[KIS_Container3] [LOG 10:12:38.621] Applying update XyphosAerospace/Plugins/BuoyancyControl/BuoyancyControl/@PART[*] to KIS/Parts/container3/part 2.cfg/PART[KIS_Container3] [LOG 10:12:38.623] Applying update XyphosAerospace/Plugins/BuoyancyControl/BuoyancyControl/@PART[*] to KIS/Parts/container3/part.cfg/PART[KIS_Container3] [LOG 10:13:02.435] Applying update kOS/kOS-module-manager/@PART[*]:FOR[kOS] to KIS/Parts/container3/part 2.cfg/PART[KIS_Container3] [LOG 10:13:02.435] Applying update kOS/kOS-module-manager/@PART[*]:FOR[kOS] to KIS/Parts/container3/part.cfg/PART[KIS_Container3] But since only TweakScale complains, you think that only TweakScale has problems. I think you should reinstall everything from scratch. It will be easier and faster than trying to hunt every single rogue patch on your rig....

Considerably. Let's crack this nut: [LOG 18:55:40.295] [TweakScale] ERROR: **FATAL** Part KhiSP.SZ (KhiSP-SZ) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 18:55:40.298] [TweakScale] ERROR: **FATAL** Part KhiSP.SZ (KhiSP-SZ) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). It appears to be not that bad, just two fatalities... On the same part??? Boy, this is a new! Congrats! Double patching (i.e., patches being applied twice, rendering the part with two TweakScale sections) are common, but DOUBLED PART with DOUBLE PATCHING (each), this is a new! Well... Lets check what's happening: [LOG 18:48:08.196] DragCubeSystem: Creating drag cubes for part 'KhiSP.SZ' [LOG 18:48:23.726] DragCubeSystem: Creating drag cubes for part 'KhiSP.SZ' [LOG 18:55:40.295] [TweakScale] WARNING: **FATAL** Found a showstopper problem on KhiSP.SZ (KhiSP-SZ). [LOG 18:55:40.295] [TweakScale] ERROR: **FATAL** Part KhiSP.SZ (KhiSP-SZ) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 18:55:40.298] [TweakScale] WARNING: **FATAL** Found a showstopper problem on KhiSP.SZ (KhiSP-SZ). [LOG 18:55:40.298] [TweakScale] ERROR: **FATAL** Part KhiSP.SZ (KhiSP-SZ) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 18:55:48.388] [Filter Extensions 3.2.0.3]: KhiSP.SZ duplicated part key in part path dictionary Hummm No joy. This is every mention of "KhiSP.SZ" on your log. We can see two lines about creating drag cubes for the part (when there should be only one). The last line also pinpoints the problem, Filter Extensions are also complaining about. However... I just remembered that dots on the name became underscores on patches! This is the reason the first log excerpt didn't have any mention for the part being loaded and patched! (I'm getting old! :P) so, let's try again: [LOG 18:46:10.961] Load(Model): Contares/Parts/SolarPanel/KhiSP_SZ [LOG 18:46:12.415] Load(Model): Contares_KHI/Parts/KhiNa/KhiSP_SZ [LOG 18:47:56.165] Config(PART) Contares/Parts/SolarPanel/KhiSP_SZ/KhiSP_SZ [LOG 18:47:56.170] Config(@PART[KhiSP_SZ]) Contares/Patches/Contares_CORE_TweakScale/@PART[KhiSP_SZ] [LOG 18:47:56.177] Config(PART) Contares_KHI/Parts/KhiNa/KhiSP_SZ/KhiSP_SZ [LOG 18:47:56.178] Config(@PART[KhiSP_SZ]) Contares_KHI/Patches/CONTARES_KHI_TweakScale/@PART[KhiSP_SZ] [LOG 18:43:10.047] Applying update Contares/Patches/Contares_CORE_TweakScale/@PART[KhiSP_SZ] to Contares/Parts/SolarPanel/KhiSP_SZ.cfg/PART[KhiSP_SZ] [LOG 18:43:10.047] Applying update Contares/Patches/Contares_CORE_TweakScale/@PART[KhiSP_SZ] to Contares_KHI/Parts/KhiNa/KhiSP_SZ.cfg/PART[KhiSP_SZ] [LOG 18:43:10.685] Applying update Contares_KHI/Patches/CONTARES_KHI_TweakScale/@PART[KhiSP_SZ] to Contares/Parts/SolarPanel/KhiSP_SZ.cfg/PART[KhiSP_SZ] [LOG 18:43:10.685] Applying update Contares_KHI/Patches/CONTARES_KHI_TweakScale/@PART[KhiSP_SZ] to Contares_KHI/Parts/KhiNa/KhiSP_SZ.cfg/PART[KhiSP_SZ] [LOG 18:43:51.019] Applying update WarpPlugin/Patches/SolarPanels/@PART[*]:HAS[@MODULE[ModuleDeployableSolarPanel]:HAS[#chargeRate[>0]]]:FOR[WarpPlugin] to Contares/Parts/SolarPanel/KhiSP_SZ.cfg/PART[KhiSP_SZ] [LOG 18:43:51.028] Applying update WarpPlugin/Patches/SolarPanels/@PART[*]:HAS[@MODULE[ModuleDeployableSolarPanel]:HAS[#chargeRate[>0]]]:FOR[WarpPlugin] to Contares_KHI/Parts/KhiNa/KhiSP_SZ.cfg/PART[KhiSP_SZ] [LOG 18:44:02.813] Applying update B9PartSwitch/CopyEventsPropagator/@PART:FOR[zzzzzz-B9PartSwitch] to Contares/Parts/SolarPanel/KhiSP_SZ.cfg/PART[KhiSP_SZ] [LOG 18:44:02.839] Applying update B9PartSwitch/CopyEventsPropagator/@PART:FOR[zzzzzz-B9PartSwitch] to Contares_KHI/Parts/KhiNa/KhiSP_SZ.cfg/PART[KhiSP_SZ] [LOG 18:44:03.923] Applying update InterstellarFuelSwitch/PatchManager/ActiveMMPatches/IntegratedDecoupler/@PART[*]:FINAL to Contares/Parts/SolarPanel/KhiSP_SZ.cfg/PART[KhiSP_SZ] [LOG 18:44:03.942] Applying update InterstellarFuelSwitch/PatchManager/ActiveMMPatches/IntegratedDecoupler/@PART[*]:FINAL to Contares_KHI/Parts/KhiNa/KhiSP_SZ.cfg/PART[KhiSP_SZ] [LOG 18:44:06.626] Applying update WarpPlugin/Patches/OreTanksFix/@PART[*]:FINAL to Contares/Parts/SolarPanel/KhiSP_SZ.cfg/PART[KhiSP_SZ] [LOG 18:44:06.660] Applying update WarpPlugin/Patches/OreTanksFix/@PART[*]:FINAL to Contares_KHI/Parts/KhiNa/KhiSP_SZ.cfg/PART[KhiSP_SZ] [LOG 18:48:08.160] PartLoader: Compiling Part 'Contares/Parts/SolarPanel/KhiSP_SZ/KhiSP_SZ' [LOG 18:48:08.189] PartLoader: Part 'Contares/Parts/SolarPanel/KhiSP_SZ/KhiSP_SZ' has no database record. Creating. [LOG 18:48:23.690] PartLoader: Compiling Part 'Contares_KHI/Parts/KhiNa/KhiSP_SZ/KhiSP_SZ' [LOG 18:48:23.719] PartLoader: Part 'Contares_KHI/Parts/KhiNa/KhiSP_SZ/KhiSP_SZ' has no database record. Creating. Gotcha! You have two parts with the same name on two different directories: [LOG 18:46:10.961] Load(Model): Contares/Parts/SolarPanel/KhiSP_SZ [LOG 18:46:12.415] Load(Model): Contares_KHI/Parts/KhiNa/KhiSP_SZ .... [LOG 18:47:56.165] Config(PART) Contares/Parts/SolarPanel/KhiSP_SZ/KhiSP_SZ [LOG 18:47:56.170] Config(@PART[KhiSP_SZ]) Contares/Patches/Contares_CORE_TweakScale/@PART[KhiSP_SZ] [LOG 18:47:56.177] Config(PART) Contares_KHI/Parts/KhiNa/KhiSP_SZ/KhiSP_SZ [LOG 18:47:56.178] Config(@PART[KhiSP_SZ]) Contares_KHI/Patches/CONTARES_KHI_TweakScale/@PART[KhiSP_SZ] And each part is being double patched because there're two sets of patches being applied to each one. There's something on Contares_KHI in need to be fixed, I think, as the Contares Core should have precedence. Another possibility is that Contares Core "donated" a part to KHI (or vice versa), and when you updated, you didn't deleted the old files, and so a rogue oldie was left behind playing havoc. Delete completely Contares and Contares_KHI and see if the double patching on doubled parts vanishes. If this fixes your problem, it was a mishap on the installation. If the problem is still there, you will need to reach Contares and/or Contares KHI maintainer and submit a bug report. (Contares KHI is another new for me, I didn't knew it!) Cheers.

(moved from the wrong thread!) Yep. There's TweakScale, the MODULE, and there's TweakScale, the "stock" Patches. It's not Module's fault, it is doing exactly what it's being told to do. I'm "teaching" it to detect some bugs, but there's a limit on what can be done automatically. About the Patches…Well. Some of the problems are on me. Some of the TweakScale stock patches have the problem too, and to tell you the true I completely forgot to check my own patches before doing the release. Until the moment, not a single report was due only the Stock Patches, but yet they are there. On my defense only my Career game (still on 1.4.3 , the mainstream version on the last time I really played) detected these problems now that I fired up with the newest TweakScaçe, but as I said, it's more exactly ONE YEAR since I fire up it since the last time!!! (dude, it was running one of my first "unofficial" compilations of TweakScale yet!) Somewhere else on this forum I said that would be a good idea having more developers playing more the game in order to foresee in advance some possible consequences about the decisions they make. Guess what? It applies perfectly to me too. Once TweakScale 2.5 goes gold (the Milestone I'm slowly pursuing through the 2.4.* series) I will take a break on this and go back to my Career. No Kerbal should be dragged away from his game for that time! There's a possible compromise on this. Until the moment, almost every single rogue patch was trying to "overcome" the default behaviour. These ones, once everything is fixed, will still be the dominant ones - with the additional benefit of not risking ruining games when Add'Ons are installed, updated or even removed - destabilising the brittle balance that is allowing things to work at the moment. There're some others that are applying the same patch twice. These ones are 'almost' harmless - but since they are applying themselves twice, they will be being applied twice even if something else tries to overrule them. And then we would have a new instance of the last problem. The nastiest problems, however, is when different patches are applied by error on the same part. This is a serious game braker because these patches are not only changing things in a unattended way (the others were doing it on purpose to get a new, predefined behaviour), ruining the current game, but they also are "vengeful" as they also ruin the game when things are fixed! This is not safe, as some rogue patches ends up acting only under determined circumstances. Anything gets different, the savegame is ruined as the brittle balance that were reached is broken and the chain ends up with different results. So we need a set of deterministic, custom made patches, that would allow these savegames to carry on without being at risk. This is the reason I'm asking people to send me their KSP.log and MM ConfigCaches - to be able to detect if these Doomsday scenarios will be a reality and then, when the TweakScale 2.4.3.1 is issued, I will be able to provide custom parches that would mangle the parts back to the wrong behaviour (saving the game), but without the risk of things going through the tubes due rogue patches going straight.or something. EXACTLY!! Backup everything and kick my up. Once I detect exactly where thing are wrong, I can handcraft a patch that would "break things again", but this time in a deterministic and safe way. What makes me think that I should "mark" these parts somehow and tell TweakScale to remember the user, regularly, that he doesn't should start new games using that installment. Good brainstorming, @zer0Kerbal . This is what the good software feed on! Thanks!

Humm. Interesting. I tested it before publishing the stunt... Humm... I think I downloaded the wrong Add'On then? You see, there's an Add"On called ModRocketSysLite and it is double patching the very same parts... (hacking into your KSP log) Yeah. Working late night can be dangerous, by plain lack of luck, Google should had given me ModRocketSysLite when I typed ModRocketSys and I just didn't paid enough attention. Found it here. Oh well... Look on the bright side: you are learning your way on patching : you detected and fixed a mistake of mine! Yes, it worked. I forgot to mention that you will still get the TweakScaleRogue stunt on crafts and savegames already saved, but once you save them again the HotFix will prevent the new crafts to have the Rogue TweakScale section, and by then the problem is solved. However... THAT is something new... I just removed a deactivated copy of the TweakScale section on the GameDatabase - and so, TweakScale didn't found anymore a second copy of it on the part, and so it didn't deactivated it by brute force on saving crafts and savegames. I made this way because, as you probably is getting aware, if someone install a new Add'On those name come first on the alphabetical order, and this Add'On rogue patches an already in use part, then the SECOND COPY of TweakScale would be the one that should be preserved. Doing the way I did at least allows me to manually fix a savegame by removing the first copy and reactivating the second one (and this is just one more reason to use S.A.V.E.!). However... What you describes is something completely... Awkward. Removing all copies TweakScale support and then shoving back the first one (that is the one your game was using) should not cause this breakage - unless there's something else changing it and I didn't caught it - it was late night, and I already missed an detail, so I can be did missed another one. You would accomplish by "hardware" what the HotFix does by "software". Essentially: ModRocketSys (Lite or not) applies a 'hard' patch for TweakScale on two parts from SpaceY SpaceY correctly applies a 'hard patch' on these two parts again Correctly because it owns that parts - the owner applies a 'hard' patch, everybody else applies 'soft' patches. The HotFix deletes the previous two patches, and reapply a hard patch mimicking the one ModRocketSys applied And the aftermath is that you have a "sane" GameDatabase where the "rogue patch infection" is not spreaded anymore on crafts and savegames - what would be the exact result you will get by manually deleting one of the copies of the patches. The HotFix aims to allow you a sane GameDatabase without having to edit third parties patches (what would be nullified on each Add'On update). Of course, it worths a try (really, make backups of everything). But I can foresee two possible results: you edit the patch, things explodes the same, and we end up confused about the reason of the explosion you edit the patch, things work fine, and we ended up confused about the reason the HotFix (allegedly) caused the explosion Allegedly because something else could had happened by coincidence (or by side effect), and perhaps we have a new problem do diagnose! In a way or another, I'm giving a second look on your case. I'm puzzled about it, there's something else happening where I can't see. -- -- -- POST EDIT -- -- -- I think I found something.... This is the patch for SYejectatron on Space-Y: @PART[SYejectatron]:NEEDS[TweakScale] // super-sized sepratron { MODULE { name = TweakScale type = surface } } And this is the patch for it on ModRocketSys (Lite or not): @PART[SYejectatron]:NEEDS[TweakScale] // super-sized sepratron { #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { } MODULE { name = TweakScale type = surface } } And that behaviour changes something - only the mass exponent, but changes something. It still doesn't explains the textures being blown up, however. I updated the hotfix to cope with that, by the way. I'm still working on it.

Oh, well.. So this one is not my fault after all. Damn. Keep that instalment for debugging purposes, if you want. It will help a lot to tackle down this pesky bug. Until the moment, I have no evidences that this could be dangerous for you, but at least once I forced a situation on my test bed where the rogue patch would be inserted before the rightful one on a ongoing savegame, and this tricks TweakScale into thinking the good one is the rogue. Let's give this a new shot: [LOG 00:25:10.145] Applying update FuelTanksPlus/Patch-1.9.1/@PART[*]:NEEDS[FuelTanksPlus] to SpaceY-Lifters/Parts/Decouplers/SYdecouplerRadial/SYdecouplerRadial1.cfg/PART[SYdecouplerRadial1] [LOG 00:25:10.511] Applying update ModRocketSysLite/Patches/MRS_TweakScale/@PART[SYdecouplerRadial1]:NEEDS[TweakScale] to SpaceY-Lifters/Parts/Decouplers/SYdecouplerRadial/SYdecouplerRadial1.cfg/PART[SYdecouplerRadial1] [LOG 00:25:10.889] Applying update SpaceY-Lifters/Patches/0_TechTree/@PART[SY*]:NEEDS[!CommunityTechTree&!HPTechTree] to SpaceY-Lifters/Parts/Decouplers/SYdecouplerRadial/SYdecouplerRadial1.cfg/PART[SYdecouplerRadial1] [LOG 00:25:10.927] Applying update SpaceY-Lifters/Patches/SpaceY_TweakScale/@PART[SYdecouplerRadial1]:NEEDS[TweakScale] to SpaceY-Lifters/Parts/Decouplers/SYdecouplerRadial/SYdecouplerRadial1.cfg/PART[SYdecouplerRadial1] [LOG 00:25:19.907] Applying update BetterBurnTime/SRBurnTime/@PART[*]:HAS[@RESOURCE[SolidFuel],@MODULE[ModuleEngines]:HAS[@PROPELLANT[SolidFuel]]]:FINAL to SpaceY-Lifters/Parts/Decouplers/SYdecouplerRadial/SYdecouplerRadial1.cfg/PART[SYdecouplerRadial1] [LOG 00:25:20.084] Applying update InterstellarFuelSwitch/PatchManager/ActiveMMPatches/IntegratedDecoupler/@PART[*]:FINAL to SpaceY-Lifters/Parts/Decouplers/SYdecouplerRadial/SYdecouplerRadial1.cfg/PART[SYdecouplerRadial1] [LOG 00:25:20.407] Applying update PartInfo/PartInfo/@PART[*]:Final to SpaceY-Lifters/Parts/Decouplers/SYdecouplerRadial/SYdecouplerRadial1.cfg/PART[SYdecouplerRadial1] So yeah, it's still our friends MRS_TweakScale and SpaceY_TweakScale stomping each other toes. Humm... On a second thought... Perhaps it is my fault... Try this hot-fix again (save it using the Raw button into GameData/__LOCAL/TweakScale/HotFixes directory). If I'm right, the Rogue Duplicated will vanish this time with the newest release. -- -- Link to my previous attempt on this here. Link to my first attempt here.

Got it! [LOG 11:06:03.821] [TweakScale] INFO: WriteDryCost Concluded : 4913 parts found ; 3 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 27 Show Stoppers found; 47 Sanity Check failed; 47 unscalable parts. Yep. We have a little mess here, and a pretty huge installment to check on! (pretty good rig, by the way!). Let's check first the 27 FATALities first, as this I can fix for you (most of the time). All of them are about duplicated properties, what means rogue patching. One of the double patchers is Contares, already known issue by the way: [LOG 10:39:51.789] Applying update Contares/Patches/CONTARES_TweakScale/@PART[truss-octo-*] to NearFutureConstruction/Parts/Truss/truss-octo/truss-octo-hub-crew-01.cfg/PART[truss-octo-hub-crew-01] [LOG 10:40:20.518] Applying update TweakScale/patches/NF/NFC_TweakScale/@PART[truss-octo-hub-crew-01] to NearFutureConstruction/Parts/Truss/truss-octo/truss-octo-hub-crew-01.cfg/PART[truss-octo-hub-crew-01] Installing TweakScale Companion for NF will solve that, because on the Companion I decided to force my way on things and that's it. I am the TweakScale guy, after all. But Contares is also patching some parts not touched by TweakScale: [LOG 10:39:51.408] Applying update Contares/Patches/CONTARES_TweakScale/@PART[A1-44_FIN] to Contares_MEU/Parts/A5/A1-44_FIN.cfg/PART[A1-44_FIN] [LOG 10:39:51.877] Applying update Contares_MEU/Patches/Contares_MEU_TweakScale/@PART[A1-44_FIN]:NEEDS[TweakScale] to Contares_MEU/Parts/A5/A1-44_FIN.cfg/PART[A1-44_FIN] And this is beyound me to fix. But we can at least minimize the damage: The fix is still the same from the last one: Install THIS version (0.0.3.2) of the TweakScale Companion for NF. If you are creating new games, you can use the latest one (0.0.4.0) - but only for new savegames This is needed because some scaling rules were fixed, and only TweakScale 2.4.4 (and the TS 2.5. beta) knows how to overcome KSP on some 'automatic savegame updating' thingies that ended up stomping TweakScale toes on the matter. Once TS 2.4.4 is on the wild, you can update to the newest 0.0.4 without fear Delete the file Contares/Patches/CONTARES_TweakScale.cfg . I don't know if this is a left-over from an old version that you forgot while updating, or if it's the same old bug from Contares still not fixed. But removing this file will save you a lot of double patching. But I don't know about any other patching this file is applying. You should ask for directions on the Contares Thread. Let me know if I can help you on something else. Cheers! -- -- -- P.S.: may I suggest to remove the log snippets from your post? Not only they are useless now that you posted the full log, but they also hinder a bit the search engine. I post some log snippets on my posts to have them indexed to a solution, and when there are such snippets on the bug report it makes things a bit more confusing while searching the "Knowledge Base"!

Wow! 69 FATALities. Almost as bad as one installment of mine, that got 172. [LOG 09:10:25.892] [TweakScale] INFO: WriteDryCost Concluded : 2443 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 69 Show Stoppers found; 9 Sanity Check failed; 1065 unscalable parts. On the bright side, you have only 9 Sanity fails, and these 9 are due lack of proper support - no worries, these will be tacked down soon. That 1065 unscalable parts are parts without TweakScale (including that 9), from a pool of 2443 parts on the GameDatabase. This is just informational, so you know that about 43% of your inventory is not scalable. Nows, let's check that 69 victims: [LOG 09:10:25.752] [TweakScale] ERROR: **FATAL** Part truss-octo-01 (Octo-Girder Modular Truss XL) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.752] [TweakScale] ERROR: **FATAL** Part truss-octo-02 (Octo-Girder Modular Truss) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.753] [TweakScale] ERROR: **FATAL** Part truss-octo-03 (Octo-Girder Modular Truss Mini) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.753] [TweakScale] ERROR: **FATAL** Part truss-octo-04 (Octo-Girder Modular Truss Micro) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.753] [TweakScale] ERROR: **FATAL** Part truss-octo-adapter-01 (Octo-Girder Modular Adapter) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.753] [TweakScale] ERROR: **FATAL** Part truss-octo-adapter-crew-01 (Octo-Girder Pressurized Adapter) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.754] [TweakScale] ERROR: **FATAL** Part truss-octo-angled-01 (Octo-Girder Modular Angular Connector) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.754] [TweakScale] ERROR: **FATAL** Part truss-octo-angled-crew-01 (Octo-Girder Pressurized Angular Connector) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.754] [TweakScale] ERROR: **FATAL** Part truss-octo-attach-01 (Octo-Girder Radial Attach Node) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.755] [TweakScale] ERROR: **FATAL** Part truss-octo-crew-01 (Octo-Girder Pressurized Truss XL) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.755] [TweakScale] ERROR: **FATAL** Part truss-octo-crew-02 (Octo-Girder Pressurized Truss) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.756] [TweakScale] ERROR: **FATAL** Part truss-octo-crew-03 (Octo-Girder Pressurized Truss Mini) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.756] [TweakScale] ERROR: **FATAL** Part truss-octo-docking-125 (Octo-Girder Docking Connector) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.756] [TweakScale] ERROR: **FATAL** Part truss-octo-docking-25 (Octo-Girder Heavy Docking Connector) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.757] [TweakScale] ERROR: **FATAL** Part truss-octo-docking-octo (Octo-Girder Octagonal Docking Connector) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.757] [TweakScale] ERROR: **FATAL** Part truss-octo-drone-01 (Octo-Girder Guidance Unit) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.758] [TweakScale] ERROR: **FATAL** Part truss-octo-hub-01 (Octo-Girder Modular Hub) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.758] [TweakScale] ERROR: **FATAL** Part truss-octo-hub-crew-01 (Octo-Girder Pressurized Hub) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.849] [TweakScale] ERROR: **FATAL** Part Decoupler.1p5 (TD-18 Decoupler) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.849] [TweakScale] ERROR: **FATAL** Part Decoupler.4 (TD-50 Decoupler) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.850] [TweakScale] ERROR: **FATAL** Part Separator.1p5 (TS-18 Stack Separator) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.850] [TweakScale] ERROR: **FATAL** Part Separator.4 (TS-50 Stack Separator) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.851] [TweakScale] ERROR: **FATAL** Part Size1p5.Strut.Decoupler (Size 1.5 Decoupler) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.852] [TweakScale] ERROR: **FATAL** Part LiquidEngineKE-1 (Kerbodyne KE-1 "Mastodon" Liquid Fuel Engine) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.852] [TweakScale] ERROR: **FATAL** Part LiquidEngineLV-T91 (LV-T91 "Cheetah" Liquid Fuel Engine) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.853] [TweakScale] ERROR: **FATAL** Part LiquidEngineLV-TX87 (LV-TX87 "Bobcat" Liquid Fuel Engine) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.854] [TweakScale] ERROR: **FATAL** Part LiquidEngineRE-I2 (RE-I2 "Skiff" Liquid Fuel Engine) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.855] [TweakScale] ERROR: **FATAL** Part LiquidEngineRE-J10 (RE-J10 "Wolfhound" Liquid Fuel Engine) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.856] [TweakScale] ERROR: **FATAL** Part LiquidEngineRK-7 (RK-7 "Kodiak" Liquid Fueled Engine) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.857] [TweakScale] ERROR: **FATAL** Part LiquidEngineRV-1 (RV-1 "Cub" Vernier Engine) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.857] [TweakScale] ERROR: **FATAL** Part monopropMiniSphere (Stratus-V Minified Monopropellant Tank) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.857] [TweakScale] ERROR: **FATAL** Part Size1p5.Monoprop (FL-R5 RCS Fuel Tank) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.857] [TweakScale] ERROR: **FATAL** Part Size1p5.Size0.Adapter.01 (FL-A150 Fuel Tank Adapter) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.858] [TweakScale] ERROR: **FATAL** Part Size1p5.Size1.Adapter.01 (FL-A151L Fuel Tank Adapter) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.858] [TweakScale] ERROR: **FATAL** Part Size1p5.Size1.Adapter.02 (FL-A151S Fuel Tank Adapter) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.858] [TweakScale] ERROR: **FATAL** Part Size1p5.Size2.Adapter.01 (FL-A215 Fuel Tank Adapter) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.858] [TweakScale] ERROR: **FATAL** Part Size1p5.Tank.01 (FL-TX220 Fuel Tank) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.859] [TweakScale] ERROR: **FATAL** Part Size1p5.Tank.02 (FL-TX440 Fuel Tank) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.859] [TweakScale] ERROR: **FATAL** Part Size1p5.Tank.03 (FL-TX900 Fuel Tank) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.859] [TweakScale] ERROR: **FATAL** Part Size1p5.Tank.04 (FL-TX1800 Fuel Tank) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.860] [TweakScale] ERROR: **FATAL** Part Size1p5.Tank.05 (FL-C1000 Fuel Tank) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.860] [TweakScale] ERROR: **FATAL** Part Size3.Size4.Adapter.01 (Kerbodyne S3-S4 Adapter Tank) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.860] [TweakScale] ERROR: **FATAL** Part Size4.EngineAdapter.01 (Kerbodyne Engine Cluster Adapter Tank) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.860] [TweakScale] ERROR: **FATAL** Part Size4.Tank.01 (Kerbodyne S4-64 Fuel Tank) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.860] [TweakScale] ERROR: **FATAL** Part Size4.Tank.02 (Kerbodyne S4-128 Fuel Tank) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.861] [TweakScale] ERROR: **FATAL** Part Size4.Tank.03 (Kerbodyne S4-256 Fuel Tank) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.861] [TweakScale] ERROR: **FATAL** Part Size4.Tank.04 (Kerbodyne S4-512 Fuel Tank) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.861] [TweakScale] ERROR: **FATAL** Part roverWheelM1-F (RoveMax M1-F Rover Wheel) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.861] [TweakScale] ERROR: **FATAL** Part Size1to0ServiceModule (SM-6A Service Module) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.862] [TweakScale] ERROR: **FATAL** Part ServiceModule18 (SM-18 Service Module) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.862] [TweakScale] ERROR: **FATAL** Part ServiceModule25 (SM-25 Service Module) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.862] [TweakScale] ERROR: **FATAL** Part kv1Pod (KV-1 'Onion' Reentry Module) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.863] [TweakScale] ERROR: **FATAL** Part kv2Pod (KV-2 ‘Pea’ Reentry Module) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.864] [TweakScale] ERROR: **FATAL** Part kv3Pod (KV-3 'Pomegranate' Reentry Module) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.864] [TweakScale] ERROR: **FATAL** Part Mk2Pod (Mk2 Command Pod) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.865] [TweakScale] ERROR: **FATAL** Part MEMLander (Munar Excursion Module (M.E.M.)) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.865] [TweakScale] ERROR: **FATAL** Part EquiTriangle0 (SP-T06 Structural Panel) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.866] [TweakScale] ERROR: **FATAL** Part EquiTriangle1 (SP-T12 Structural Panel) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.866] [TweakScale] ERROR: **FATAL** Part EquiTriangle1p5 (SP-T18 Structural Panel) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.866] [TweakScale] ERROR: **FATAL** Part EquiTriangle2 (SP-T25 Structural Panel) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.866] [TweakScale] ERROR: **FATAL** Part Panel0 (SP-S06 Structural Panel) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.867] [TweakScale] ERROR: **FATAL** Part Panel1 (SP-S12 Structural Panel) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.867] [TweakScale] ERROR: **FATAL** Part Panel1p5 (SP-S18 Structural Panel) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.867] [TweakScale] ERROR: **FATAL** Part Panel2 (SP-S25 Structural Panel) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.867] [TweakScale] ERROR: **FATAL** Part Triangle0 (SP-R06 Structural Panel) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.868] [TweakScale] ERROR: **FATAL** Part Triangle1 (SP-R12 Structural Panel) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.868] [TweakScale] ERROR: **FATAL** Part Triangle1p5 (SP-R18 Structural Panel) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.868] [TweakScale] ERROR: **FATAL** Part Triangle2 (SP-R25 Structural Panel) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 09:10:25.869] [TweakScale] ERROR: **FATAL** Part HeatShield1p5 (Heat Shield (1.875m)) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). All that "truss" problems are old news. It's Contares. [LOG 08:52:37.306] Applying update Contares/Patches/CONTARES_TweakScale/@PART[truss-octo-*] to NearFutureConstruction/Parts/Truss/truss-octo/truss-octo-03.cfg/PART[truss-octo-03] [LOG 08:53:12.070] Applying update TweakScale/patches/NFT_TweakScale/@PART[truss-octo-03] to NearFutureConstruction/Parts/Truss/truss-octo/truss-octo-03.cfg/PART[truss-octo-03] [LOG 08:54:34.286] Applying update B9PartSwitch/PartInfo/@PART[*]:HAS[@MODULE[ModuleB9PartSwitch]]:FOR[zzzzzz-B9PartSwitch] to NearFutureConstruction/Parts/Truss/truss-octo/truss-octo-03.cfg/PART[truss-octo-03] [LOG 08:54:35.569] Applying update Kopernicus/Config/SolarPanels/@PART:FINAL to NearFutureConstruction/Parts/Truss/truss-octo/truss-octo-03.cfg/PART[truss-octo-03] This was already detected and fixed here. And the latest TweakScale has already the HotFix on the distribution file. TL;DR: Contares problems can be fixed are follows: Download (click on the Raw button) or extract from the distribution file the TweakScale/Extras/TweakScale/HotFixes/Contares--TweakScale.cfg file. Move it into some place on your KSP installment. Be sure to remember where, as you would want to delete it once the Add'Ons maintainers fix the problem. I suggest to use GameData/__LOCAL/TweakScale/HotFixes/ Every time you update Contares, you will need to check if this HotFix is still needed. HotFixes brute force their way into the GameDatabase, and if Contares make any fix on it patches, they will be trashed in favor of the HotFix. Well, this solves 18 issues at once. Now let's check the others. Let's check Decoupler_1p5. [LOG 08:53:42.020] Applying update TweakScale/patches/SquadExpansion/MakingHistory/Coupling/@PART[Decoupler_1p5] to SquadExpansion/MakingHistory/Parts/Coupling/Decoupler_1p5.cfg/PART[Decoupler_1p5] [LOG 08:53:43.334] Applying update TweakscaleMakingHistoryConfigs/Coupling/@PART[Decoupler_1p5] to SquadExpansion/MakingHistory/Parts/Coupling/Decoupler_1p5.cfg/PART[Decoupler_1p5] [LOG 08:53:51.497] Applying update EngineLight/decoupler-configs/@PART[*]:HAS[@MODULE[Module*Decouple*]]:FOR[EngineLight] to SquadExpansion/MakingHistory/Parts/Coupling/Decoupler_1p5.cfg/PART[Decoupler_1p5] [LOG 08:54:36.089] Applying update Kopernicus/Config/SolarPanels/@PART:FINAL to SquadExpansion/MakingHistory/Parts/Coupling/Decoupler_1p5.cfg/PART[Decoupler_1p5] Well… There's a lot of people patching Decoupler_1p5. This i not necessarily bad, as only double patching TweakScale is surely known to lead to problems. So we have to inspect every patch, what is a but worksome. I will try to cut some work by inspecting the ConfigCache instead, with luck I can trace the source of the double patching inspecting the part directly: UrlConfig { parentUrl = SquadExpansion/MakingHistory/Parts/Coupling/Decoupler_1p5.cfg PART { name = Decoupler_1p5 <CUT> MODULE { name = TweakScale type = stack defaultScale = 1.875 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 type = stack defaultScale = 1.875 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 TWEAKSCALEEXPONENTS { name = TweakScale DryCost = 0.5 mass = 2 } } MODULE { name = TweakScale TWEAKSCALEEXPONENTS { name = TweakScale DryCost = 0.5 mass = 2 } } MY GOD!! It's full of double patches!!!! Well… Congrats. This is the worst patching I ever saw. There's at least THREE guys shoving patches into this part, one of them is TweakScale default patches. On the bright side, this is one of the benign kind of rogue patching - everybody is shoving the same data into the part, so don't reaaly matter what the datum being used. At least that. The first and obvious one is TweakscaleMakingHistoryConfigs (and yeah, an illustrious unknown). Delete GameDatabase/TweakscaleMakingHistoryConfigs . I Don't know what is it, and who is still recommending to use it, and frankly, by this time, I strongly recommend to avoid using anything from someone that still tells you to use this thing for the following reasons: It's not available anywhere, I can't find a source for downloading it. So I can't inspect it. I don't have a clue about what is this stunt! So it doesn`t complies with Forum Rules for Add`Ons It's almost a year that TweakScale actively supports Making History from the default installation files. It's long the time this thing were necessary. I once found a download link from Spacedock, but that entry was deleted from the site. Don't have a clue when. I'm pretty sure there was a time that this patch was needed. But it's way long in the past already. We found one, two more to go. Let's check EngineLight. Simple mod (nice one!!!), and its patches doesn't touches TweakScale. INNOCENT #ghostRiderFeelings. Now let's see Kopernicus. I failed to understand why this is patching a Decoupler, but since this doesn't touch TweakScale neither, it's not the problem. Well, I ran out of suspects. Only TweakscaleMakingHistoryConfigs appears to be playing a role on this. Since I counted 60 entries on the FATALities mentioning it, I'm pretty sure that by bluntly deleting GameData/TweakscaleMakingHistoryConfigs your installment should be fine. If anything bad still remains, publish the new KSP.log and ModuleManager.ConfigCache here and I will look on it.! Scale Safe! Uh… I think I didn't explained correctly how to write the patch. Sorry. @PART[S2Structural]:FINAL { -MODULE[TweakScale],* { } } Get rid of the < and > . It was meant to denote something not literal - but sometimes I forget most people here are not techie guys, and from the ones that are, most of them are not die hard UNIX freaks as me (where I got used to this notation). I will fix the original post too. UUGH… I also forgot an opening brace!! (the first one below :FINAL). Sorry!

ANNOUNCE Release 2.4.5.0 is available for downloading, with the following changes: Adds two Module attributes to allow granular control, part by part, of TweakScale behaviour, allowing it to be deactivated at user’s choice, or even made unavailable without the need to deinstall TweakScale (and then screwing up savegames) Intended to make easier to take party on Challenges where TweakScale is not allowed Also allows Challenges to easily ban TweakScale only on some parts by patches (or even code). Issues Fixed: #172 Wait for KSPe bug #10 Some interesting installment checks were updated on KSPe, and the respective KSPe Light for TweakScale was updated with them. #170 Add ‘active’ and ‘available’ properties See OP for the links. Highlights Standard mechanism to control TweakScale availability From 2.4.5.0 and up, it’s possible to deactivate TweakScale on some (or even all) parts by patching or on the user interface without affecting living crafts on the savegame (or even already existent craft files). A patching only feature can lock up TweakScale on the current state, making easier to create artefacts to automatically reconfigure a savegame for Challenges with specific rules. Again, without affecting existent crafts or savegames - once the craft is launched, it’s not affected by these options. See the Documentation for details. Formal support for KSP from 1.4.4 to 1.11 KSP 1.11 didn’t introduced any changes that break TweakScale, so it’s formally supported. However, in order to proper support Variants, the minimal KSP version supported by now is 1.4.4 . Sorry for that. TweakScale 2.5 aims to bring back support for KSP down to 1.2.2 (exactly how, is still work in progress, but it’s feasible as being demonstrated by some Unofficial forks of mine). Parts with Variants Variants that change Cost and/or Nass are now fully supported, but TweakScale is struggling to support Parts with Variants that changes Attachment Nodes. I had planned to withdraw TweakScale support from such parts as I did in the past, but then I realised that most Version 2 parts from already scalable parts (as Terrier…) would had TweakScale withdrawn, and this would render some crafts and savegames corrupted. Since most of these parts didn’t misbehave on a noticeable way, I decided to just let it go as is for while. Just a few stock parts are misbehaving into a noticeable way, and these parts are (until the moment): The Mastodon engine The Structural Tubes T-12 T-18 T-25 T-37 T-50 And probably more, as Add'Ons starts to use such feature. The only workaround at the moment is to descale these parts before applying the variant and then scaling them again. Alternatively, just detach and reattach the misbehaving parts. A proper fix is Work in Progress, and is expected to be released on 2.4.4.1. Deprecating Patches Support for all non Squad parts are on a deprecating status and will be definitively removed on TweakScale 2.5. The TweakScale Companion Program will be the source for supporting third-parties add'ons. It’s advised to install the needed Companions as they reach Gold status. Sanity Checks Parts using Firespitter’s FSbuoyancy needs the latest TweakScale Companion for Firespitter, as only the Companion has the specific code that knows how to handle it. Overrules A overrule, as the name says, is a patch the overrules TweakScale (and anything else) in order to make things broken in a deterministic way. A complete essay can be found here. Hot Fixes A Hot Fix is a hand crafted patch that fixes by brute force patching problems, forcing the original intended result for a given KSP installment. The difference from an overrule is that Hot Fixes don’t break compatibility with sane installments, so you can start new savegames and share your crafts without worries. A complete essay can be found here. New Scaling Behaviour A new TWEAKSCALEBEHAVIOUR, ModuleGeneratorExtended , is available for parts using ModuleGenerator that wants to scale the INPUT_RESOURCES too. This feature wasn’t introduced directly into the ModuleGenerator’s TWEAKSCALEEXPONENTS to prevent damage on Add'Ons (and savegames) that rely on the current behaviour (scaling only the output), as suddenly the resource consumption would increase on already stablished bases and crafts. Just add the lines as the example below (the output resources scaling is still inherited from the default patch!). @PART[my_resource_converter]:NEEDS[TweakScale] { #@TWEAKSCALEBEHAVIOR[ModuleGeneratorExtended]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = free } } WARNINGS The known Unholy interaction between modules (Kraken Food), rogue patches or known incompatibilities between third parties Add'On that can lead to disasters are being detected on the Sanity Checks with a proper (scaring) warning being shown. A full essay about these issues can be found here. Unfortunately, such issues are a serious Show Stopper, potentially (and silently) ruining your savegames. This is not TweakScale fault, but yet it’s up to it to detect the problem and warn you about it. If this happens with you, call for help. A Cancel button is available for the brave Kerbonauts willing to fly unsafe. TweakScale strongly recommends using S.A.V.E.. Special procedures for recovering mangled installments once the TweakScale are installed (triggering the MM cache rebuilding) are possible, but keep your savegames backed up. And DON`T SAVE your crafts once you detect the problem. Reach me on Forum for help. TweakScale stills mangles further affected crafts and savegames with some badly (but recoverable) patched parts so when things are fixed, your crafts preserve the TweakScale settings without harm. THIS DOES NOT FIX THE PROBLEM, as this is beyond the reach of TweakScale - but it at least prevents you from losing your crafts and savegames once the problem happens and then it is later fixed. You will detect this by KSP complaining about a missing TweakScaleRogueDuplicate module (previously TweakScaleDisabled, renamed for clarity). You can safely ignore this. Keep an eye on the Known Issues file. — — — — — This Release will be published using the following Schedule: GitHub, reaching first manual installers and users of KSP-AVC. Right now. CurseForge. Right now. SpaceDock (and CKAN users), Right now. The reasoning is to gradually distribute the Release to easily monitor the deployment and cope with eventual mishaps.

ANNOUNCE Release 2.4.3.7 is available for downloading, with the following changes: Updated KSPe Light for TweakScale: Standard Installation Check And that works on Windows now! Common Dialogs More consistent appearance between different installations Internal routines updated to understand Unity 2019. KSP 1.8 Ready, baby! Issues Fixed: #26 Document the patches #69 Act on deprecated or misplaced patches And correctly cleaning up this time. #76 Prevent KSP from running if TweakScale is installed on the wrong place! See OP for the links. Highlights New Runtime Check TweakScale now complains with a Houston (Fatal Error Message) when it detects it was wrongly installed. Deprecated Patches Then following patches were deprecated as the respectives Add'Ons are not available for downloading anymore, rendering them useless and even dangerous to be used by the ones that have them on their archives: KOSMOS UDK’s Large Structural Components These ones were deprecated due the Add'On’s maintainers decided to internalize them and maintain the patches themselves. HGR KAX Mining Extensions Mark 3 Expansion Deprecated patches are preserved on the Extras/Deprecated directory on the distribution file. In the unlikely event you need them back, it's recommended to copy them into a customized place on your installment and not on the TweakScale's directory hierarchy. TweakScale suggests GameData/__LOCAL/TweakScale . Overrules A overrule, as the name says, is a patch that overrules TweakScale (and anything else) in order to make things broken in a deterministic way. A complete essay can be found here. Hot Fixes A Hot Fix is a hand crafted patch that fixes by brute force patching problems, forcing the original intended result for a given KSP installment. The difference from an overrule is that Hot Fixes don’t break compatibility with sane installments, so you can start new savegames and share your crafts without worries. A complete essay can be found here. New Scaling Behaviour A new TWEAKSCALEBEHAVIOUR, ModuleGeneratorExtended , is available for parts using ModuleGenerator that wants to scale the INPUT_RESOURCES too. This feature wasn’t introduced directly into the ModuleGenerator’s TWEAKSCALEEXPONENTS to prevent damage on Add'Ons (and savegames) that rely on the current behaviour (scaling only the output), as suddenly the resource consumption would increase on already stablished bases and crafts. Just add the lines as the example below (the output resources scaling is still inherited from the default patch!). @PART[my_resource_converter]:NEEDS[TweakScale] { #@TWEAKSCALEBEHAVIOR[ModuleGeneratorExtended]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = free } } WARNINGS The known Unholy interaction between modules (Kraken Food), rogue patches or known incompatibilities between third parties Add'On that can lead to disasters are being detected on the Sanity Checks with a proper (scaring) warning being shown. A full essay about these issues can be found here. Unfortunately, such issues are a serious Show Stopper, potentially (and silently) ruining your savegames. This is not TweakScale fault, but yet it’s up to it to detect the problem and warn you about it. If this happens with you, call for help. A Cancelbutton is available for the brave Kerbonauts willing to fly unsafe. TweakScale strongly recommends using S.A.V.E.. Special procedures for recovering mangled installments once the TweakScale are installed (triggering the MM cache rebuilding) are possible, but keep your savegames backed up. And DON`T SAVE your crafts once you detect the problem. Reach me on Forum for help. TweakScale stills mangles further affected crafts and savegames with some badly (but recoverable) patched parts so when things are fixed, your crafts preserve the TweakScale settings without harm. THIS DOES NOT FIX THE PROBLEM, as this is beyond the reach of TweakScale - but it at least prevents you from losing your crafts and savegames once the problem happens and then is later fixed. You will detect this by KSP complaining about a missing TweakScaleRogueDuplicate module (previously TweakScaleDisabled, renamed for clarity). You can safely ignore this. As usual, this version still drops support in runtime for some problematic parts. Any savegame with such problematic parts scaled will have them descaled. This is not a really big problem as your game was going to crash sooner or later anyway - but if you plan to return to such savegame later when TweakScale will fully support that parts again, it’s better to backup your savegames! Keep an eye on the Known Issues file.

Got it. MODULE { name = TweakScaleRogueDuplicate // Programatically tainted due duplicity or any other reason that disabled this instanc isEnabled = True currentScale = 2.5 defaultScale = 2.5 defaultTransformScale = (0, 0, 0) DryCost = 8000 stagingEnabled = True EVENTS { } ACTIONS { } UPGRADESAPPLIED { } } TweakScale is trying to salvage the situation, so no harm is being done to your crafts (other than an annoying message from KSP on loading about a "missing" TweakScaleRogueDuplicate module). This one is from C3.Kontainer.02_4293072378. Problem: C3.Kontainer.02_4293069502 has double TweakScale modules, but they weren't flagged as a rogue duplicate. Humm... interesting - I just found a bug on the bug hunter Well, this one is fixed (pretty lame one, by the way - damn). Well, this solves the undetected rogue duplicates. Now I need to diagnose the reason of the duplicating. What follows are "interesting things" found on the KSP.log that, most probably, are completely unrelated to this problem, but may help on preventing something else (or, at least, to diagnose them): 1) The following are missing libraries, usually needed by the Add'Ons you installed. It's not necessarily an error because KSP issues an ADDON BINDER problem even when you try to probe the Assembly without loading (I think this should be an Warning, and the ERRORs should be used only when trying to load the damned thing - but, whatever). [ERR 16:34:38.608] ADDON BINDER: Cannot resolve assembly: 0_00_AT_Utils_UI, Culture=neutral, PublicKeyToken=null [ERR 16:34:38.608] ADDON BINDER: Cannot resolve assembly: 0_00_AT_Utils_UI, Culture=neutral, PublicKeyToken=null [ERR 16:34:38.623] ADDON BINDER: Cannot resolve assembly: AtmosphereAutopilot.UI, Culture=neutral, PublicKeyToken=null [ERR 16:34:38.623] ADDON BINDER: Cannot resolve assembly: AtmosphereAutopilot.UI, Culture=neutral, PublicKeyToken=null [ERR 16:34:38.642] ADDON BINDER: Cannot resolve assembly: ContractsWindow.Unity, Culture=neutral, PublicKeyToken=null [ERR 16:34:38.642] ADDON BINDER: Cannot resolve assembly: ContractsWindow.Unity, Culture=neutral, PublicKeyToken=null [ERR 16:34:38.648] ADDON BINDER: Cannot resolve assembly: EVEManager, Culture=neutral, PublicKeyToken=null [ERR 16:34:38.648] ADDON BINDER: Cannot resolve assembly: EVEManager, Culture=neutral, PublicKeyToken=null [ERR 16:34:38.649] ADDON BINDER: Cannot resolve assembly: Utils, Culture=neutral, PublicKeyToken=null [ERR 16:34:38.649] ADDON BINDER: Cannot resolve assembly: Utils, Culture=neutral, PublicKeyToken=null [ERR 16:34:38.661] ADDON BINDER: Cannot resolve assembly: KSPDev_Utils.2.2, Culture=neutral, PublicKeyToken=null [ERR 16:34:38.661] ADDON BINDER: Cannot resolve assembly: KSPDev_Utils.2.2, Culture=neutral, PublicKeyToken=null [ERR 16:34:38.665] ADDON BINDER: Cannot resolve assembly: KerbalEngineer.Unity, Culture=neutral, PublicKeyToken=null [ERR 16:34:38.665] ADDON BINDER: Cannot resolve assembly: KerbalEngineer.Unity, Culture=neutral, PublicKeyToken=null [ERR 16:34:38.703] ADDON BINDER: Cannot resolve assembly: BetterTracking.Unity, Culture=neutral, PublicKeyToken=null [ERR 16:34:38.703] ADDON BINDER: Cannot resolve assembly: BetterTracking.Unity, Culture=neutral, PublicKeyToken=null [ERR 16:34:39.436] ADDON BINDER: Cannot resolve assembly: KerboKatzUtilities.XmlSerializers, Culture=neutral, PublicKeyToken=null [ERR 16:34:39.436] ADDON BINDER: Cannot resolve assembly: KerboKatzUtilities.XmlSerializers, Culture=neutral, PublicKeyToken=null [ERR 16:34:39.437] ADDON BINDER: Cannot resolve assembly: KerboKatzUtilities.XmlSerializers 2) You have some loose MiniAVC.dll on your instalment. MiniAVC was deprecated, and can cause trouble on KSP > 1.8 releases. I suggest to install ZeroMiniAVC. 3) I took one part from the troubled ones and made a search for the applying patches: [LOG 16:35:00.506] Applying update EriksParts/TweakScale/TweakScale_USI/@PART[C3_FlatRnd_02|C3_FlatTank_02|C3_Kontainer_02|C3_Kontainer_KIS_02|C3_Tank_02|Fert_Tank_250|LS_Tank_250]:NEEDS[TweakScale] to UmbraSpaceIndustries/Kontainers/Kontainer_02.cfg/PART[C3_Kontainer_02] [LOG 16:35:01.005] Applying update KRnD/MM_Patches/parts/@PART[*]:HAS[!MODULE[KRnDModule]] to UmbraSpaceIndustries/Kontainers/Kontainer_02.cfg/PART[C3_Kontainer_02] [LOG 16:35:10.190] Applying update UmbraSpaceIndustries/Kontainers/Kontainers_CTT/@PART[C3_Kontainer_02]:NEEDS[CommunityTechTree] to UmbraSpaceIndustries/Kontainers/Kontainer_02.cfg/PART[C3_Kontainer_02] [LOG 16:35:10.213] Applying update UmbraSpaceIndustries/Kontainers/Kontainers_TweakScale/@PART[C3_*_02]:HAS[@MODULE[FSfuelSwitch]]:NEEDS[TweakScale] to UmbraSpaceIndustries/Kontainers/Kontainer_02.cfg/PART[C3_Kontainer_02] Well, it's a classic Double Patching: EriksParts/TweakScale/TweakScale_USI.cfg is patching C3.Kontainer.02 together UmbraSpaceIndustries/Kontainers/Kontainers_TweakScale.cfg . I think that you misdiagnosed the cause of the problem due that lame mistake of mine on the Rogue Patching mitigator (this one will be fixed on the next release).

There's a huge amount of problems on your rig. Let's start for the easier one: [ERR 21:22:45.402] [AssemblyLoader] Exception when getting assembly attributes: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown. Additional information about this exception: System.TypeLoadException: Could not load type of field 'ProbeControlRoom.ProbeControlRoom:toolbarControl' (35) due to: Could not load file or assembly 'ToolbarControl, Version=0.1.9. 4, Culture=neutral, PublicKeyToken=null' or one of its dependencies. assembly:ToolbarControl, Version=0.1.9.4, Culture=neutral, PublicKeyToken=null type:<unknown type> member:(null) s ignature:<none> [ERR 21:22:45.402] [AssemblyLoader] Exception when getting assembly attributes: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown. Additional information about this exception: System.TypeLoadException: Could not load type of field 'Tac.FuelBalanceController:toolbarControl' (11) due to: Could not load file or assembly 'ToolbarControl, Version=0.1.9.4, Cultu re=neutral, PublicKeyToken=null' or one of its dependencies. assembly:ToolbarControl, Version=0.1.9.4, Culture=neutral, PublicKeyToken=null type:<unknown type> member:(null) signature :<none> You need to install ToolbarControl. Additionally, there's a bunch of rogue patches on your system: [LOG 21:22:40.468] [TweakScale] ERROR: **FATAL** Part Thoroughbred (S2-17"サラブレッド"固体燃料ブースター) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 21:22:40.469] [TweakScale] ERROR: **FATAL** Part Clydesdale (S2-33"クライズデール"固体燃料ブースター) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 21:22:40.470] [TweakScale] ERROR: **FATAL** Part Shrimp (F3S0"シュリンプ"固体燃料ブースター) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 21:22:40.471] [TweakScale] ERROR: **FATAL** Part Mite (FM1"マイト"固体燃料ブースター) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 21:22:40.502] [TweakScale] ERROR: **FATAL** Part rocketNoseConeSize4 (ロケット保護用ノーズコーンMk16A) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 21:22:40.503] [TweakScale] ERROR: **FATAL** Part Size.1.5.Cone (ロケット保護用ノーズコーンMk5A) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 And the problem is an old friend, BladeTweaks: [LOG 21:13:29.236] Applying update BladeTweaks/Squad-TweakScale/@PART[Thoroughbred]:FOR[TweakScale] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] Delete BladeTweaks/Squad-TweakScale.cfg and this should solve these last problems. Cheers!! p.s.: By reading the messages above, you should be aware that there's a bug on KSP affecting TweakScale when attaching radially parts with Variants - you will be bitten by it almost surely. You can overcome the problem by launching crafts directly from LaunchPad or Runway without loading the craft on the Editor - once the craft is loaded on Editor (and only when loading the craft on the Editor), it wills screw up the surface attached parts with Variants that are scaled, and the only solution is to re-place the parts. It's a pain in the SAS, I know. I will work on this bug on this WeekEnd. [EDIT: NO MORE! KSP-Recall to the Rescue!]

ANNOUNCE Release 2.4.4.0 is available for downloading, with the following changes: Updated KSPe Light for TweakScale: Suport for KSP 1.11 Chain Scaling now jumps over parts without TweakScale support, instead of just breaking the chain. Parts with Variants that change Mass and/or Cost are now supported. #HURRAY Formal Public Interface for scaling helpers (used mainly by the Companions) Added ignoreResourcesForCost attribute to allow custom modules to deactivate TweakScale calculations for resources Installation checks, detecting common installation errors. Complete overhaul of the patches for Stock (and DLC) parts Only fixes that don't break current savegames were applied. TweakScale 2.5 will have further fixes merged, even when unbalancing existing crafts. Issues Fixed: Formally closes 49 issues, backporting (almost) all fixes from the Beta Releases until 2.5.0.27. Please see the Change Log, as they are too much to be enumerated comfortably here! All of these totalling 353 commits to be merged since the previous 2.4.3.21 release!! See OP for the links. Highlights Formal support for KSP from 1.4.4 to 1.11 KSP 1.11 didn't introduced any changes that break TweakScale, so it's formally supported. However, in order to proper support Variants, the minimal KSP version supported by now is 1.4.4 . Sorry for that. TweakScale 2.5 aims to bring back support for KSP down to 1.2.2 (exactly how, is still work in progress, but it's feasible as being demonstrated by some Unofficial forks of mine). Parts with Variants Variants that change Cost and/or Nass are now fully supported, but TweakScale is struggling to support Parts with Variants that changes Attachment Nodes. I had planned to withdraw TweakScale support from such parts as I did in the past, but then I realised that most Version 2 parts from already scalable parts (as Terrier...) would had TweakScale withdrawn, and this would render some crafts and savegames corrupted. Since most of these parts didn't misbehave on a noticeable way, I decided to just let it go as is for while. Just a few stock parts are misbehaving into a noticeable way, and these parts are (until the moment): The Mastodon engine The Structural Tubes T-12 T-18 T-25 T-37 T-50 And probably more, as Add'Ons starts to use such feature. The only workaround at the moment is to descale these parts before applying the variant and then scaling them again. Alternatively, just detach and reattach the misbehaving parts. A proper fix is Work in Progress, and is expected to be released on 2.4.4.1 2.4.4.something..... Deprecating Patches Support for all non Squad parts are on a deprecating status and will be definitively removed on TweakScale 2.5. The TweakScale Companion Program will be the source for supporting third-parties add'ons. It's advised to install the needed Companions as they reach Gold status. Sanity Checks Parts using Firespitter's FSbuoyancy needs the latest TweakScale Companion for Firespitter, as only the Companion has the specific code that knows how to handle it. Overrules A overrule, as the name says, is a patch the overrules TweakScale (and anything else) in order to make things broken in a deterministic way. A complete essay can be found here. Hot Fixes A Hot Fix is a hand crafted patch that fixes by brute force patching problems, forcing the original intended result for a given KSP installment. The difference from an overrule is that Hot Fixes don't break compatibility with sane installments, so you can start new savegames and share your crafts without worries. A complete essay can be found here. New Scaling Behaviour A new TWEAKSCALEBEHAVIOUR, ModuleGeneratorExtended , is available for parts using ModuleGenerator that wants to scale the INPUT_RESOURCES too. This feature wasn't introduced directly into the ModuleGenerator's TWEAKSCALEEXPONENTS to prevent damage on Add'Ons (and savegames) that rely on the current behaviour (scaling only the output), as suddenly the resource consumption would increase on already stablished bases and crafts. Just add the lines as the example below (the output resources scaling is still inherited from the default patch!). @PART[my_resource_converter]:NEEDS[TweakScale] { #@TWEAKSCALEBEHAVIOR[ModuleGeneratorExtended]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = free } } WARNINGS The known Unholy interaction between modules (Kraken Food), rogue patches or known incompatibilities between third parties Add'On that can lead to disasters are being detected on the Sanity Checks with a proper (scaring) warning being shown. A full essay about these issues can be found here. Unfortunately, such issues are a serious Show Stopper, potentially (and silently) ruining your savegames. This is not TweakScale fault, but yet it's up to it to detect the problem and warn you about it. If this happens with you, call for help. A Cancel button is available for the brave Kerbonauts willing to fly unsafe. TweakScale strongly recommends using S.A.V.E.. Special procedures for recovering mangled installments once the TweakScale are installed (triggering the MM cache rebuilding) are possible, but keep your savegames backed up. And DON`T SAVE your crafts once you detect the problem. Reach me on Forum for help. TweakScale stills mangles further affected crafts and savegames with some badly (but recoverable) patched parts so when things are fixed, your crafts preserve the TweakScale settings without harm. THIS DOES NOT FIX THE PROBLEM, as this is beyond the reach of TweakScale - but it at least prevents you from losing your crafts and savegames once the problem happens and then it is later fixed. You will detect this by KSP complaining about a missing TweakScaleRogueDuplicate module (previously TweakScaleDisabled, renamed for clarity). You can safely ignore this. Keep an eye on the Known Issues file. — — — — — This Release will be published using the following Schedule: GitHub, reaching first manual installers and users of KSP-AVC. Right now. CurseForge - will not upload. New TweakScale release is needed due KSP 1.11 bug. SpaceDock (and CKAN users) - will not upload. New TweakScale release is needed due KSP 1.11 bug. The reasoning is to gradually distribute the Release to easily monitor the deployment and cope with eventual mishaps.

Deinstalling TweakScale would break flying crafts that have scaled parts for sure. That's the reason I push S.A.V.E. to be used by everyone - something breaks somewhere (and not only on TweakScale), and we risk KSP shoving bad data on flying crafts. But the pink squares is a new for me - TweakScale doesn't touches textures, it scales the mesh and let KSP handle the texturing.... The Sanity Checks are about parts with known problems, and that are deactivated. TweakScale warns you about the deactivation because someone wrote a patch to it, and so it's expected that such part would be scaled. That parts you mentioned are parts with VARIANTS with mass, a known problem still to be fixed by TweakScale - it's scheduled to be (AT LAST!) handled on TweakScale 2.4.4 series - assuming a new pandemic doesn't shove all my plans on the trash bin again.... Since these parts were never really supported in the past, this is not a FATALity (i.e., something that will break KSP). That pesky warning, FINALLY, now are only issued when Module Manager redo the patching (to tell you the true, TweakScale checks the timestamp of the MM caches and suppress Warnings and Advises if they are older than 1 hour). Now... That Houstons you got are the real deal - Something is usually really bad (or looks like being bad - TweakScale is not really smart to tell weird things from bad weird things, so it yells on anything weird). One weirdness that can be really problematic (but not always) is double patching, i.e., when a rogue patch patches an already patched part uncontrollably. Last time this happened on KIS was due me forgetting to remove a old file from the TweakScale distribution - and, yeah, you are using TweakScale 2.4.3.11 - the one I had borked! [LOG 15:53:19.127] [TweakScale] Version 2.4.3.11 /L <yada yada yada> [LOG 15:53:27.167] Applying update TweakScale/Deprecating/patches/KIS_TweakScale/@PART[KIS_Container1] to KIS/Parts/container1/part.cfg/PART[KIS_Container1] [LOG 15:53:29.643] Applying update TweakScale/patches/KIS_TweakScale/@PART[KIS_Container1] to KIS/Parts/container1/part.cfg/PART[KIS_Container1] Please use the latest TweakScale, 2.4.3.15 . It's currently only on Github, CurseForge will be updated tonight and SpaceDock (and CKAN) tomorrow night. However, the current patches for KIS are EoL, they are old and do not scales most current KIS parts. TweakScale Companion for KIS will solve that, but currently this is still in Alpha status, so perhaps you should wait a bit as I didn't ironed out all the bugs of that thing (if any, the true is that I don't know if there're bugs on it yet!). In time, I found a lot of MiniAVC dlls on your instalment. MiniAVC was deprecated by the maintainer, and it's known to play havoc on KSP >= 1.8, sometimes in a pretty nasty way. Please install ZeroMiniAVC - really, install it, it's a question of time until something triggers a crash. Cheers!

Hi. I had being asked (more than once) if this overrules and hotfixes of mine are definitive fixes, if they can be used safely, etc, etc, etc. So I though it could be a good idea to try to explain, better this time, what at heck are these stunts after all. Overrules An overrule, as the name says, is a patch the overrules TweakScale (and anything else) in order to make things "broken" in a deterministic way. Rogue patches usually renders the GameDatabase in a unsafe state, but sometimes they just messes things without provoking crashes on the game. So, once these situations are detected (i.e.: messed up GameDatabases but that doesn't explodes under our noses), a overrule can be created to keep only some parts "broken" in order to keep ongoing savegames… ongoing. This is needed because, now, savegames are intrinsically tied to the GameDatabase on the host installment. Modules preset on the GameDatabase that are not present in the savegame are injected while loading. It wasn't always this way - some KSP versions ago, and I tested it until 1.4.5, absent modules on the savegame would render parts in memory without that modules - so this is a relatively new problem. Older KSPs probably don`t need this - but yet, rogue patches are undesirable anyway. There're three problems on this approach: I brute force my way into the GameDatabase, disregarding everything else. This is bad because an additional Add'On would like to change something (as a new scale type), and the overrule will bluntly throw away everything and shove a recorded in stone configuration that used to work on the time I wrote the thing. So every time a new Add'On that patches something with TweakScale is installed, we need to make sure that the overrule are still valid. This keeps the GameDatabase in a unholy (besides controlled) state, and so every craft and savegame will only work on a broken installment. It's, indeed, only meant to prevent you from losing your savegame. It prevents the part to be checked by the Sanity Checks. Since the thing is essentially breaking the part, it would rise an "Houston" on TweakScale. So… if you mess up a Overrule, TweakScale will not detect the problem. HotFixes A HotFix is something like a Overrule, except that instead of breaking the part to keep an ongoing savegame alive, I effectively fix the part as it should be at first place. They are meant to be used while the Add'On Author/Maintainer doesn't applies a new Release with the fixes, or when the Add'On is stalled and cannot be adopted and fixed due Copyright reasons (as being ARR or CC-*-ND). This is less worst than an overrule because crafts and savegames are now interchangeable between different (sane) KSP installments. But there're two problems on this approach: I brute force my way into the GameDatabase, disregarding everything else. This is bad because an additional Add'On would like to change something (as a new scale type), and the overrule will bluntly throw away everything and shove a recorded in stone configuration that used to work on the time I wrote the thing. So every time a new Add'On that patches something with TweakScale is installed, we need to make sure that the overrule are still valid. It prevents the part to be checked by the Sanity Checks, as sometimes it will force a condition that the Sanity Check thinks it's bad, but it was found to be a false alarm. So… if you mess up a HotFix, TweakScale will not detect the problem. Conclusions Overrules and HotFixes are not final solutions for the problem. They are temporary workarounds that fix the problem under our noses, but can create new ones later, and are meant to be used as last resource only. The only real and safe solution for the problem is reaching the offending Add'On Author/Maintainer for a new release with the problem fixed. In the mean time, and as always, you can reach me here for help when things go through the tubes. No savegame will be left behind. Link to my site where this essay will be updated now and then http://ksp.lisias.net/blogs/tech-support/TweakScale/Hotfixes-and-Overrules

Your assessment of the situation was accurate. Something is, indeed, duplicating (or deleting!!!) the TweakScale node on the Spark engine. There's something weird happening here. The internal name of the engine you used (Spark) is liquidEngineMini.v2. In my test bed, this part is working perfectly fine (ie, I can scale and use it without any new issues besides the already known ones - the plumes not scaling). This reflects on my KSP.log (I tested it twice, with and without Making History just to be sure) [LOG 01:08:59.178] ******* Log Initiated for Kerbal Space Program - 1.6.1.2401 (OSXPlayer) en-us ******* Kerbal Space Program - 1.6.1.2401 (OSXPlayer) en-us OS: Mac OS X 10.12.6 CPU: Intel(R) Core(TM) i5-2415M CPU @ 2.30GHz (4) RAM: 16384 GPU: Intel HD Graphics 3000 OpenGL Engine (579MB) SM: 40 (OpenGL 3.3 INTEL-10.2.37) RT Formats: ARGB32, Depth, ARGBHalf, Shadowmap, RGB565, ARGB4444, ARGB1555, Default, ARGB2101010, DefaultHDR, ARGB64, ARGBFloat, RGFloat, RGHalf, RFloat, RHalf, R8, ARGBInt, RGInt, RInt, RGB111110Float, RG32, RGBAUShort, RG16 <....> [LOG 01:09:58.071] DragCubeSystem: Creating drag cubes for part 'liquidEngineMini.v2' <....> [LOG 01:10:34.416] Part found: liquidEngineMini.v2 [LOG 01:10:34.416] Part liquidEngineMini.v2 has Module ModuleEnginesFX [LOG 01:10:34.417] Part liquidEngineMini.v2 has Module ModuleJettison [LOG 01:10:34.417] Part liquidEngineMini.v2 has Module ModuleGimbal [LOG 01:10:34.417] Part liquidEngineMini.v2 has Module ModuleTestSubject [LOG 01:10:34.417] Part liquidEngineMini.v2 has Module ModulePartVariants [LOG 01:10:34.417] Part liquidEngineMini.v2 has Module FXModuleAnimateThrottle [LOG 01:10:34.417] Part liquidEngineMini.v2 has Module TweakScale [LOG 01:10:34.417] Part liquidEngineMini.v2 has Module ModulePartInfo [LOG 01:10:34.417] Part liquidEngineMini.v2 has drycost 240 with ignoreResourcesForCost False <....> [LOG 01:12:07.053] liquidEngineMini.v2 added to ship - part count: 3 (my DLL is the debug version, a relentless log spammer! ) But this is what I got from yours: [LOG 21:40:06.797] DragCubeSystem: Creating drag cubes for part 'liquidEngineMini.v2' <.....> [WRN 21:40:23.438] [TweakScale] Removing [LOG 21:39:27.132] ******* Log Initiated for Kerbal Space Program - 1.6.1.2401 (WindowsPlayer x64) en-us ******* Kerbal Space Program - 1.6.1.2401 (WindowsPlayer x64) en-us OS: Windows 10 (10.0.0) 64bit CPU: Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz (12) RAM: 32708 GPU: NVIDIA GeForce GTX 1080 Ti (11127MB) SM: 30 (Direct3D 9.0c [nvldumdx.dll 25.21.14.1935]) RT Formats: ARGB32, Depth, ARGBHalf, Shadowmap, RGB565, Default, ARGB2101010, DefaultHDR, ARGB64, ARGBFloat, RGFloat, RGHalf, RFloat, RHalf, R8, RG32 <.....> TweakScale support for liquidEngineMini.v2. [ERR 21:40:23.438] [TweakScale] Part liquidEngineMini.v2 didn't passed the sanity check due having a ModulePartVariants with Mass - see issue #13 https://github.com/net-lisias-ksp/TweakScale/issues/13. <.....> [LOG 21:40:48.730] liquidEngineMini.v2 added to ship - part count: 2 [WRN 21:40:50.841] Exception on rescale: System.NullReferenceException: Object reference not set to an instance of an object at TweakScale.TSGenericUpdater.OnRescale (ScalingFactor factor) [0x00000] in <filename unknown>:0 at TweakScale.TweakScale.CallUpdaters () [0x00000] in <filename unknown>:0 [WRN 21:41:36.487] Exception on rescale: System.NullReferenceException: Object reference not set to an instance of an object at TweakScale.TSGenericUpdater.OnRescale (ScalingFactor factor) [0x00000] in <filename unknown>:0 at TweakScale.TweakScale.CallUpdaters () [0x00000] in <filename unknown>:0 [WRN 21:41:45.804] Exception on rescale: System.NullReferenceException: Object reference not set to an instance of an object at TweakScale.TSGenericUpdater.OnRescale (ScalingFactor factor) [0x00000] in <filename unknown>:0 at TweakScale.TweakScale.CallUpdaters () [0x00000] in <filename unknown>:0 [LOG 21:43:03.880] deleting part liquidEngineMini.v2 [ERR 21:43:07.222] Cannot find module 'TweakScale' (-699235618) <....> We have the exact same KSP version, the very same TweakScale version (mine is just compiled in debug mode), and you tried the new patches on the github (that I'm using too), and yet, two completely different results. So, or MacOS has something hidden that automatically fix things that bork on Windows ,, or we have something mangling/hijacking/trolling TweakScale patches. A quick search on your KSP reveals the there're more people besides me using the ":FOR" clausule, what's plain wrong. And since they are sorted alphabetically before TweakScale, they got applied first, rendering my patches ineffective or duplicated in second place. That can be a good explanation by the same part passing the Sanity Checks on my installment, but being refused on yours - and since the duplicates detector honors the first occurrence, deactivating the remaining ones, it ends up deactivating my patches. leading to: The second slider doesn't works - as expected, as the duplicate detector got rid of the Module instance that would answer to it The first sliders borking on NREs, as they are tied to the first occurrence of the TweakScale module that was not injected by my patches. Again, your assessment of the situation was accurate - these parts were hijacked by rogue patches. [I got the behaviour right, but pinpoint the wrong doer. This is happening at runtime!] By morning I will generate a report from your log with all the offending patches, so we can fix your copies in situ and, if things became right, start to firing up Issues to the maintainers. In time, "[x] Science!" is borking relentlessly on your KSP. I suggest you update it to a 1.6 compatible release, or plain delete it if such version doesn't exists. This is hurting your KSP, as it's happening on a event handler that can be aborting a chain of events: [ERR 21:40:23.296] Exception handling event onNewGameLevelLoadRequestWasSanctionedAndActioned in class ScienceChecklistAddon:System.MissingMethodException: Method not found: 'MusicLogic.SetVolume'. at ScienceChecklist.ScienceChecklistAddon.onLevelWasLoaded (GameScenes action) [0x00000] in <filename unknown>:0 at EventData`1[GameScenes].Fire (GameScenes data) [0x00000] in <filename unknown>:0 EVE Manager is also borking, but I don't think this is anything but a annoyance by now: [LOG 21:47:47.635] EVEManager: Issue loading ShadowManager! Error: System.NullReferenceException: Object reference not set to an instance of an object at Utils.MaterialPQS.RemoveFromPQSCities () [0x00000] in <filename unknown>:0 at Utils.MaterialPQS.Remove () [0x00000] in <filename unknown>:0 at CelestialShadows.ShadowObject.Remove () [0x00000] in <filename unknown>:0 at EVEManager.GenericEVEManager`1[T].Clean () [0x00000] in <filename unknown>:0 at EVEManager.EVEManagerBase.Apply () [0x00000] in <filename unknown>:0 at EVEManager.EVEManagerBase.LoadConfig () [0x00000] in <filename unknown>:0 at EVEManager.GenericEVEManager`1[T].Setup () [0x00000] in <filename unknown>:0 at CelestialShadows.ShadowManager.Setup () [0x00000] in <filename unknown>:0 at EVEManager.GlobalEVEManager.Setup (Boolean late) [0x00000] in <filename unknown>:0 [LOG 21:47:47.635] [Scatterer] Celestial Body: Kerbin (CelestialBody)

Interesting. I had played Career on the 1.4.x era using TweakScale (it was how I got involved on this), and I don't remember problems on it (other than the problems I was getting everywhere, of course). We had a lot of problems on 3rd party patches, some others on TweakScale itself, we had used TweakScale to diagnose some bordeline situations inside KSP itself (as the zero ou negative mass problem) and for a lot of time my focus was hunting down these rogue patches and borderline situations and cook safety-measures to help on this task. But once the patching is successful, no misbheaviour were detected on Career. (there're some technical debts on TweakScale, of course, but they don't affect Career specifically, the misbehaviours are consistent on all game modes) What we have is a lack of support from Custom Tech Trees - TweakScale is available on Career the same way it's available on Sandbox - if you have access to a part, you can scale it at will - no restrictions applied.

ANNOUNCE. Release 2.4.2.0 is available for downloading. See OP for the links. And yet another *Unholy interaction between modules* (Kraken Food) was detected when rogue patches apply twice the same property on a part. Unfortunately, one of that rogue patches were being delivered on the TweakScale Releases. We apologize for that. Be advised that a new situation was detected that demanded withdrawing support from some parts at runtime due rogue patching. No breakage is expected this time as such parts are rendered useless and you could not use them anyway, but take precautions on installing Add'Ons on your installment as some older ones are prone to induce this misbehaviour. Issues that would mangle your savegames and crafts still persists. Things still work until the problem is fixed (by installing, deleting or updating an add'on!) when then your KSP installment will be sane but all your savegames and crafts with TweakScale parts will get reset to defaults - yeah, you can't fix the problem or things get worse. This version of TweakScale "mangles further" the affected crafts and savegames so when things are fixed, your crafts preserve the TweakScale settings without harm. THIS DOES NOT FIX THE PROBLEM, as this is beyond the reach of TweakScale - but it at least prevents you from losing your crafts and savegames once the problem happens and then is later fixed. Special procedures for recovering mangled installments once the TweakScale are installed (triggering the MM cache rebuilding) are possible, but keep your savegames backed up. And DON`T SAVE your crafts once you detect the problem. Reach me on here for help. As usual, this version still drops support in runtime for some problematic parts. Any savegame with such problematic parts scaled will have them "descaled". This is not a really big problem as your game was going to crash sooner or later anyway - but if you plan to return to such savegame later when TweakScale will fully support that parts again, it's better to backup your savegames! Currently, only EnginePlate1 to 5, and Tube1 to 4 are being affected due using ModulePartVariants with mass. It's an annoyance, but not a really heavy impact on gaming. I'm trying to figure out coding time to fix this on TS 2.5.0, the next major milestone. On the bright side, it Default support for Near Future Aeronautics, thanks to our fellow Kerbonaut Red Stapler. Please keep an eye on the KNOWN ISSUES file. I will keep it updated regularly. — — — — — This Release will be published using the following Schedule: GitHub , reaching first manual installers and users of KSP-AVC. CurseForge -online SpaceDock (and ckan users) - by monday night The reasoning is to gradually distribute the Release to easily monitor the deployment and cope with eventual mishaps.

My apologies to anyone that witnessed that sad exchange of… opinions. I'll try not to be drawn again to such things. Now, let's get back to business. Got it. [LOG 18:57:27.124] [TweakScale] INFO: WriteDryCost Concluded : 1429 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 6 Show Stoppers found; 9 Sanity Check failed; 488 unscalable parts. You can ignore that 9 "Sanity Check failed", these are parts that were patched but since some things had changed over time, TweakScale was not doing a proper job on supporting them. Please be patient as these parts will be supported on the next Iteration (2.4.4.x) of TweakScale. Let's get our pawns dirty on that 6 FATALities: [LOG 18:57:27.020] [TweakScale] ERROR: **FATAL** Part M2X.Endcap (Mk2 Airlock Adapter Endcap) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 18:57:27.041] [TweakScale] ERROR: **FATAL** Part SecuBot16bad (SecuBot16bad) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 18:57:27.043] [TweakScale] ERROR: **FATAL** Part M50FixedAero (M50FixedAero) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 18:57:27.044] [TweakScale] ERROR: **FATAL** Part Single30TurretAlpha (Single 30 Turret) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 18:57:27.045] [TweakScale] ERROR: **FATAL** Part M30StreamlinedAero (SM30 Auto Cannon) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 18:57:27.046] [TweakScale] ERROR: **FATAL** Part GeneralDynamicsXM301 (GD_XM301 Gatling) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). The first one, M2X.EndCap, was already identified before. It is/was a glitch on Mk2 Expansion. My pull request was closed and the fixes applied. The 1.8.6. release has the fixes. Please update Mk2Expansion. The remaining 5, SecuBot16bad; M50FixedAero; Single30TurretAlpha; M30StreamlinedAero and GeneralDynamicsXM301 are being patched by SM_Armory, an Add'On that is not available anymore for downloading. One of them are being patched twice by SM_Armory: [LOG 18:53:22.644] Applying update SM_Armory/Patches/tweakscale/@PART[Single30TurretAlpha] to SM_Armory/Parts/Config/Single30Ball.cfg/PART[Single30TurretAlpha] [LOG 18:53:22.877] Applying update SM_Armory/Patches/tweakscale/@PART[Single30TurretAlpha] to SM_Armory/Parts/Config/Single30Ball.cfg/PART[Single30TurretAlpha] So I think it's reasonable to conclude that the source of the rogue patching appears to be SM_Armory. However, this Add'On is ARR and it's not available anymore for downloading, so I can't even inspect the patches myself, so we are in the dark on this issue. What doesn't means I can't try to help. Please send me your ModuleManager.ConfigCache so I can eye-ball it. With some luck, and by analysing the other Add'Ons those patches are available, I can infer the SM_Armory's original intent and then provide you with a HotFix for SM_Armory. Alternatively, if you have a GitHub account, we can move this "ticket" to the Issue #63, as more than one fellow Kerbonaut are getting some problems with it. Ugh.. [LOG 13:53:20.773] [TweakScale] INFO: WriteDryCost Concluded : 1136 parts found ; 0 checks failed ; 0 parts with hotfixes ; 1 parts with issues overruled ; 118 Show Stoppers found; 0 Sanity Check failed; 478 unscalable parts. 118 show stoppers. And some of them are, indeed, badly patched. Three tines in a row, as this part I got from the ConfigCache: MODULE { name = TweakScale type = free type = free type = free_square } Yep, we have some work to do! However, I have a problem. Your KSP.log appears to be incomplete! See: [LOG 13:50:40.451] Config(PART) AirplanePlus/Parts/Aero/smallwings/halfwing/smallwingConnector1 [LOG 13:50:43.427] PartLoader: Compiling Part 'AirplanePlus/Parts/Aero/smallwings/halfwing/smallwingConnector1' [LOG 13:50:43.491] PartLoader: Part 'AirplanePlus/Parts/Aero/smallwings/halfwing/smallwingConnector1' has no database record. Creating. [LOG 13:50:43.494] DragCubeSystem: Creating drag cubes for part 'smallwingConnector1' [LOG 13:53:20.641] [TweakScale] WARNING: **FATAL** Found a showstopper problem on smallwingConnector1 (Wing Connector Type F). [LOG 13:53:20.642] [TweakScale] ERROR: **FATAL** Part smallwingConnector1 (Wing Connector Type F) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). Do you see? There are no "Applying updates" lines on the log! (see the previous ones to see how they list every patch on a part using a log line with "Applying update"). Initially I thought you were being running from a ConfigCache, but I found: [LOG 2019-09-16 13:15:16.312] Checking Cache [LOG 2019-09-16 13:15:20.683] SHA generated in 4.379s [LOG 2019-09-16 13:15:20.683] SHA = 65-EC-B7-DC-C2-42-FD-12-56-78-D8-A1-68-23-F0-54-F1-46-FE-7C-B6-B1-F9-BE- [LOG 2019-09-16 13:15:23.180] Changes : Added : GameData/AM6E1engine/AM6E1engine.cfg <cut> [LOG 2019-09-16 13:15:23.185] Cache SHA = 4D-CE-A9-99-5B-2A-A7-DC-98-3F-FA-30-41-F5-71-AA-BC-E5-26-A8-40-4F-94-5C- [LOG 2019-09-16 13:15:23.185] useCache = False What means that no, you are not loading from cache. But then I found some parts with the log message, and others without: [LOG 2019-09-16 13:46:09.429] Applying update SMArmory/SM_OSTandT/Patches/Armor_SMI_OST/@PART[Tiger1Hull]:FINAL to SMArmory/SM_OSTandT/Parts/Tiger1Hull/Tiger1Hull.cfg/PART [LOG 2019-09-16 13:46:09.479] Applying update TweakScale/BreakingParts/B9_HX/@PART[B9_Structure_HX1_S_HS]:NEEDS[TweakScale]:FINAL to B9_Aerospace_HX/Parts/Structure_HX/model_hx_size1_structure_hub_support.cfg/PART And this can explain why some parts are terribly patched - the BreakingParts are a stunt to prevent ongoing savegames to break by fixing the parts. Not all double patching leads to a crash, so initially I was trying to keep some parts broke in order to prevent losing ongoing savegames. So, unless I had told you to use this stunt, please delete GameData/TweakScale/BreakingParts . You have a some SM Add'ons on your installment, and there's a chance that some of them can be doing something wrong are the previous guy. But since your KSP.log is… weird… I can't be sure. Your list of DLLs says: Mod DLLs found: Stock assembly: Assembly-CSharp v0.0.0.0 ModuleManager v3.1.1.0 ModuleManager v3.1.2.0 ModuleManager v4.0.2.0 B9AnimationModules v1.3.2.0 / vv1.3.2 B9PartSwitch v2.5.1.0 / vv2.5.1 BDArmory.Core v1.3.1.0 BDArmory v1.3.1.0 Firespitter v7.3.6867.18541 KTechCategoryMaster v0.0.0.1 SMI_APUcontroller v0.0.0.1 RasterPropMonitor v0.30.5.22792 KTechCategoryMaster v0.0.0.1 SMI_APUcontroller v0.0.0.1 SM_MalFuncIndustries v0.1.0.5 SMI SmallArms v0.0.1.0 HoverCraft v1.0.4.4 SMIndustries v0.1.0.6 VLSLauncher v0.1.0.0 SM_ParaMotor v0.0.0.1 StrykerAA v0.1.0.5 SmokeScreen v2.8.1.0 Stock assembly: KSPSteamCtrlr v0.0.1.35 KSPe.Light.TweakScale v2.1.0.13 Scale v2.4.3.4 Scale_Redist v1.0.0.0 / v2.4.3.4 With three different versions for Module Manager available. Perhaps having all of them installed leaded to this glitch? This is a blocking issue for me, because without a log that tells me every "Applying Update", I cant trace who is patching who and then I'm on the dark without the option of detecting the source of the problems and propose fixes. So I need to ask you to: Delete all Module Maneger DLLs but the 4.0.2 one. Make sure you are not logging Module Manager into separate log files. I need all the logs into the KSP.log file, my tools are designed to work this way. Delete ModuleManager.ConfigCache Delete the directory <KRP_ROO>/Logs Launch KSP.exe As soon the FATAL Alert Box appears, just shutdown KSP Send me again KSP.log, ModuleManager.ConfigCache, and just to be on the safe side, everything under <KRP_ROO>/Logs Hopefully this will provide me with the information I need to check things. To avoid accidentally deleting them, I propose to save the files on: hacks GameData/__LOCAL/TweakScale/hacks Hot Fixes GameData/__LOCAL/TweakScale/HotFixes Overrules GameData/__LOCAL/TweakScale/Overrules You can put them anywhere, but these locations are easy to remember, to check and are out of the way of the installers tools so you don't risk losing anything when update things. [LOG 17:14:30.249] [TweakScale] INFO: WriteDryCost Concluded : 1630 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 554 Show Stoppers found; 0 Sanity Check failed; 476 unscalable parts. Yeah, you have about 554 Show Stoppers!! Dude, you are definitively the Winner on this contest! But I need the full Log. I need to track down evert patch being applied to get into the problem. Please publish the full KSP.log (and also the ModuleManager.ConfigCache) on Google Drive, Drop Box or something like that. My hands are tied without all that information!