Lisias

I was talking about a hypothetical concurrent physics engine - if you have many threads simulating different partitions from the world, you need to syncronize them before detecting collisions, otherwise you will get some pretty hard to debug bogus collisions due race conditions.

Nope, I'm very up to date. See this thread (it is less than a year old). I'm talking about the GAME, not the engine. Additionally: If you create MonoBehaviour script and do things in any Fixed/Late/Update() function, this runs on main thread. Most of the Unity API's are not thread safe. Meaning you cannot create seperate thread and interact with the engine API's. Source (April 2022) Yep, physics is generally not well suited for multithreading, unless you stop thinking serially and start to think "distributively". Different crafts on different frames of reference don't interact with each other and, so, dont need to be simulated serially. Even two different crafts in the same frame of reference but not touching themselves can have their physics calculated in parallel - as long your data structures are tailored for that. Detecting collisions are still a problem, tough.

I agree. KSP2 is going to take some time to get traction - we will get a burst of downloads, then a lot of fuzz about, and then some (probably most) people will get bored and will probably go back to KSP1 for "real playing" - or play something else, if they perceive KSP1 as a "dead game". KSP1 is not dead yet. It eventually will be, but not yet. Until there, I think it's wise to give it some attention and care - it will be still be played by lots of people in the near future - or none of them will be played at all, to tell you the true. Keeping people interested on KSP1 will help KSP2 on the long run.

I can't say anything about KSP2, but I know that is shares some things with KSP1 - as Unity. Unity games usually relies heavily on single core performance - Unity, or at least the part of Unity that KSP1 heavily relies on, is heavily built [optimised] around a non threaded paradigm. As far as I know, the Unity's physics engine is not multi-thread capable - but this may be a weakness imposed by KSP1 itself, where all the Universe shares the same Frame of Reference at a given instant. The weird thing about Unity, mainly 2019 at least, is that the more cores you have, the worst the performance gets - believe it or not. So, high frequencies, low core count CPUs are the best hosts for playing KSP1 and, probably, KSP2 too. Memory is simple: the more, the best. I think that there's a point in which too much memory may choke the Garbage Collector (mainly due it's being hindered by the problem I described on the link above), but I didn't reached it yet. Your main problem is VRAM. From KSP 1.4.3 towards 1.12.5, the main factor that screwed performance on my rig was the high VRAM consumption. Even lightly modded KSP1s are getting screwed lately when using 6GB VRAM GPUs due the excessive use of VRAM by KSP1 and, lately, PD-Launcher. I got very promising results on my really old MacPotato by downsampling the DDS textures on KSP 1.12.x - not to the point in which it performed so well as on 1.4.3, but still better (the new ground rendering introduced on 1.8.0 is also pretty heavier on my rig). But, this is KSP1. Let's talk about what I hope to get on KSP2: Multiple Frames of Reference simultaneously. With each main body having its own origin, everything under its Frame of Reference can be calculated on a separate physics engine instance, each one on its own thread, and so we can have some very perceptible improvements on performance on savegames with multiple vessels scattered on different stellar bodies. Seweing the different Frames of Reference together will be pretty complex, but it will worth the pain IMHO Whatever Unity did screwed on 2019 that ended up getting worse performance as more cores you have, I really hope they had fixed it on Unity 2021. This is just abhorrent. I have better performance and lower CPU temperatures by reducing the number of threads per CPU on KSP1 to a single one. It's insane. Better Texturing Quality granularity than on KSP1 Way better VRAM management than on KSP1 Running on Windows 10. Microsoft is heavily pushing newer hardware for Windows 11, no matter the performance specs of the rig If KSP2 manages to tackle down at least 3 of the points above, we will have a better experience on KSP2 for sure - and if your rig can manage 1.12.5 at max settings, it should be able to run KSP2 in my humble opinion. Eventually, at least. — — POST EDIT — — I rephrased a statement above. I think it's more… faithfull… to what I'm meaning. I hope.

Nope. Windoze only, sorry. There were an official statement saying the game would be launched on 2020. This is one of the points on KSP2 in which I'm terribly pessimistic. Multiplatform support is something that should be worked on since the very first commit of a project. As much Unity tries to abstract things, abstractions leak, and they leak a lot - to a point that most development teams give up after a certain point of development time. As a proof os concept, take the Client Apps for Steam, Epic and GoG. Only GoG really works fine natively on MacOS - all the others need a loopback filesystem with the case sensitive filenames turned off. A pain in the back, I tell you - and this is only one of the problems to cope with. I hope, but I don't expect, a native Linux and/or MacOS for KSP2. Ever.

I can't say I'm disappointed because since the pandemics I'm resigned to cope to a lot of changes on Real Life™, most of them for the worst. And I'm convinced that this is not going to happen only to me, I don't expect my life to be better (or too much worse) than anyone else's. So I kinda knew that KSP2 would have a somewhat bleak launching - people had too much high expectations for it (and I think I can include even the developers on this wagon). And I think this is OK- lots of things on my life didn't gone as I wanted, but some of them gone as I needed, so I'm counting my blesses. Sometimes it's not evident, but I'm deeply grateful to a lot of things that I didn't wanted to happen, but it happened anyway and they ended up being what I had needed to happen. And I think KSP2 is going to be something like that - not what we want, but hopefully enough to fulfil what we need: consensus is not something that makes everybody happy, but something which makes nobody angry. KSP1 started as a very humble game. It grown a lot in the process - not without a lot of pain. I expect KSP2 will do the same - it will, eventually, be a hell of a game in the same sense KSP1 became a hell of game nowadays - there's still an incredibly marvellous game buried on all that collection of bugs, and that's the reason I'm still digging on it. “The sculpture is already complete within the marble block, before I start my work. It is already there, I just have to chisel away the superfluous material.” Michelangelo Coding is the same for me. It will eventually succeed, as long we keep digging. And hopefully modders too. The scene needs new blood, with more time to spend on a hobby and less desire on making this a "profession". KSP1 had a vibrant, colourful and intense modding scene in the early days - shifting to KSP2 without bringing all of that back will be way less attractive than otherwise. Is KSP2 going to be an elitist scene like X-Plane or DSC, with add'ons made by companies and not rarely costing more than the game itself? Or it's going to be fun and anarchic as KSP1 was in the beginning? What's going to lure add'on developers to KSP2? Fun? Amusement? Self accomplishment? Or money? (money changes everything). Are we going to need to pay money in order to publish something around here? This is concerning me more than anything else - the game itself, I KNOW will be fine as long the developers have time and resources enough - smaller teams with less resources managed to provide us with KSP1, I'm pretty sure these guys are more than skilled enough to do the same to KSP2. (mistakes will be made, the same way some already had been - but, hey, we are still alive and kicking, right?) I like graphics, but I like playing more. I'm very, very impressed with games like Tiny Combat Arena and Juno: New Origins - they are incredibly fun to play even on a crappy machine like mine. And, yeah, I spent more money on software than on hardware - it's one of the reasons I didn't upgraded my rig yet!! This came to my attention too. I'm guessing that these dudes took advantage of the initial momentum to get funding for things they knew will not be funded later once the money started to flow and the pointed egg heads smelled the incoming money. It's a sad state of the industry the one we have for decades already: the "fake it until you make it" mantra is still on the vogue. Theres a lot of things you need to get fast, or you will not get them at all. A fear the same. I really enjoy (most of) the videos, and I liked most of the things I saw on KSP2 until this moment - but as much as I think I will enjoy the game itself (eventually), I enjoy eating and paid bills more. I'm on a budget, and the machine used by SWDennis on his KSP2 test drive would cost around a whole year of the minimal wage on my country - and all of that to get 20 fps? I understand it was a beta (or even alpha) release of an early access game compiled in debug mode and all that jazz but… Gee… 20 fps on a machine that is way beyound the purchasing power of about 90% of the population of my country? This is not exactly the best way to get some money from the product right now: you can give the game for free, it will be of no use if people could not run it. I would deduce 18 months from it. Pandemics screwed everything, and on my line of duty, I closely overviewed the effects on a whole country. I have nightmares until nowadays due that (falling) numbers, wars didn't screwed things like that - and I know what I'm talking about. Hope. IMHO, this is the real threat to this game. Everything else is just life being life and people doing what people do. Manley doesn't talk anything that could detract the game since the developers complained to him in the past that he was making them look bad. Manley stopped to do things too bold since them (or, at least, it was what I perceived) to minimize crashes on his videos. So I pretty doubt he would criticise it openly on a video. Lowne, well, this guy is a grown "kid' - on the most positive sense of it. It's one of the main reasons I had enjoyed this videos in the past - he is enthusiastic, contagiously enthusiastic. I doubt he even noticed any problem on KSP2 while playing, he was enjoying himself. Check ShadowZone and SWDenis. These ones are being pretty critical on the matter (also, on the most positive sense). "The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time."

NOTAM It came to my attention that some users may be having problems with scaled parts on SubAssemblies. I could not reproduce the problem using the latest TweakScale (2.4.6.23 at this time) and KSP 1.12.5 - at least, using Stock parts only. Interesting enough, I got a single situation where scaling parts with variants left me with the wrong Attachment Nodes. But it happened only on the first craft I created on the first time I loaded Editor. Once I saved a craft and clicked on 'New', the problem didn't manifested itself anymore. Didn't tested yet if launching the craft or just quitting the Editor (or the savegame) and reloading Editor would make a difference. Something to be checked later. History suggests that we have something wrong on the Editor. Again. But I didn't zeroed in the root cause of this misbehaviour yet, so it may be something related to KSP-Recall. No (new) misbehaviours were detected on KSP 1.7.3, I will check other KSP releases (as 1.11.2) later. Any user experiencing this problem, please report. Cheers!

Approximately 50% of the TweakScale downloads come from SpaceDock nowadays, and I set up CKAN to download from there. I only wished things on CKAN would not take so much time to pass trough. It's a whole month already...

Wow, someome from the dawn of TweakScale! Pleased to meet you! (I'm the current TS maintainer) About KSP2, I'm most interested, right now, on the minimum hardware requirements to run it. I'm not going to invest on a new Windows machine for a long time, and I want to know if the hardware I have now will be enough to run it!

Just to explain exactly what happened: you were bitten by the infamous KSP's Assembly Loader/Resolver bug. It's the thingy that keeps track of every DLL loaded, as well the Assemblies inside the DLL (C# DLLs are like zip files, a container for things, being that things the Assemblies, where Assemblies are a bunch of related code sewed together). What happens is that when something tries to load a DLL and it's not there, or the DLL it's there but it's corrupted somehow (as not being able to find dependencies), the Assembly Loader/Resolver enters into a inconsistent state and from that point, anyone trying to load a DLL or to use a thingy called Reflection from the C#'s runtime borks relentlessly. It happens that TweakScale makes heavy use of both thingies and, so, it's usually the whistle blower that yells about it. Had not this nasty Assembly Loader/Resolver bug be there, failing to load a DLL would only affect whatever was trying to load it (as, obviously, it was being loaded because it have something someone is willing to use). Since this RunSharp.dll one could be removed without consequences, it was probably copied by accident into the distribution package. KSP preloads all DLLs if finds in the GameData (unless they are inside a directory called PluginData), even if no one is going to use it. I'm guessing that this RunSharp thingy needs some dependency that was not there, and then borked being loaded, and then triggered the infamous bug on Assembly Loader/Resolver. Welcome to a very important class on Software Development: Configuration Management. Cheers!

Things are going to be even better when the CKAN guys finally aprove my entry! It's a month already in the making!!! https://github.com/KSP-CKAN/NetKAN/pull/9536

I like boeings!! here, I fixed it to ya: Humm… digging around, I found two that I can publish here: The ERJ-145 is known around here as the "Windows 98 jet", because its electronics need to be restarted all the time. It's also known as "Brasilia Jet", in a allusion to the EMB 120 Brasilia, which it succeeded. "Problem", Brasilia is also the name of a old volkswagen car from the 70s that for being cheap, it was very used on user's customisations - not all of them with a good taste. Note the two exhausts in the back - you shove 2 more wings on it and you have a ERJ-145!!!

This is too good to let it pass unchecked!!

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,