Lisias

Well.. So I removed the InterstellarFuelSwitch and added back WarpPlugin IFS is not needed by this part (so it was ruled out of the problem anyway), and the WarpPlugin have the PartModules needed by the part. Unsurprisingly, the problem is back. So, yeah, we have our suspect, WarpPlugin - more specifically, one of above mentioned PartModule. So I removed IntegratedThermalElectricPowerGenerator from the part and tried again to see what happens. Bull's eye! The problem is gone. So we found the culprit. But why this is affecting only IT? Follows the KSPIE parts also using it: ./WarpPlugin/Parts/BeamedPower/PhasedArray/phasedArray1/MunSeeker_ZZZ_RadioTelescope_Contracts.cfg ./WarpPlugin/Parts/BeamedPower/Thermal/OversizeFoldingDishAluminium/SIGINT.cfg ./WarpPlugin/Parts/BeamedPower/Thermal/OversizeFoldingDishAluminium/SIGINT_End.cfg ./WarpPlugin/Parts/BeamedPower/Thermal/OversizeFoldingDishGold/SIGINT.cfg ./WarpPlugin/Parts/BeamedPower/Thermal/OversizeFoldingDishGold/SIGINT_End.cfg ./WarpPlugin/Parts/BeamedPower/Thermal/OversizeFoldingDishGold/SIGINTEnd.cfg ./WarpPlugin/Parts/BeamedPower/Thermal/SolarPowerMoltenSalt/SolarPower_MoltenSalt.cfg ./WarpPlugin/Parts/BeamedPower/Thermal/InlineThermalReceiverPanel/MW_TR_DI.cfg ./WarpPlugin/Parts/Electrical/AntimatterCore/WarpCoreUnit2.cfg ./WarpPlugin/Parts/Electrical/AntimatterCore/WarpCoreUnit.cfg ./WarpPlugin/Parts/Electrical/FissionReactor/fissionreactor.cfg ./WarpPlugin/Parts/Electrical/QuantumSingularityReactor2/QuantumSingulaityReactor.cfg ./WarpPlugin/Parts/Electrical/IXSMainHull/IXSMainHull.cfg ./WarpPlugin/Parts/Electrical/MuonCatFusionReactor2/StnSciSpectro.cfg ./WarpPlugin/Parts/Engines/SURGE/OPT_SURGE.cfg So, why nobody complained about this problem before? Logic suggests that these parts are also affected. So I reinstalled things back and tried one of these parts too. I randomly choose "Antimatter Catalyzed Fusion Reactor", the kspiWarpCoreUnit2 on WarpCoreUnit2.cfg. I took the very same rbug.craft file, and replaced the Interstellar-Technologies-ICFSC-Reactor with the kspiWarpCoreUnit2 and then scaled it up to 5M. No problem detected, the refunding happened exactly as expected. @GoAHead, this settles the matter: Interstellar Technologies appears to be at fault here. The very same PartModule that is triggering the problem on IT parts works fine on KSPIE ones. There's something missing on their parts, perhaps? Or perhaps they are using something that is broken on the IntegratedThermalElectricPowerGenerator PartModule and by plain luck (or knowledge) it's not used on KSPIE. In a way or another, I suggest you reach the IT guys and talk about the problem. I can't further help on this by myself. Good luck!

Music for times of war:

I know. But I need to do the tests progressivelly, otherwise I would had a really harsh time diagnosing the problem. For starters, I detected that Interstellar Technologies 0.4.1 (the latest available on SpaceDock), has some outdated add'ons compared with KSPIe latest (1.29.6 on SpaceDock). If you just unzipped IT0.4.1 over KSPIE1.29.6, you downgraded the following add'ons: CommunityResourcePack CommunityTechTree InterstellarFuelSwitch KerbalEngineer WarpPlugin Waterfall What can be the source of your problems. Right now I'm firing up KSP 1.12.5 with KSPIE and IT installed in order to check your case. Outdated add'ons weren't installed, I'm using whatever KSPIE installed on my rig. I also didn't updated IFS to 3.30, as I have words that 3.30 somehow broke TS or something else that sou broke TS, and I will utilize this test session to check it too. I will update this post as soon as I have some results. — POST EDIT — Unsurprisingly, TweakScale wasn't able to check some parts due errors on them: [LOG 02:53:19.454] [TweakScale] "TweakScale warning" about check failures was displayed <...> [LOG 02:53:19.225] [TweakScale] ERROR: part=Interstellar-Technologies.AMCatGasdynamicMirror (KSPIT KR-342 AM Cat. Gasdynamic Mirror Cell Fusion Drive) Exception on Sanity Checks: System.NullReferenceException: Object reference not set to an instance of an object at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x00000] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CreateCopy () [0x00006] in <106570632fc343a784fad39e75e877bf>:0 at GameDatabase.GetConfigNode (System.String url) [0x0002f] in <106570632fc343a784fad39e75e877bf>:0 at TweakScale.PrefabDryCostWriter.GetMeThatConfigNode (Part p) [0x0002a] in <62ab179107a144c5a3808f0cd36a9f76>:0 at TweakScale.PrefabDryCostWriter.checkForOverrules (Part p) [0x00000] in <62ab179107a144c5a3808f0cd36a9f76>:0 at TweakScale.PrefabDryCostWriter+<WriteDryCost>d__3.MoveNext () [0x00417] in <62ab179107a144c5a3808f0cd36a9f76>:0 at error:0 [LOG 02:53:19.227] [TweakScale] ERROR: part=Interstellar-Technologies.AM-Catalyzed-ICFE (KSPIT KR-250 Antimatter Catalyzed Inertial Confinement Fusion Drive) Exception on Sanity Checks: System.NullReferenceException: Object reference not set to an instance of an object at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x00000] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CreateCopy () [0x00006] in <106570632fc343a784fad39e75e877bf>:0 at GameDatabase.GetConfigNode (System.String url) [0x0002f] in <106570632fc343a784fad39e75e877bf>:0 at TweakScale.PrefabDryCostWriter.GetMeThatConfigNode (Part p) [0x0002a] in <62ab179107a144c5a3808f0cd36a9f76>:0 at TweakScale.PrefabDryCostWriter.checkForOverrules (Part p) [0x00000] in <62ab179107a144c5a3808f0cd36a9f76>:0 at TweakScale.PrefabDryCostWriter+<WriteDryCost>d__3.MoveNext () [0x00417] in <62ab179107a144c5a3808f0cd36a9f76>:0 at error:0 [LOG 02:53:19.229] [TweakScale] ERROR: part=Interstellar-Technologies.AM-Catalyzed-MIFE (KSPIT KR-129 Antimatter Catalyzed Magneto Inertial Fusion engine) Exception on Sanity Checks: System.NullReferenceException: Object reference not set to an instance of an object at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x00000] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CreateCopy () [0x00006] in <106570632fc343a784fad39e75e877bf>:0 at GameDatabase.GetConfigNode (System.String url) [0x0002f] in <106570632fc343a784fad39e75e877bf>:0 at TweakScale.PrefabDryCostWriter.GetMeThatConfigNode (Part p) [0x0002a] in <62ab179107a144c5a3808f0cd36a9f76>:0 at TweakScale.PrefabDryCostWriter.checkForOverrules (Part p) [0x00000] in <62ab179107a144c5a3808f0cd36a9f76>:0 at TweakScale.PrefabDryCostWriter+<WriteDryCost>d__3.MoveNext () [0x00417] in <62ab179107a144c5a3808f0cd36a9f76>:0 at error:0 [LOG 02:53:19.230] [TweakScale] ERROR: part=Interstellar-Technologies.AM-Catalyzed-ICFE-Afterburning (KSPIT KN-162 Afterburning AM Cat ICFE) Exception on Sanity Checks: System.NullReferenceException: Object reference not set to an instance of an object at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x00000] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CreateCopy () [0x00006] in <106570632fc343a784fad39e75e877bf>:0 at GameDatabase.GetConfigNode (System.String url) [0x0002f] in <106570632fc343a784fad39e75e877bf>:0 at TweakScale.PrefabDryCostWriter.GetMeThatConfigNode (Part p) [0x0002a] in <62ab179107a144c5a3808f0cd36a9f76>:0 at TweakScale.PrefabDryCostWriter.checkForOverrules (Part p) [0x00000] in <62ab179107a144c5a3808f0cd36a9f76>:0 at TweakScale.PrefabDryCostWriter+<WriteDryCost>d__3.MoveNext () [0x00417] in <62ab179107a144c5a3808f0cd36a9f76>:0 at error:0 [LOG 02:53:19.232] [TweakScale] ERROR: part=Interstellar-Technologies.AM-Fusion-Engine ("Compression" Antimatter Catalyzed Fusion Engine) Exception on Sanity Checks: System.NullReferenceException: Object reference not set to an instance of an object at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x00000] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CreateCopy () [0x00006] in <106570632fc343a784fad39e75e877bf>:0 at GameDatabase.GetConfigNode (System.String url) [0x0002f] in <106570632fc343a784fad39e75e877bf>:0 at TweakScale.PrefabDryCostWriter.GetMeThatConfigNode (Part p) [0x0002a] in <62ab179107a144c5a3808f0cd36a9f76>:0 at TweakScale.PrefabDryCostWriter.checkForOverrules (Part p) [0x00000] in <62ab179107a144c5a3808f0cd36a9f76>:0 at TweakScale.PrefabDryCostWriter+<WriteDryCost>d__3.MoveNext () [0x00417] in <62ab179107a144c5a3808f0cd36a9f76>:0 at error:0 [LOG 02:53:19.233] [TweakScale] ERROR: part=Interstellar-Technologies.Antiproton-Catalyzed-Microfission (KSPIT NK-52 Antiproton catalyzed microfission drive) Exception on Sanity Checks: System.NullReferenceException: Object reference not set to an instance of an object at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x00000] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CreateCopy () [0x00006] in <106570632fc343a784fad39e75e877bf>:0 at GameDatabase.GetConfigNode (System.String url) [0x0002f] in <106570632fc343a784fad39e75e877bf>:0 at TweakScale.PrefabDryCostWriter.GetMeThatConfigNode (Part p) [0x0002a] in <62ab179107a144c5a3808f0cd36a9f76>:0 at TweakScale.PrefabDryCostWriter.checkForOverrules (Part p) [0x00000] in <62ab179107a144c5a3808f0cd36a9f76>:0 at TweakScale.PrefabDryCostWriter+<WriteDryCost>d__3.MoveNext () [0x00417] in <62ab179107a144c5a3808f0cd36a9f76>:0 at error:0 [LOG 02:53:19.235] [TweakScale] ERROR: part=Interstellar-Technologies.BeamCoreFusion (KSPIT KR-523 Beam Core Fusion Drive) Exception on Sanity Checks: System.NullReferenceException: Object reference not set to an instance of an object at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x00000] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CreateCopy () [0x00006] in <106570632fc343a784fad39e75e877bf>:0 at GameDatabase.GetConfigNode (System.String url) [0x0002f] in <106570632fc343a784fad39e75e877bf>:0 at TweakScale.PrefabDryCostWriter.GetMeThatConfigNode (Part p) [0x0002a] in <62ab179107a144c5a3808f0cd36a9f76>:0 at TweakScale.PrefabDryCostWriter.checkForOverrules (Part p) [0x00000] in <62ab179107a144c5a3808f0cd36a9f76>:0 at TweakScale.PrefabDryCostWriter+<WriteDryCost>d__3.MoveNext () [0x00417] in <62ab179107a144c5a3808f0cd36a9f76>:0 at error:0 [LOG 02:53:19.237] [TweakScale] ERROR: part=Interstellar-Technologies.Daedalus-ICF (KSP-IT Daedalus Fusion Drive) Exception on Sanity Checks: System.NullReferenceException: Object reference not set to an instance of an object at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x00000] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CreateCopy () [0x00006] in <106570632fc343a784fad39e75e877bf>:0 at GameDatabase.GetConfigNode (System.String url) [0x0002f] in <106570632fc343a784fad39e75e877bf>:0 at TweakScale.PrefabDryCostWriter.GetMeThatConfigNode (Part p) [0x0002a] in <62ab179107a144c5a3808f0cd36a9f76>:0 at TweakScale.PrefabDryCostWriter.checkForOverrules (Part p) [0x00000] in <62ab179107a144c5a3808f0cd36a9f76>:0 at TweakScale.PrefabDryCostWriter+<WriteDryCost>d__3.MoveNext () [0x00417] in <62ab179107a144c5a3808f0cd36a9f76>:0 at error:0 [LOG 02:53:19.238] [TweakScale] ERROR: part=Interstellar-Technologies-Kugelblitz-Drive (IT-547 Kugelblitz Drive) Exception on Sanity Checks: System.NullReferenceException: Object reference not set to an instance of an object at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x00000] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CreateCopy () [0x00006] in <106570632fc343a784fad39e75e877bf>:0 at GameDatabase.GetConfigNode (System.String url) [0x0002f] in <106570632fc343a784fad39e75e877bf>:0 at TweakScale.PrefabDryCostWriter.GetMeThatConfigNode (Part p) [0x0002a] in <62ab179107a144c5a3808f0cd36a9f76>:0 at TweakScale.PrefabDryCostWriter.checkForOverrules (Part p) [0x00000] in <62ab179107a144c5a3808f0cd36a9f76>:0 at TweakScale.PrefabDryCostWriter+<WriteDryCost>d__3.MoveNext () [0x00417] in <62ab179107a144c5a3808f0cd36a9f76>:0 at error:0 [LOG 02:53:19.240] [TweakScale] ERROR: part=Interstellar-Technologies.Laser-Core-Antimatter ("Pion" Laser core Antimatter Engine) Exception on Sanity Checks: System.NullReferenceException: Object reference not set to an instance of an object at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x00000] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CreateCopy () [0x00006] in <106570632fc343a784fad39e75e877bf>:0 at GameDatabase.GetConfigNode (System.String url) [0x0002f] in <106570632fc343a784fad39e75e877bf>:0 at TweakScale.PrefabDryCostWriter.GetMeThatConfigNode (Part p) [0x0002a] in <62ab179107a144c5a3808f0cd36a9f76>:0 at TweakScale.PrefabDryCostWriter.checkForOverrules (Part p) [0x00000] in <62ab179107a144c5a3808f0cd36a9f76>:0 at TweakScale.PrefabDryCostWriter+<WriteDryCost>d__3.MoveNext () [0x00417] in <62ab179107a144c5a3808f0cd36a9f76>:0 at error:0 [LOG 02:53:19.241] [TweakScale] ERROR: part=Interstellar-Technologies.Multi-Mode-Fusion-Engine ("Pressure" Multi-Mode Fusion Engine) Exception on Sanity Checks: System.NullReferenceException: Object reference not set to an instance of an object at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x00000] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CreateCopy () [0x00006] in <106570632fc343a784fad39e75e877bf>:0 at GameDatabase.GetConfigNode (System.String url) [0x0002f] in <106570632fc343a784fad39e75e877bf>:0 at TweakScale.PrefabDryCostWriter.GetMeThatConfigNode (Part p) [0x0002a] in <62ab179107a144c5a3808f0cd36a9f76>:0 at TweakScale.PrefabDryCostWriter.checkForOverrules (Part p) [0x00000] in <62ab179107a144c5a3808f0cd36a9f76>:0 at TweakScale.PrefabDryCostWriter+<WriteDryCost>d__3.MoveNext () [0x00417] in <62ab179107a144c5a3808f0cd36a9f76>:0 at error:0 [LOG 02:53:19.243] [TweakScale] ERROR: part=Interstellar-Technologies.Muon-Cat-Large (KSPIT MN-620 Muon Catalyzed Fusion Drive) Exception on Sanity Checks: System.NullReferenceException: Object reference not set to an instance of an object at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x00000] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CreateCopy () [0x00006] in <106570632fc343a784fad39e75e877bf>:0 at GameDatabase.GetConfigNode (System.String url) [0x0002f] in <106570632fc343a784fad39e75e877bf>:0 at TweakScale.PrefabDryCostWriter.GetMeThatConfigNode (Part p) [0x0002a] in <62ab179107a144c5a3808f0cd36a9f76>:0 at TweakScale.PrefabDryCostWriter.checkForOverrules (Part p) [0x00000] in <62ab179107a144c5a3808f0cd36a9f76>:0 at TweakScale.PrefabDryCostWriter+<WriteDryCost>d__3.MoveNext () [0x00417] in <62ab179107a144c5a3808f0cd36a9f76>:0 at error:0 [LOG 02:53:19.245] [TweakScale] ERROR: part=Interstellar-Technologies.Muon-Catalyzed-Fusion-Drive (KSP-IT KN-142 "Flare" Muon Catalyzed Fusion engine) Exception on Sanity Checks: System.NullReferenceException: Object reference not set to an instance of an object at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x00000] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CreateCopy () [0x00006] in <106570632fc343a784fad39e75e877bf>:0 at GameDatabase.GetConfigNode (System.String url) [0x0002f] in <106570632fc343a784fad39e75e877bf>:0 at TweakScale.PrefabDryCostWriter.GetMeThatConfigNode (Part p) [0x0002a] in <62ab179107a144c5a3808f0cd36a9f76>:0 at TweakScale.PrefabDryCostWriter.checkForOverrules (Part p) [0x00000] in <62ab179107a144c5a3808f0cd36a9f76>:0 at TweakScale.PrefabDryCostWriter+<WriteDryCost>d__3.MoveNext () [0x00417] in <62ab179107a144c5a3808f0cd36a9f76>:0 at error:0 [LOG 02:53:19.246] [TweakScale] ERROR: part=Interstellar-Technologies.Multi-Mode-SSTO-Engine ("Hybrid" Multi-Mode SSTO Fusion Engine) Exception on Sanity Checks: System.NullReferenceException: Object reference not set to an instance of an object at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x00000] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <106570632fc343a784fad39e75e877bf>:0 at ConfigNode.CreateCopy () [0x00006] in <106570632fc343a784fad39e75e877bf>:0 at GameDatabase.GetConfigNode (System.String url) [0x0002f] in <106570632fc343a784fad39e75e877bf>:0 at TweakScale.PrefabDryCostWriter.GetMeThatConfigNode (Part p) [0x0002a] in <62ab179107a144c5a3808f0cd36a9f76>:0 at TweakScale.PrefabDryCostWriter.checkForOverrules (Part p) [0x00000] in <62ab179107a144c5a3808f0cd36a9f76>:0 at TweakScale.PrefabDryCostWriter+<WriteDryCost>d__3.MoveNext () [0x00417] in <62ab179107a144c5a3808f0cd36a9f76>:0 at error:0 These parts will probably cause some problems to you, but the "Interstellar-Technologies-ICFSC-Reactor" the rbug.craft uses is not there, so you have yet another problem to cope with. Anyway, I redid the test using the rbug.craft and, yes, I detected an underrefunding on it. However, and we need to make things clear here, this is not a problem on TweakScale neither with KSP-Recall. This is something on the Interstellar Techonologies - these parts have the problem. TS and Recall are working fine with everything else. I'm now checking what's wrong on these parts. — — POST POST EDIT — — To avoid losing time, I redid the test using the "Antimater Initiated Micro Fusion Reactor" on the same savegame where the Interstellar-Technologies-ICFSC-Reactor part is borking. I need to know if this is something confined into IT parts only or if it infected everything else. Well, the KSPIE parts are still being refunded without problems. This settle the matter, whatever is wrong, is affecting IT parts only. — — POST POST POST EDIT — — Interesting. Apparently, something is messing up the chain of events that ends up calling the `Refunding`'s `IPastCostModifier` interface. The best way to check for it is to remove `Refunding` and see what happens. So I applied this patch: @PART[Interstellar-Technologies-ICFSC-Reactor]:FINAL { !MODULE[Refunding] { } } to remove `Refunding` from the part to see what happens - and, as expected, I started to get mis-refunded (the problem `Refunding` was intended to fix at first place). Digging around the config cache and the craft files, I realised that the affected part has Refunding installed before TweakScale, where the funcional parts have it after TweakScale. I really don't remember if this can do a difference or not (I have some faint remembrance of being worried about this issue, but really don't really remember now), so I injected back the thing on the same patch so it would shove `Refunding` later on the patching process: @PART[Interstellar-Technologies-ICFSC-Reactor]:FINAL { !MODULE[Refunding] { } } @PART[Interstellar-Technologies-ICFSC-Reactor]:FINAL { %MODULE[Refunding] { active = True } } And this patch gave me the intended result on the ConfigCache, the `Refunding` module is now after TweakScale's. But it didin't solved the problem, so the order of the `Refunding` module is not an issue. (need to take note of that somewhere). At the present time, I don't have an explanation for only the IT parts being affected by the problem. The only thing I can say for sure is that neither TweakScale neither KSP-Recall are the culprits for the problem. They are involved on it, for sure, but they are not causing it. Wondering what to do next. — POST POST POST POST EDIT — Updating IFS to 3.30 didn't changed anything. No new problems, no change on the current ones. I don't understand why rolling back IFS solved anything for another user. More interesting yet, I reinstalled everything from scratch, starting with KSPIE and then I just shoved the InterstellarTechnologies directory into the GameData, completely ignoring anything else from the IT's zip package. The problem happens the same... So whatever is happening on the IT parts, is something being triggered on the Config, as everything else is the same for KSPIE parts - that are working as expected. Oh, dear… I'm going to debug parts now. — POST POST POST POST POST EDIT — So… It's Part Config debugging time. Since it was already stablished that this is not being caused (directly) by a PartModule (being it TS, Recall, or whatever), it's something on the ICFSCReactor.cfg file. In order to simplify the number of variables on this equation, I removed a lot of things from the test bed, leaving installed only: 000_FilterExtensions 000_FilterExtensions_Configs 000_KSPe CommunityResourcePack InterstellarFuelSwitch Interstellar_Redist.dll ModuleManager ModuleManagerWatchDog MyPatches.cfg Squad SquadExpansion TweakScale __LOCAL A customized copy of the Interstellar-Technologies-ICFSC-Reactor part is here for debugging. 000_KSPe.dll 666_ModuleManagerWatchDog.dll 999_KSP-Recall 999_Scale_Redist.dll ModuleManager.dll Of course the part will be butchered on launch, as the following PartModules will not be there for it: InertialConfinementReactor IntegratedThermalElectricPowerGenerator IntegratedRadiator This will allow me to check if the problem still happens or not on this reduced setup and… Well, the problem didn't happened ANYMORE. So the problem must be being triggered by one of the PartModules listed above. Working on it.

This one I gave a close look. It was a Unity issue. FS was relying on a call from Unity 2017 that got removed on Unity 2019, and then the DLL failed to be loaded - triggering the infamous Assembly Loader/Resolver on KSP. This was fixed on the next FS release, but MJ2 retained a code yelling anything going wrong on FS as FS not being compatible with KSP - even when something else screws up the Assembly Loader/Resolver and FS ends up being hit by the splash damage.

Publishing your KSP.log on dropbox and posting the link here will be a great first step! Read this thread about how to get help: On the OP, on the Spoiler below the title "Support:", you will find additional information for modern KSP on Linux and MacOS.

Other FS PartModules are also used. Most of them can be replaced, of course, but since some of them are still really needed, there was no ral point on switching some of them if you are not going to switch all of them. Until now. Or soon™ - frankly, every I sit down to work on AP+ (or something fun as expanding the TweakScale Companion), some astral conjunction happens somewhere in the Universe, triggering an avalanche of bug reports that ended up eating most of my free time. I understand, and I agree. I have this concerning on KAX - avoiding cluttering it with things that would not "fit" the add'ons' "spirit". Of course, I will not do it - what would be the point at this time? - but I think that AP+ should be a "Franchise", with some "sub-modules" adding related parts into the mix. AP+ "Cold War Civil Aviation", "WW2 Military Aviation", "Jet Engine Dawn", etc. I once waved some contributions to KAX once because I didn't thought it would fit on it (it's essentially Pre WW1 era, and post WW2 era aviation parts - how a Boeing fuselage would fit on it?). It's still an idea I'm toying with, but how to implement it without disrupting the Scene? I don't think the cost/benefit of doing it now would be positive. I'm toying with the possibility of fixing Firespitter. I already had fixed some things on it on a personal fork, but gave up on pushing them into the mainstream as things are never merged. I don't want to rant publicly about, but FS is fixable. There's absolutely nothing preventing it from bring fully compatible (with all the original parts) into modern KSP. I decline to further comment about. That said, almost everything on FS is replaceable. What doesn't means it will got better with it - sometimes, you will get a worst experience by switching off from it. Yes! I replaced some FS modules from KAX on the helo parts, and let me tell you - I hated the result. Fixing Firespitter is the way to go, in a way or another - it's the reason I decided to work on it extra-officially. I think it's wiser to decline on further commenting about. Because not so many people really like to use B9PS (they love the parts using ot, and tolerate B9PS due them), and even fewer authors like to support it. Believe me on this one - B9PS is a nice idea, but far from being convenient to support and frankly way overbloated. Kraken knows how many man-months it took me to support this thing on TweakScale - and I still get problems nowadays due something misusing it now and then. I don't oppose people using B9PS if people it, but I don't plan to do the job myself - I will assist anyone willing to do it, though, as long this dude maintains the patches themselves.

Moved from TweakScale thread: So, this is what I did: On a "standard" KSP 1.12.5 test bed with the following preinstalled addons, all at the latest versions at this time KSPe KSP-Recall DistantObject (I forgot to remove it) ModuleManager/L Module Manager Watch Dog TweakScale TweakScale Companion the ÜberPaket I downloaded the latest KSPIE from SpaceDock (1.29.6) and installed it on that rig (without overwriting anything that was already there). I forgot to remove all MiniAVC DLLs, but whatever - most people also does it so perhaps this was for the best. I loaded your "bug" savegame and checked for the problem you reported. And got busted, as the part Interstellar-Technologies-ICFSC-Reactor was not found on the GameData. Krap, booting KSP 1.12.5 is pain where the sun doesn't shine on this machine. So I tried to salvage the situation using another reactor, the Antimater Initiated Micro Fusion Reactor, scaling it up to 7.5M and launched it at a cost of 3,689,359 . I confirmed the Funds were deducted from the KSC's account, then I recovered it. And the money were refunded as expected. So everything is working fine on a "Stock" (or nearly) installation, and so we have something else screwing you on your rig. Now that I know where the problem is not, I will start to update things on this rig to match yours and find who is stealing money from your Agency. I'm working on it.

It's not TweakScale, it's KSP-Recall that somehow is failing (or being induced to fail) on the stunt I cooked for working around the major KSP screwup on the IPartCostModifier handling. I will pursue this problem on KSP-Recall thread. — — POST EDIT — — Current KSP-Recall and TweakScale were ruled out, it's something else screwing with KSP-Recall.

Guitar Hero moment: Joan Jett!

The weird thing about this Assembly Loader/Resolver problem is that everybody and the kitchen's sink get royally screwed once it is triggered by someone. On saner systems, only the thingy that failed being loaded would had problems, but due this KSP's bug, once the first DLL fails to be loaded, everybody else in need of loading another DLL or to use another thingy called Reflection will be screwed by the problem. So it's not obvious what's cause and what's effect on this one - not to mention splash damage. Empirically, I had found that the first occurrence of a DLL loading error would pinpoint the cause of the problem, but when MJ2 is installed, the order of the log is messed (something about MJ2 doing it's own sanity checks, changing the chain of events - not a problem, just a different way of doing some things), and so it's yet more harsh to diagnose the problem! Well, now let's talk about this problem. KSPe.Light is the lightweight, "retargetable" version of KSPe. I did this way because KSPe's API was not stable at that time, but yet had a lot of features that made my life easier so embedding a custom version of it on Recall (and others) make sense - I can develop KSPe outside the development cycle of Recall et all, so I don't risk screwing up someone else's life due an ABI breakage (that happens every minor version change - i.e., 2.2 to 2.3, from 2.3 to 2.4, and now with KSP 2.4 to 2.5). The side effect of it is that is not uncommon that Recall (et all) gets tied to a specific version of KSPe.Light.<something>. What's should not be a problem, because each Release of Recall (et all) come with it embedded, and all of them works on almost all KSP releases, so the user is never locked out of the bug fixing cycle no matter the KSP he's playing on (with a few exceptions, of course). Things got royally screwed on the user's machine because somehow KSPe.Light.Recall v2.3.0.4 was installed with KSP Recall v0.2.0.6 . But it happens that on Recall v0.2.0.6 I used the KSPe.Light.Recall v2.4.0.0, not this older one! And do you remember that I break ABI (Application Binary Interface) when I raise the minor version of KSPe? (i remove deprecated things marked to be removed since 2 or 3 minors before, usually - on 2.4 I removed a lot of bad ideas from the 2.2 era that was hindering further development). So now we have the reason for the breakage - an older KSP-Recall was installed, but somehow with an even older KSPe.Light.Recall for it where an ABI call was different from the one Recall was compiled against. So we had a Dynamic Linking error, that it's a kind of Reflection Error that triggers the Assembly Loader/Resolver bug on KSP, that so starts to screw up the life of everybody else. Firespitter is only a problem when the TweakScale Companion for Firespitter is not installed. I'm trying to find time to write a "Sanity Check" on TweakScale to recommend installing Companions as needed - but, boy, I just can't win an argument with Real Life™. So, at this time, the TweakScale Companion ÜberPaket is almost a hard dependency for people not playing Stock. Good thing I had wrote conditional DLL loading tools on KSPe, so you can install a "hard" Companion (one that needs a dedicated DLL compiled against the targer add'on) on a rig without the target installed without risking getting screwed by the Assembly Loader/Resolver. Well… "vida que segue" (life goes on). Cheers! — — — English Translation of some terms — — — API Application Programming Interface A kind of "contract" where two different codes from two different sources agree in order to reuse each other's assets. Source Code level ABI Application Binary Interface It's the same contract, but on the binary level after compilation. It's related, but doesn't matches exactly the API used to generate it, Depending in how you compile something (and in which language), one API can generate different ABIs. Most of the time, as your libraries evolve, you want to keep the ABI intact to prevent a recompile fest on the field - what creates drag on the adoption of the newer versions. API changes are usually better tolerated if done on the long term (i.e., first you mark something as deprecated, then you pesky everybody for some versions about how that thingy is going to be removed futurelly, and then you remove the thing). But sometimes you draw yourself to a corner with C# - there're so many different ways to define a call, and because of it sometimes you just can't keep ABI compatibility while changing an API. It was was happened on KSPe 2.3, a bunch of bad ideas were preventing me from fixing some API calls to something saner due ABI conflicts.

Nope. KSPe is not installed. What we have on his GameData are the specialised Light version used by DOE, Recall and TweakScale - and they are not throwing exceptions. Curiously, I found this: [LOG 14:54:03.858] [CompatibilityChecker] Running checker version 5 from 'MechJeb2' [EXC 14:54:03.861] MissingMethodException: bool ModuleManagerWatchDog.SanityLib.IsEnforceable(int,int) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) [EXC 14:54:03.862] MissingMethodException: bool ModuleManagerWatchDog.SanityLib.IsEnforceable(int,int) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) [LOG 14:54:03.862] [WatchDog.InstallChecker] Version 1.1.0.3 /L It's curious, but apparently something is screwing with MMWD DLLs. MMWD does not use KSPe, being the Light or not, so KSPe is not a variable on this one. So this is something else triggering that Kraken damned KSP bug on the Assembly Loader/Resolver thingy. Then I found this: [EXC 15:09:19.206] MissingMethodException: KSPe.Util.Log.Logger KSPe.Util.Log.Logger.CreateForType<!0>(string,string,int) Rethrow as TypeInitializationException: The type initializer for 'KSP_Recall.AttachedOnEditor.AttachedOnEditor' threw an exception. UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.GameObject:AddComponent(Type) Suggesting that KSP-Recall is not being able to find it's specialised version of KSPe.Light. However, it was found on your rig: [LOG 14:54:02.325] [KSPe.Light.KSP-Recall] Version 2.3.0.4 /L <...> [LOG 14:54:02.328] [KSP_Recall] Version 0.2.0.6 /L running on KSP 1.12.5 HOWEVER… Somehow you have a VERY OLD Version of KSP-Recall installed on your machine! This release if from more than 18 months ago, a really huge amount of time given the number of bug fixes I did on the newer versions! The following is the logs I have from my Reference KSP installagion: [LOG 12:10:34.512] [KSPe.Light.Recall] Version 2.4.3.0 /L for KSP-Recall [LOG 12:10:34.521] [KSP-Recall] Version 0.3.0.9 /L running on KSP 1.12.5 This is reason enough to stop the diagnosing and suggest you to completely remove the KSP-Recall and reinstall it using the latest version found on CurseForge or SpaceDock. It's since Dec 2021 (when I launched Recall V0.2.1.3) that I don't even fire this old 0.2.0.6 release!!! @Rocket Science42, please update KSP-Recall to the latest version and then try again. If things still get screwed, publish a new KSP.log and I will keep digging. Additionally, you are also using a very old release of TweakScale too!: [LOG 14:54:08.266] [TweakScale] Version 2.4.6.2 /L And Kraken knows how many mistakes and bugs I had fixed on TweakScale since Oct 2021, when I launched this version! I never fired it again since Nov 2021 when I released a new one. @Rocket Science42, again, please install the latest TweakScale from CurseForge or SpaceDock. And, now, a somewhat serious warning. You are using the latest KSP: [LOG 14:50:53.555] ******* Log Initiated for Kerbal Space Program - 1.12.5.3190 (WindowsPlayer x64) en-us ******* Kerbal Space Program - 1.12.5.3190 (WindowsPlayer x64) en-us So there's absolutely no reason for you be using so older versions of KSP Recall and TweakScale. I go trough huge pains to make the newer releases compatible to any KSP version since at least 1.4.3 (some few add'ons of mine can be used downto 1.3.1!!!), so you can always be using the latest releases with the latest features and bug fixes no matter the KSP version you are using. But I don't test older releases of my add'ons on newer KSP ones! I don't know why you decided to install so older versions of these Add'Ons (and, frankly, perhaps it's better not to know after all), but I strongly suggest you don't do it anymore. Now and then I made a mistake, I know. But I had always fixed the real bad ones in a matter of days once they are detected, and it's some time since a healthy KSP installation had suffered due one of them. The latest major screw up of mine was on a code that was trying to survived royally screwed up KSP installations with multiple bad patching problems on it - people that keeps their GameData sane didn't noticed the problem! Anyway. Please update your KSP-Recall and TweakScale to the latest versions and try again. If anything bad keeps happening, publish a new KSP.log and I will dig on it,

Yep! I'm going to support Universal Storage. Soon™. It will be implemented on the TweakScale Companion Program. This guy is a bit tricky to support because it have a lot of PartModules to cope with... Do you know what? I will start to work on it this WeekEnd! Cheers!

The problem is caused by double patching. The TweakScale code that tries to survive the problem got a regression on 2.6.4.22 that leaded to this unfortunate problem. The latest TweakScale 2.4.6.23 fixed the problem. Be advised that only installations infected with the double patching problem were affected. Installations with sane patchings weren't affected (as the code that suffered the regressions are only triggered on faulty installations).

So I did what I usually do: I don't guess, I measure. With this project https://github.com/net-lisias-ksp/ScrewMeUp/releases one can selectivelly induce the injection of NRE's on the different points of the Unity's and KSP's Life Cycles - and so measure the consequences on the current gaming. I don't really have to explain that this thing can royally screw you over, so don't even consider using it on anything that you would remotely like to use again after! The M.O. is simple: on any scene, open the PAW for the selected strutCube and activate the "Screwer" you are interested on checking (KSP or Unity). Then look into the KSP.log for situations where the "Screwed" PartModule doesn't logs an entry telling its is fine. Failing to log "it's fine" indicates a situation where the NRE had screwed the Life Cycle of the PartModule. Only the strutCube (Cubic Octagonal Strut) was patched with these PartModules. Only crafts using it will be subject to the problem, we would need to inject these Modules on more complex parts (including with 3rd parties modules as TweakScale) to completely appreciate the consequences - but, hey, this is a start. Additional very important info on spoiler: Not entirely true - at least, depending from what you call "major". At least some methods are screwing KSP when an uncaught Exception happens, on the very least we have the already known PartModule.OnSave that can halt the whole User Interface when happens. Interesting enough the "damage" is not permanent, if you disable the "Screwing" the game goes back to normal. Not a bad thing, not a bad thing at all. See above. I didn't mapped exactly what ones are screwing the game and where, this is Research in Progress (something to be done on a longer Week End to say the true), but it's enough to say that it can impede the part from being loaded on recent KSPs if the test is activated on the Loading Scene (by setting true on the patch that inject the Screwer module into the part) - on some older KSPs, it plain crash the game to CTD. Additionally, I didn't created a test for VesselModules. Yet. I will need a more refined Test Artefact in order to check about this one (see above). It's important to consider that failing to complete the OnDestroy() can leave not only memory left behind on the heap, but entire objects on GameEvents (as it happened in the past with B9PS, that ended up screwing TweakScale), what I called Zombies in the past. TweakScale is one thingy that really misbehaves when transformed into a Zombie.

So the problems happen when the uncaugh exceptions happens on KSP overriden methods only? The OnSave for sure screws the whole game when it happens, preventing even the UI from working once it happens. On exactly what method this is happening? We have information that Unity's "callbacks" are caughthing exceptions and preventing the thread's murder, but I have empirical evidences that at least the PartModule.OnSave royally screws the whole game when an uncaught exceptions os thrown...

Choose your poison! EVE beta is, well, beta. You know you are risking your savegames using it. And since the thing is being actively developed, such problems are really expected to happen. Parallax is a bit more hairy, because it's being used as stable nowadays. IMHO, someone should at least handle that exceptions in a graceful way to make sure this is not aborting any threads. A lot of weird issues may be related to it, not only here on DOE or even TweakScale, but on some others too. Including efforts to fix KSP internal problems. There's no way to keep the game healthy with threads being murdered by unhandled Exceptions. This may be one of the reasons so many people are getting screwed on KSP while gaming, with crafts suddenly being saved missing modules and when reloaded, missing the configurations. I have diagnosed at least one case in which some (but not all) satellites on a savegame lose all communications: by inspecting the savegame, the affected crafts had lose the ModuleDataTransmitter and the values were reinjected in a way that made them unuseable. This must had happened in a single gaming session, because some 2 or 3 crafts had the problem - the other ones probably had never be unrailled on the doomed gaming session, so they were preserved. Again, if you don't mind risking your savegames, it's your choice. But users need to have the same choice too - and users can't choose what they don't know about - and they are not skilled techinicians as both of us.

That's something we can work on! Let's talk about it on the next WeekEnd! In the end, it's really simple: a list of bodies by name and the RGB colours you want their flare. Check this file: https://github.com/net-lisias-ksp/DistantObject/blob/master/GameData/DistantObject/PlanetColors.cfg

Ouch, I forgot about! It was going to be needed for some customisations, but I ended up not implementing them (yet) and forgot the thing there! Thanks for the heads up! That's the problem with errors on KSP: they break the chain of events of the life cycle of some components. As an example, let's suppose we have a one part vessel with 3 modules: ModuleA, ModuleB, ModuleC. When KSP fires up the vessel, it does something more or less like this: Call VesselModule's OnStart Call the OnStart of every Module: ModuleA.OnStart() ModuleB.OnStart() ModuleC.OnStart() Release control to the GameEngine. And the GameEngine, so, loops more or less this way: For every vessel in the physics range: Call its FixedUpdate For every Part on the Vessel: Calls its FixedUpdate, i.e: ModuleA.FixedUpdate() ModuleB.FixedUpdate() ModuleC.FixedUpdate() Now imagine: each Module's OnStart initialises some data needed by its respective FixedUpdate, right? So, what's happens if there's an Exception while handling the ModuleB.OnStart()? Well, the ModuleC.OnStart() will not be called, because the thread was killed while calling ModuleB.OnStart()! So ModuleB.FixedUpdated will probably be screwed, and ModuleC.FIxedUpdate will surely be royally screwed - besides not being its fault ModuleB killed the thread on the OnStart phase. The same happens if ModuleB.FixedUpdate() throws an Exception - the thread is killed, and the ModuleC.FixedUpdate() is never called because of that. This is the reason we should not play KSP when there're exceptions being thrown on the KSP.log. Kraken knows what's not being called because of that.

Please note that this will be reverted when Steam updates something, or when the user asks for verifying the game installation, the same way it happens with the KSSL, mentioned here.

Update to the latest TweakScale (2.4.6.23 at this moment). Your GameData is "infected" with a pretty old problem that I call "Rogue Duplicate", when less than ideally written parches shove multiple copies of the TweakScale module on a part. While fixing a weird bug on 2.4.6.21 (that I still didn't understood what happened to this day), I made a stupid mistake on the code that handles this Rogue Duplicate crap on 2.4.6.22. Your rig will still have that Rogue Duplicate thingies, but with 2.4.6.23 TweakScale is able to handle them again. Cheers.

I don't have a 1.12.3 available for testing anymore, so I gave this a try on 1.12.5 (and, of course, on 1.4.3 too - why not? ). This is what I did: Launched the game, created a new sandbox called "test-doe" this step, obviously, is only executed the first time Opened the DOE Settings, clicked on Reset to Defaults and made sure the Flares and the SkyBox Dimming are enabled. Also enabled the Show Names on MouseOver. Closed the Settigns after clicking Apply. On VAB, loaded the Ion Powered Space Probe Launched it into LaunchPad Cheated it into a 6000000000 (9 zeros) orbit around the Sun. Made sure to move the camera to be between the Sun and the Probe (so the Sun was "behind me" for sure), and at the same time be able to see the flare of some planed, in my case, Duna. Quit the game to Desktop Reloaded the game, reloaded the savegame, got into Tracking Station, selected the probe and clicked on Fly. Nothing wrong detected - the Sky is not dimmed, and the flares are visible. Moving the camera around worked as expected - things got dimmed when the Sun appeared, and got back to be visible as the Sun is out of the view. I repeated this procedure on 1.4.3 and 1.12.5. I think you may be experiencing some 3rd party conflict, perhaps? Or something that is mangling with the game's life cycles?

Yep. I would love to have such limitations on the game - even as an option. This would impose real challenging on airplane designs! FS is, also, a very abstracted model, so not so realistic as it may sound - but it makes things more fun to cope with. And even by not being used on the procedurally generated blades for the thing, it can be "hacked" to be used on "hardcoded" engine meshes to match the actual number of blades on the thing. There's ModulePartVariant to switch meshes to models with 3 or 4 blades (more blades, better performance on high altitudes; less blades, better on lower altitudes). What I really liked on FS was making believe the space race had begun before the WW2 - so, what kind of carrying vehicles we would had? How would be launching a primitive rocket from a primitive airplane carrier? I spent weeks avoiding upgrading parts and facilites, trying to do the most I can with the current restrictions - as launching a kerballed mission to a fly-by over the poles on a suborbital trajectory from a biplane (as I could not steer the rocket from the launchpad yet), and still be able to recover and reuse most of the parts (and with primitive SAS). Months of fun and amusement, it was one of my best savegames to date. And, damnit, it's fun to fly biplanes. These ones are not going to use propellers!

Exactly my point. Extraplanetary aircrafts doesnt' needs to be spacecrafts! Check how NASA did with Ingenuity, Point taken. Something to consider about. I think this argument doesn't proceed. I'm talking about performance, not size. Kerbals still have about 1 meter high, so shrinking things this way would make the part unsuitable for them (and, in fact, I think that some are). Kerbin is about a third of the size of Earth, but have the same atmosphere height and the same gravity. So the parts should, ideally, perform in a way that would impose similar challenges to the user as the equivalent reallife™ counterpart - reaching the same altitude, but with a proportional autonomy. Again, what would be the point of having propelled engines if they would perform exactly as the jet ones? RSS usually rebalance the parts for their needs. I don't see why I should balance parts to be used on RSS if they are meant to be use on Stock. But the upscaled words argument has merit - if the stock parts performs good on upscaled world, so A+ should do. The parts should fit the game. That's the whole point. Do the research again for propelled bombers and fighters on real world. So they are currently meant to be used on sandbox, not on career. Ideally, you should do your first steps on flying using propellers, and only later research jet engines. Our fist space artefacts were transported by propelled crafts, the jet engines came common use only after the space age had started. And, as I said, things are esily patched. These are not mutually exclusive options. This is due how KSP simulates the fuel consumption and engine performance over altitude. The model is simplified and tied to the air intake consumption only - by the way, is how the power curve over altitude is simulated, by reducing the volume of the air intaking from the intakes. So, in essence, the fuel consumption for flying 1 hour at 100% trust is the same as flying 2 hours at 50% trust, no matter the altitude. This model works fine for rocket engines, but poorly on jet engines - and terribly on piston engines. It's not a matter of being possible or not. It's a matter of hating this kind of animation. I don't mind reworking the propellers to use stock animations, but I will not use them - I will keep the current animations as an option for people using Firespitter, as I do. I don't mod things I don't use. That's the point: I'm not using FS because I need, I'm using it because I like it. The code models engine power and propeller efficiency pretty nicely, it really makes difference between using a 3 bladed propeller and a 6 one. Using a too much powered engine with 2 blades will not convert all the power into trust, you need more blades. But adding each blade adds a bit of drag (and some weight!) on the thing, so you need to balance - and this is what makes things interesting on a LEGO style gaming as KSP, you need to balance things in order to get what you want, it's the whole point of the game!!

A Cessna Caravan has a max autonomy of 1070nm, or about 1980Km on Real Life™. Kerbin has an Equatorial diameter of about 3.770 KM. Earth (the real one) has about 12.740 KM. So Kerbin is about 0,29591837 times the size of Earth. So, if I want to make a Cessna Caravan correctly balanced for Kerbin, the thing should have about 320KM or autonomy! Otherwise, again, why bother building an add'on for propelled airplanes? People willing to throw balancing trough the window can cheat their way into the game, why spoil the game for people willing to have a balanced, challenging game using airplanes?