Lisias

No more than floating habitats on the warm high atmosphere of Venus. And yet.. NASA Concept. Click on the image for more information.

Not necessarily. Aviation engines like the Wasp Major and Duplex Cyclone don't do it. Airplane builders attach the alternator they think is adequate to the shaft to generate electricity. On multiple engine aircrafts, not all of them have alternators - sometimes, only one engine has one, and the pilot had to rely on the APU if that engine fails (to tell you the true, some commercial airlines are this way until nowadays). Fuel cells are excellent APUs , but I agree that an alternator should be provided to be attached to the prop engines - or your idea should be implemented. It's probably easier to implement your idea, however.

Been there, doing that since. Multi thread, multi core, even multi CPU. Worst, diferent CPUs. It's hard? Yep. It's messy? Sometimes. It's unfeasible? Not. Nobody needs to pay you for doing easy things - they can do it by themselves without you. And, exactly as in Nam, your chances or survival increases considerably by having good combatants on your side, instead of crying ones. Life is tough. Coding is no different.

Thinking is a very healthy habit, I think I should do that more times. There's another option that I totally missed. A OVERRULE patch. It's kinda of brute-forcing our way out of the mess, and this may make Add'Os' Authors less than happy (as we would deactivating things they intended to be active), but it's a way out nevertheless. This will surely void your warranty . Update your TweakScale to 2.4.3.2, where I fixed a dumb mistake on the Log, generate another Log and post it with the ModuleManager.ConfigCache. Then tell me what is your favorite Fuel Switch. I will cook a OVERRULE patch that will delete all the others FuelSwitches but the one you want when more than one FuelSwitch is on a part. It's not perfect as it can be overruled² by a smarter patch, may break if you install another Fuel Switch, but it may work for now. And if that thing really works, I can consider adding it to Extras folder of the next TweakScale version!

Announce. Minor Release 2.4.3.2 is on the wild. Just some typos fixed and added support for the new Cryo Engines from Nertea's. 2019-0804: 2.4.3.2 (Lisias) for KSP >= 1.4.1 This is an Emergencial Release due an Emergencial Release due an Emergencial Release. I love recursion, don’t you? Closing or reworking the following issues: #65 Support for new Nertea’s Cryo Engines Thanks to friznet and marr75. Fixing some tyops on Logging and Dialog Boxes. Links on the OP.

Of course, not! We will puff them first! Vaporized Kerbals are ideal to feed gas engines!

To avoid taking heat from the environment while the gas goes up. You want to pump heat from your facilities, not from the low atmosphere.

Hi! A TweakScale user reported an problem that ended up being a glitch on one of the MK2Expansion patches. I fixed the glitch and applied a pull request. Cheers!

I think I have a "solution" for this problem. Space Elevators. Making a floating nuclear reactor to exploit cooler environment high in the Venus skies is unfeasible (and you would need to transmit the electricity anyway, somewhat hard to accomplish when the energy source is moving around). But a space elevator would provide anchorage for such a stunt. I doubt it would be cost effective to move the whole shebang to the high atmosphere of Venus, but heat pipes would do. And the Space Elevator would then transmit the energy to the consumers, probably floating cities in the high atmosphere of Venus, where the temperature and pressure are pleasant for humans (saving costs on housing and EVA suits.

Failing a Sanity Check means a known issue that was mitigated to avoid problems. It's a nuisance, because that parts can't be scaled for now. But they were never scaled before because they are being quarantined for a long time, and before that your game would be crashing when using them. But send me this new KSP.log anyway, so I can try to priorize the tasks I need to do to get rid of those quarantines (it usually involves writing code to support new things). If the window vanished after 30 seconds, it was not a Show Stopper. It was a warning or am advising, otherwise it would be bugging your screen, getting on the way and preventing you to even start a game without you actively closing it. The countdown stops by clicking on the window. Then the window will stay there until you close it or until you start a new game, switching scenarios. By the figure you gave, 9, it should be the Stock parts I do not support yet because they use a thing called MODULEVARIANTPART that has mass, and TweakScale doesn't know yet how to scale these parts. These will be tacked down on TweakScale 2.4.4.x series. (There's one more 2.4.3.x release planned with some more weird but happily rare situations handled, and then I will work on the 2.4.4.x series). — — — addendum — — — Got it. [LOG 22:28:18.501] [TweakScale] INFO: TweakScale::WriteDryCost: Concluded : 0 checks failed ; 0 parts with issues overruled ; 7 Show Stoppers found; 50 Sanity Check failed; Let's see that 7 Show Stoppers first: [LOG 22:28:18.481] [TweakScale] WARNING: **FATAL** Found a showstopper problem on batteryBankMini (Z-200 Rechargeable Battery Bank). [LOG 22:28:18.481] [TweakScale] ERROR: **FATAL** Part batteryBankMini (Z-200 Rechargeable Battery Bank) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 22:28:18.492] [TweakScale] WARNING: **FATAL** Found a showstopper problem on SXTInlineAirIntake (XM-600 1.25m Air Intake). [LOG 22:28:18.492] [TweakScale] ERROR: **FATAL** Part SXTInlineAirIntake (XM-600 1.25m Air Intake) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 22:28:18.492] [TweakScale] WARNING: **FATAL** Found a showstopper problem on SXTWingSmall (non RO (RP-0 yes) - Mk0B Small Modular Wing). [LOG 22:28:18.492] [TweakScale] ERROR: **FATAL** Part SXTWingSmall (non RO (RP-0 yes) - Mk0B Small Modular Wing) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 22:28:18.492] [TweakScale] WARNING: **FATAL** Found a showstopper problem on SXTWingLarge (non RP-0 - FAT-460 Super-Lift Aeroplane Main Wing). [LOG 22:28:18.492] [TweakScale] ERROR: **FATAL** Part SXTWingLarge (non RP-0 - FAT-460 Super-Lift Aeroplane Main Wing) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 22:28:18.494] [TweakScale] WARNING: **FATAL** Found a showstopper problem on SXTOsaulNoseCockpitAn225 (An-124 Cockpit). [LOG 22:28:18.494] [TweakScale] ERROR: **FATAL** Part SXTOsaulNoseCockpitAn225 (An-124 Cockpit) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 22:28:18.494] [TweakScale] WARNING: **FATAL** Found a showstopper problem on SXTOsualRadCockpit (An-124 Cockpit Radial). [LOG 22:28:18.494] [TweakScale] ERROR: **FATAL** Part SXTOsualRadCockpit (An-124 Cockpit Radial) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 22:28:18.499] [TweakScale] WARNING: **FATAL** Found a showstopper problem on SXTtruckbox (non RP-0 - Truck Box). [LOG 22:28:18.499] [TweakScale] ERROR: **FATAL** Part SXTtruckbox (non RP-0 - Truck Box) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). The "good news" is that these are already diagnosed. The batteryBankMini is borking due a patch on ROs, see this post about how to fix. There's a lot of potential problems on the RO's patch, and unfortunately I lack the time to proper support TweakScale and also propose fixes for RO's patches, so I kindly ask you to reach RO's maintainers about the issue, pinpointing this post as a source of information. The remaining ones are SXT, and they were also diagnosed and I think it's all fixed too. Download the latest SXT (currently 0.3.28.2), and if anything are still broken, kick me here and I will check it for you. That 50 Sanity Checks are more than an annoyance, however. I'm sorry for that. Some parts are in need of proper TweakScale support, what will happen in the next 2.4.4.x releases. But most of them, however, are happening due having a deadly mix of Fuel Switches on the same part. It's not exactly a defect on the Fuel Switches, but a fail on living together - what's not exactly a fail after all, as the part should have only one Fuel Switch applied to it! So, really, it's a problem of patches being applied without regards of already existing patches. I talked about it here, for reference. Unfortunately, my best and only advise is to choose a Fuel Switch and stick with it, and uninstall the others. Firespitter appears to be the One those everybody knows how to deactivate or coexist with, so this one you can leave alone. But from all the others, the easy way out for now is to choose only one of them and uninstall the others. You could have all of them installed if patches didn't try to apply all of them on the same part - this is the problem (patches that add more than one Fuel Switch to a part), but the easiest way out of the mess is to not have more than one installed, so even if a rogue patch apply them, it will not be effective and the problem will not happen. Kick me here if something else happens.

They don't breath oxygen. They need it to keep their molecular integrity. Once their skin lose contact with the oxygen, their skin's cells' membrane disintegrates, exposing the cytoplasm to the cell's membranes from the rest of their bodies. That cytoplasm is highly volatile, and the subtle expansion steals heat from the adjacent cells, leading to the membrane's rupture of that cells, exposing the cytoplasm, what feedbacks into a chain reaction that ends up disintegrating the whole body into a cloud of smoke. This is the reason they are resilient to impacts. As long the impact does not compress the skin against something to the point all the oxygen is expeled, they're good. The Forces of Nature that somehow reintegrates them on the KSP's Astronaut Complex after some hours are yet to be explained. It's believed to be related to a phenomena called "Game Option" - but nobody is really sure about what such thing really is. Some hypothesis about Krakens and Users were in vogue for some time, but currently the Theory of Configurabilty is the most accepted explanation for the phenomena, besides all the equations failing miserably at the Event Horizon - the Frontier of the Artificial Reality where all the keystrokes and mouse clicks are lost and nothing more exists beyound NaNs and INFs through infinite divisions by zero.

Full KSP.log and ModuleManager.ConfigCache when available.

I found what follows on your log: [EXC 07:40:32.161] NullReferenceException: Object reference not set to an instance of an object SaturableRW.SaturableRW.UpdateMomentum () SaturableRW.SaturableRW.FixedUpdate () [EXC 07:40:32.161] NullReferenceException: Object reference not set to an instance of an object SaturableRW.SaturableRW.UpdateMomentum () SaturableRW.SaturableRW.FixedUpdate () [EXC 07:40:32.175] NullReferenceException: Object reference not set to an instance of an object SaturableRW.SaturableRW.UpdateMomentum () SaturableRW.SaturableRW.FixedUpdate () [EXC 07:40:32.175] NullReferenceException: Object reference not set to an instance of an object SaturableRW.SaturableRW.UpdateMomentum () SaturableRW.SaturableRW.FixedUpdate () [EXC 07:40:32.188] NullReferenceException: Object reference not set to an instance of an object SaturableRW.SaturableRW.UpdateMomentum () SaturableRW.SaturableRW.FixedUpdate () [EXC 07:40:32.189] NullReferenceException: Object reference not set to an instance of an object SaturableRW.SaturableRW.UpdateMomentum () SaturableRW.SaturableRW.FixedUpdate () [ERR 07:40:32.205] Module tjs_DecouplerLight threw during OnUpdate: System.TypeLoadException: Could not load type 'ModuleDecouplerBase' from assembly 'EngineLightRelit'. at Part.ModulesOnUpdate () [0x00000] in <filename unknown>:0 What hints me a problem with SaturableRW and EngineLightRelit, whatever these things are. I also found: [LOG 07:10:35.533] PartLoader: Compiling Part 'StationPartsExpansionRedux/Parts/Extendable/extendable-125/sspx-inflatable-centrifuge-125-1/sspx-inflatable-centrifuge-125-1' [ERR 07:10:35.616] Module ModuleFuelTanks threw during OnLoad: System.ArgumentNullException: Argument cannot be null. Parameter name: key at System.Collections.Generic.Dictionary`2[System.String,RealFuels.Tanks.TankDefinition].ContainsKey (System.String key) [0x00000] in <filename unknown>:0 at System.Collections.ObjectModel.KeyedCollection`2[TKey,TItem].Contains (.TKey key) [0x00000] in <filename unknown>:0 at RealFuels.Tanks.ModuleFuelTanks.RecordTankTypeResources (System.Collections.Generic.HashSet`1 resources, System.String type) [0x00000] in <filename unknown>:0 at RealFuels.Tanks.ModuleFuelTanks.RecordManagedResources () [0x00000] in <filename unknown>:0 at RealFuels.Tanks.ModuleFuelTanks.OnLoad (.ConfigNode node) [0x00000] in <filename unknown>:0 at PartModule.Load (.ConfigNode node) [0x00000] in <filename unknown>:0 What hints me this can be the source of the problem. What you describes happens when Fuel Switches have problems while they are computing the resulting mass of a part, and we have evidences that something (usually a problematic patch!) is inducing RealFuels to a exception. Except that the guy DOES NOT have TweakScale installed. TweakScale is, usually, the Screaming Victim of that occurrences. Most of the time, it's a Fuel Switch problem that TweakScale gets involved because TweakScale are installed in all the parts of a system - and so, they are always involved on the mess because every part have it, as well the problematic third party Add'On.

Yep. 8 Show Stoppers. [LOG 16:26:32.606] [TweakScale] WARNING: **FATAL** Found a showstopper problem on M2X.Endcap (Mk2 Airlock Adapter Endcap). [LOG 16:26:32.607] [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 16:26:32.705] [TweakScale] WARNING: **FATAL** Found a showstopper problem on MEMLander (Munar Excursion Module (M.E.M.)). [LOG 16:26:32.705] [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 16:26:32.714] [TweakScale] WARNING: **FATAL** Found a showstopper problem on SXTInlineAirIntake (XM-600 1.25m Air Intake). [LOG 16:26:32.714] [TweakScale] ERROR: **FATAL** Part SXTInlineAirIntake (XM-600 1.25m Air Intake) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 16:26:32.714] [TweakScale] WARNING: **FATAL** Found a showstopper problem on SXTWingSmall (Mk0B Small Modular Wing). [LOG 16:26:32.714] [TweakScale] ERROR: **FATAL** Part SXTWingSmall (Mk0B Small Modular Wing) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 16:26:32.714] [TweakScale] WARNING: **FATAL** Found a showstopper problem on SXTWingLarge (FAT-460 Super-Lift Aeroplane Main Wing). [LOG 16:26:32.714] [TweakScale] ERROR: **FATAL** Part SXTWingLarge (FAT-460 Super-Lift Aeroplane Main Wing) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 16:26:32.719] [TweakScale] WARNING: **FATAL** Found a showstopper problem on SXTOsaulNoseCockpitAn225 (Kn-225 "Osaul Payload" Cockpit). [LOG 16:26:32.719] [TweakScale] ERROR: **FATAL** Part SXTOsaulNoseCockpitAn225 (Kn-225 "Osaul Payload" Cockpit) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 16:26:32.720] [TweakScale] WARNING: **FATAL** Found a showstopper problem on SXTOsualRadCockpit (Mk.P-Yavka Radial Cockpit). [LOG 16:26:32.720] [TweakScale] ERROR: **FATAL** Part SXTOsualRadCockpit (Mk.P-Yavka Radial Cockpit) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 16:26:32.733] [TweakScale] WARNING: **FATAL** Found a showstopper problem on SXTtruckbox (Truck Box). [LOG 16:26:32.733] [TweakScale] ERROR: **FATAL** Part SXTtruckbox (Truck Box) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). This appears to be something, these parts didn't got Fatalities around here yet. Let's check them: The M2X_EndCap TweakScale patches are being applied twice: [LOG 16:19:23.035] Config(@PART[M2X_Endcap]:NEEDS[TweakScale]) Mk2Expansion/Patches/M2X_Tweakscale/@PART[M2X_Endcap]:NEEDS[TweakScale] [LOG 16:19:23.036] Config(@PART[M2X_Endcap]:NEEDS[TweakScale]) Mk2Expansion/Patches/M2X_Tweakscale/@PART[M2X_Endcap]:NEEDS[TweakScale] I initially though it was a wildcard problem, let's see the patch: <line 155> @PART[M2X_Endcap]:NEEDS[TweakScale] { %MODULE[TweakScale] { type = stack defaultScale = 1.25 } } ... ... ... <494> @PART[M2X_Endcap]:NEEDS[TweakScale] { %MODULE[TweakScale] { type = stack defaultScale = 1.25 } } But I was wrong. The patching is being applied two times. Well, the fix is obvious: delete de second patch. I applied a pull request to the Maintainer with the fix, and until a new release is issued, you can download the fixed file here (click "Raw") and replace the current file in GameData/Mk2Expansion/Mk2Expansion/GameData/Mk2Expansion/Patches/M2X_Tweakscale.cfg . [and told the Maintainer this time! ] This fix one problem. There're 7 more to go. The next problem is MEMLander (Munar Excursion Module (M.E.M.)) : Initially I was confused because I didn't found how SXT patches would double patch the Stock's MEMLander from Making History. But then I realized than one month ago the Maintainers fixed a problem on the SXT's MEMLander to rename it to MEMLanderSXT and things made sense. From your log I learnt that you are using SXT Continued 0.3.23.7, while the SXT Release is the 0.3.28.2 . I suggest you to update SXT. I think this will fix all the other errors, as they are all related to SXT and the latests release has fixes for TweakScale. Please publish the new KSP.log , so I can hunt them down.

Ah! Found it! This is where it started! On the good news, it's not TweakScale neither. It doesn't touch the joints. I nailed down the occurrence, and apparently is not a problem on an Add'On itself, but race condition between KSP and an Add'On. I didn't got into the root of the problem yet, so I'm restraining myself to talk further on the matter - I may be wrong on the Add'On that may be triggering the problem. But what I can say for sure is that there's a very interesting condition in @falcoon's savegame in which two crafts are packed at the same time, and then it is unpacked. Exactly after that, one of the crafts explodes due losing its joints and having all its parts colliding at the same time (this is the reason of all that NRE on the PartJoint). Why it's happening now, and not before? This is where I need to start guessing, but there're more concurrency nowadays on KSP than there were in the past (what's good, because we already reached the performance ceiling on a single CPU's thread). Since it can happens (about once each 30 times) that the vessel does not explode makes me hint that there's a sweet spot that can be exploited to avoid that race condition, at least for now. It's what I'm working when I have the time. The bad news is that I haven't enough time for it. (but I still on it)

Hi! TweakScale maintainer here. Nice patch. But may I give a suggestion? Do not use ":FOR" in your patches. This ":FOR" thingy are how we say "this is a default patch from TweakScale that should be applied first", while ":NEEDS" says "I'm a part that needs TweakScale fully initialized before me so I can use it without glitches". I would also change "type" to "%type", so in the event someone else apply a patch for TweakScale to the same part, the part would not be double patched, what will trigger the "Houston" message on TweakScale 2.4.3.0 and newer. Cheers!

Yep. The problem is the physical values for the whole shebang. You use the "mean", more resistant parts lose its resistance, and you can't rely on them. And the other way around, weak parts become too stronger. Ubiozur has some options about how to infer the physics values for the new parts. But the default ones are very… "on the safe side"… and it ends up usually causing what you describe. I found Ubiozur useful to build large maritime and airborne ships. I like to try to build them as real life, with keel and all. So I weld structural parts - usually, all the same part - to make the keel. Then I apply griders and flangers where it's possible, and attach the utilitiy parts (living room, cargo, etc) on them. Autostruts is only applied to the structural parts and EAS struts to "weld" some things tight on more than one structural part (as on intersecations between griders and flanges). Well, you got it. These stunts make the vessels behave way closer to the real ones when failing making the incidents sometimes uncomfortably realistic.

The problems happens when you use the parts. But with 51 parts to be worry about, you end up using them sooner or later. BUT… In your case, you are really fine: [LOG 23:33:12.800] Load(Model): Squad/Parts/Coupling/Assets/Decoupler_1p5 [LOG 23:33:31.239] Config(@PART[Decoupler_1p5]:FOR[DecouplerShroud]:NEEDS[SquadExpansion]) DecouplerShroud/Patches/SquadExpansionPatches/@PART[Decoupler_1p5]:FOR[DecouplerShroud]:NEEDS[SquadExpansion] [LOG 23:33:31.313] Config(@PART[Decoupler_1p5]) ReStock/PatchesMH/Coupling/restock-mh-decouplers/@PART[Decoupler_1p5] [LOG 23:33:31.335] Config(PART) SquadExpansion/MakingHistory/Parts/Coupling/Decoupler_1p5/Decoupler_1p5 [LOG 23:33:31.374] Config(@PART[Decoupler_1p5]) TweakScale/patches/SquadExpansion/MakingHistory/Coupling/@PART[Decoupler_1p5] [LOG 23:33:31.375] Config(@PART[Decoupler_1p5]) TweakscaleMakingHistoryConfigs/Coupling/@PART[Decoupler_1p5] It's that TweakscaleMakingHistoryConfigs again . Delete GameData/TweakscaleMakingHistoryConfigs and everything will be fine. The last fellow Kerbonaut that had this issue told me that deleting this didn't caused any side effect. I still don't know what this thing is. Well, I think I do - it appears to be patches for Making History parts. The part count fits, at least. I just don't know from where.

Yep. Got it. [LOG 00:13:39.550] [TweakScale] WARNING: **FATAL** Found a showstopper problem on nesdIntRcsSep.LES (LES Tower motor). [LOG 00:13:39.550] [TweakScale] ERROR: **FATAL** Part nesdIntRcsSep.LES (LES Tower motor) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). Humm… Interesting. That's a new: [LOG 00:08:42.925] Config(PART) InternalRCS/Parts/RCS2/SE-PR/nesdIntRcsSep [LOG 00:08:42.927] Config(@PART[nesdIntRcsSep]:FOR[RealPlume]) KSA/MM Changes/@PART[nesdIntRcsSep]:FOR[RealPlume] [LOG 00:08:42.927] Config(@PART[nesdIntRcsSep]:FINAL) KSA/MM Changes/@PART[nesdIntRcsSep]:FINAL [LOG 00:08:42.927] Config(+PART[nesdIntRcsSep]:FINAL) KSA/MM Changes/+PART[nesdIntRcsSep]:FINAL [LOG 2019-08-03 00:07:11.030] Applying update KSA/MM Changes/@PART[nesdIntRcsSep]:FOR[RealPlume] to InternalRCS/Parts/RCS2/SE-PR.cfg/PART [LOG 2019-08-03 00:07:15.952] Applying update KSA/MM Changes/@PART[nesdIntRcsSep]:FINAL to InternalRCS/Parts/RCS2/SE-PR.cfg/PART [LOG 2019-08-03 00:07:15.952] Applying copy KSA/MM Changes/+PART[nesdIntRcsSep]:FINAL to InternalRCS/Parts/RCS2/SE-PR.cfg/PART [LOG 00:09:44.271] PartLoader: Compiling Part 'InternalRCS/Parts/RCS2/SE-PR/nesdIntRcsSep' [LOG 00:09:44.311] PartLoader: Part 'InternalRCS/Parts/RCS2/SE-PR/nesdIntRcsSep' has no database record. Creating. [LOG 00:09:44.319] DragCubeSystem: Creating drag cubes for part 'nesdIntRcsSep' [LOG 00:09:44.412] PartLoader: Compiling Part 'InternalRCS/Parts/RCS2/SE-PR/nesdIntRcsSep_LES' [LOG 00:09:44.458] PartLoader: Part 'InternalRCS/Parts/RCS2/SE-PR/nesdIntRcsSep_LES' has no database record. Creating. [LOG 00:09:44.464] DragCubeSystem: Creating drag cubes for part 'nesdIntRcsSep.LES' [LOG 00:13:39.550] [TweakScale] WARNING: **FATAL** Found a showstopper problem on nesdIntRcsSep.LES (LES Tower motor). [LOG 00:13:39.550] [TweakScale] ERROR: **FATAL** Part nesdIntRcsSep.LES (LES Tower motor) has a fatal problem due having duplicated properties - see Apparently the problem is on that KSA//MM Changes. The ConfigCache will tell us exactly what's wrong, and this will make easier to search the problem on the KSA/MM Changes . That I'm afraid I don't know where to look for.

Dancing Queen, ABBA… oh, wait..

That was a KSP 1.5.1 log, using TweakScale 2.4.0. [LOG 19:22:52.837] AssemblyLoader: Loading assembly at D:\Steam Games\steamapps\common\Kerbal Space Program\GameData\TweakScale\Plugins\Scale.dll [LOG 19:22:52.845] AssemblyLoader: KSPAssembly 'Scale' V2.4.0 ... ... Scale v2.4.0.6 I think you sent me the wrong log. May I make a suggestion? Make a full copy of your KSP 1.5.1, install TweakScale 2.4.3.1 on that discardable copy, launch it and then send me this log (and the ConfigCache) if a Houston pops up? Anything wrong, we can hand craft a patch to keep your savegames ongoing on the new KSP version. (I call that patches "OVERRULES").

What's a good computer? i5 with two cores and 4 HTs at 2.7GHz used to be good enough, but after some security patches from Apple to my MacMini (that nowadays are worse than the problem they aim to fix), I had to trim down a lot of things that used to run better earlier. Even recording gaming sessions are now impacting heavily the FPS, when before it was barely noticeable. Try to reduce the Texture Quality to 1/4 . It worked to me, at least.

Ugh. Thare're some serious Toe Stomping Fest on your installment! [LOG 20:21:49.537] [TweakScale] INFO: TweakScale::WriteDryCost: Concluded : 932 checks failed ; 0 parts with issues overruled ; 1 Show Stoppers found; 11 Sanity Check failed; That 932 checks failed means that something made TweakScale bork while trying to see the part's guts. It's not a danger by itself, but it prevents me to check that parts to see what's inside. These parts are also borking on the DryCostWrite - and this is something else to be concerned. That 11 Sanity Checks failed are parts not being supported yet. You can ignore it for now. Well… Let's check what we can fix for now, there's not much that we can do about that 932 right now. It's a Toe Stomping Fest, and I will address this later. The part with the Show Stopper, batteryBankMini, is being patched as follows: [LOG 20:04:47.740] Config(@PART[batteryBankMini]:FOR[RealismOverhaul]) RealismOverhaul/RO_SuggestedMods/Squad/RO_Squad_Electrical/@PART[batteryBankMini]:FOR[RealismOverhaul] [LOG 20:04:48.048] Config(@PART[batteryBankMini]:FOR[xxxRP0]) RP-0/Tree/TREE-Parts/@PART[batteryBankMini]:FOR[xxxRP0] [LOG 20:04:48.086] Config(PART) Squad/Parts/Electrical/z-200Battery/z-200Battery/batteryBankMini [LOG 20:04:48.155] Config(@PART[batteryBankMini]) TweakScale/patches/Squad/Squad_Util/@PART[batteryBankMini] [LOG 20:04:48.161] Config(@PART[batteryBankMini]) VenStockRevamp/Squad/Parts/Electrical/@PART[batteryBankMini] [LOG 2019-08-02 20:03:44.108] Applying update TweakScale/patches/Squad/Squad_Util/@PART[batteryBankMini] to Squad/Parts/Electrical/z-200Battery/z-200Battery.cfg/PART [LOG 2019-08-02 20:03:46.099] Applying update VenStockRevamp/Squad/Parts/Electrical/@PART[batteryBankMini] to Squad/Parts/Electrical/z-200Battery/z-200Battery.cfg/PART [LOG 2019-08-02 20:04:52.806] Applying update RealismOverhaul/RO_SuggestedMods/Squad/RO_Squad_Electrical/@PART[batteryBankMini]:FOR[RealismOverhaul] to Squad/Parts/Electrical/z-200Battery/z-200Battery.cfg/PART [LOG 2019-08-02 20:06:30.992] Applying update RP-0/Tree/TREE-Parts/@PART[batteryBankMini]:FOR[xxxRP0] to Squad/Parts/Electrical/z-200Battery/z-200Battery.cfg/PART [LOG 20:10:37.996] PartLoader: Compiling Part 'Squad/Parts/Electrical/z-200Battery/z-200Battery/batteryBankMini' [LOG 20:10:38.040] PartLoader: Part 'Squad/Parts/Electrical/z-200Battery/z-200Battery/batteryBankMini' has no database record. Creating. [LOG 20:10:38.044] DragCubeSystem: Creating drag cubes for part 'batteryBankMini' [LOG 20:14:08.115] [DRE] skipping part batteryBankMini (leaveTemp = True) [LOG 20:16:30.559] [TweakScale] WARNING: **FATAL** Found a showstopper problem on batteryBankMini (Z-200 Rechargeable Battery Bank). [LOG 20:16:30.559] [TweakScale] ERROR: **FATAL** Part batteryBankMini (Z-200 Rechargeable Battery Bank) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). And thanks a lot for the ConfigCache! It helps to nail down the source of the problem! UrlConfig { parentUrl = Squad/Parts/Electrical/z-200Battery/z-200Battery PART { name = batteryBankMini module = Part author = Squad <yadda yadda yadda> MODULE { name = TweakScale type = stack defaultScale = 0.625 type = RealismOverhaulStackSolid } <yadda yadda yadda> } } } You see that double "type" thingy? That's the problem. The canonical way to change values on a TweakScale module is by using "%" on the data name, that means "edit or create". By default, Module Manager adds the value. Every RO patch should look like this: @MODULE[TweakScale]:NEEDS[TweakScale] { %type = RealismOverhaulStackSolid } So you need to edit every RO patch to add that lines. For example: @PART[batteryBankMini]:FOR[RealismOverhaul] // Good for ReStock { %RSSROConfig = True @RESOURCE[ElectricCharge] { @amount = 20500 @maxAmount = 20500 } @mass = 0.07731 @MODULE[TweakScale] { type = RealismOverhaulStackSolid } } Should be edited to: @PART[batteryBankMini]:FOR[RealismOverhaul] // Good for ReStock { %RSSROConfig = True @RESOURCE[ElectricCharge] { @amount = 20500 @maxAmount = 20500 } @mass = 0.07731 @MODULE[TweakScale]:NEEDS[TweakScale] { %type = RealismOverhaulStackSolid } } There's currently about 330 issues exactly like that problematic one on the RO's patches. 338 edits are a bit too much to be done on the scarce time I have to handle these issues on a single WeekEnd. So I will need to ask you for patience as I tackle down them as the time allows. Alternatively, you can edit the files yourself? Then you could apply a pull request to the Maintainers and have this fixed for everybody!

Yep. That's it. Thanks. I found 17 Show Stoppers on your installment. For reference, below is every occurrence of one of the parts affected, truss-octo-01 (Octo-Girder Modular Truss D (XL)). It's a Part from NearFutureConstruction. It's being patched by a lot of Add'Ons, but what caught my attention is TweakScale (TweakScale/patches/NFT_TweakScale) and Contares (Contares/Patches/CONTARES_TweakScale). It's a hunch, as you have a lot of Add'Ons applying patches to the offending Parts, but I need to start somewhere I found contares on SpaceDock, but then I realized that it was split in modules. By the name of the offending patch, I think you are using the 1.8.9 version (the last one before the big split). But the new versions also have the problem: they patch parts without checking if they were patched before (it doesn't even checks if TweakScale is installed, using :NEEDS): @PART[RCS_45_0_0_0] // RCS-Modul { %MODULE[TweakScale] { type = stack defaultScale = 1.25 } } The same happens to Contares Core (the newest versions) unfortunately: @PART[MICRO_GABUN] { %MODULE[TweakScale] { type = stack defaultScale = 0.625 } } Add'Ons willing to overrule TweakScale patches (being the default ones provided with the Distribution, or provided by third parties) needs the :NEEDS in order to prevent applying useless patches. But also need to prevent double patching by not applying their patches if the part is already patched (unlikely ) or by making sure to overwrite (or plain delete) the previous one. Otherwise, people like you will have to handle this situation. Currently, you are in risk of having your flying crafts corrupted if you install or uninstall an Add'On. Since Contares doesn't use :NEEDS, they are being applied first (as "C" cames before "T" , and patches without :FOR, :NEEDS, :AFTER or :BEFORE are applied in legacy mode by Module Manager - essentially. by alphabetical order). So TweakScale patches were applied second, and now these are de dominant ones - when multiple Add'Ons tries to patch the same Part without regard of others, the last one is the one ruling TweakScale. Anything changes, and your flying parts goes kaput, as the images below depicts: This will happens to your craft files, but also on the crafts flying on you persistant savefile! The final and definitive solution for the problem is to ask Contares maintainer to edit every TweakScale patch they apply to what follows: @PART[truss-octo-*]:NEEDS[TweakScale]:FINAL // Final is not the recomended way, it should be :AFTER[TweakScale] but I need to implement :FOR on TweakScale first! { -MODULE[TweakScale],* %MODULE[TweakScale] { type = stack // Or whatever value they want defaultScale = 2.5 // Ditto } } (both in the Classic Contares that you are using, as the newest Contares Core and plugins). This will ensure the patch will only be applied when TweakScale is present, and will ensure that any previously patched part will be cleaned up - making sure that whatever the Add'on Author uses, will be used without causing collateral effects. Unfortunately, Contares doesn't provides a Github, Bitbucket or any other Code Hosting service, so I'm unable to apply the patches my self as I made earlier. I can't help you further neither. The patches ruling TweakScale for now (as installing an new Add'On can change things!) is the default ones. You can try deleting GameData/TweakScale/patches/NFT_TweakScale.cfg . It appears to be a quick&dirty workaround, but this can break any craft you have made (including the flying ones). I think you should install S.A.V.E. before trying this. Until Contares' Maintainer fix the patches, you will need to remember to delete that file every time you update TweakScale.