Search the Community

Never allow more than one ModuleManager to be present in your installment. Some older DLLs don't have enough meta-data to allow KSP 1.12.x (and only it, previous releases were a yet worst mess!) to try to figure out what to load. Being not bad enough, I have evidences that some rigs are prone to fire up more than one instance of MM at once when this happens, and you end up having race conditions on the patching - this really screws up things. This appears to victimize MM 4.2.3 in special because, in the majority of the situations where a doppelgänger is also running, the most evident problem is the Localization's patches being screwed (with nodes copied inside themselves, really a mess). I could only detect this one by eye balling the ConfigCache - a very tedious task... Since it's not feasible to determine in advance which DLL is safe to have as a doppelgänger and which is not, the safest and easiest way out of the mess is to avoid having more than one Module Manager DLL in your rig as it would be plague (what, in essence, ends up being sometimes). As a matter of fact, I'm diagnosing some complex installments and decided to install MM 4.1.4 and 4.2.3 at the same time to see what happens with the patching on KSP 1.12.5 (MacOS). This ended up allowing 4.1.4 to be ran instead of 4.2.3, as the following log excerpts demonstrates: [LOG 21:50:19.605] ******* Log Initiated for Kerbal Space Program - 1.12.5.3190 (OSXPlayer) en-us ******* Kerbal Space Program - 1.12.5.3190 (OSXPlayer) en-us <yada yada yada> ************************************************************************ Environment Info Unix 7FFFFFFFFFFFFFFF Args: KSP -crash-report-folder /Users/lisias/temp/ksp Mod DLLs found: Stock assembly: Assembly-CSharp v0.0.0.0 Scale_Redist v1.0.0.0 / v2.5.0.62 ModuleManager v4.1.4.0 ModuleManager v4.1.4.0 <----- doppelgänger!!! <yada yada yada> [LOG 21:50:48.120] [ModuleManager] version 4.1.4.0 at /Users/lisias/Workspaces/KSP/runtime/1.12.5/GameData/ModuleManager.4.1.4.dll won the election against Version 4.1.4.0 /Users/lisias/Workspaces/KSP/runtime/1.12.5/GameData/ModuleManager.4.2.3.dll So, and assuming that you just installed things by unzipping the whole contents without removing unwanted things after (the most usual M.O. on userland), it's pretty unlikely that MM 4.2.3 would be causing any trouble for you, because 4.1.4 would be the one being run, perhaps twice (I never managed to reproduce this MM being run twice behaviour on my rig, it appears to be tied to some CPU models). So, in a nutshell, never, ever allow more than one Module Manager be present in your whole rig. === == = POST EDIT Well... I did this test: tried the GDLV3 stock craft on a test bed exactly like this one. In one test session, I used MM 4.2.3, and in another I used 4.1.4. In both cases, the ConfigCache generated were identical (compared char by char). There's no way MM 4.2.3 would caused the problem you depicted. In both cases, the image I got was: Whatever is happening on your rig, changing to MM 4.2.3 must be a coincidence. But, to be certain, I suggest you do what I did: Install MM 4.2.3 on this test bed. Delete ConfigCache. Fire it up, fly the GDLV3 and see what happens Rename the ModuleManager.ConfigCache to ModuleManager.ConfigCache.mm423. Remove MM 4.2.3, install 4.1.4. Fire it up, fly the GDLV3 and see what happens Rename the ModuleManager.ConfigCache to ModuleManager.ConfigCache.mm414. Compare both ConfigCache for differences. I think this may be related to VRAM (there are too many programs using video et all opened? On my old potato, I could not watch Youtube and play KSP at the same time!). Perhaps deleting the Settings.cfg and the PartDatabase.cfg (on the same place where the EXE file is) would help? If nothing helps, post your full KSP.log (quit KSP before copying the file, to prevent KSP from truncating it) after reproducing the problem again. I would like to see it to check if I find something on it that I recognize.

I "reverse engineered" your KSP.log and replicated your installment on my rig. It's not a 100% replica because I'm on MacOS (what gave me advantages sometimes), but it works very well as long as I don't try to use something tied to Windows or to a specific GPU driver. And the damned thing works for me. Now, I have some theories about what could be happening based on previous experiences on diagnosing heavy loads on KSP on multiple OSes. Perhaps you have same pretty old Add'On installed, and when I reproduced your rig here I ended up installing a newer one"by accident"; or You have yet less RAM than me, and you just blew it up while running the game. MacOS is way more resilient to this than Windows, I can overcommit up to 4 times my RAM before the rig goes birds up. So I can survive borderline situations than Windows users just can't. But it costs me dearly, performance goes to the deepest circle of Dante's Inferno... [LOG 17:04:01.624] [AutoSave]: Game Backed Up and Saved [LOG 17:16:00.292] Flight State Captured Yeah, you read it right. 12 Minutes between two log entries... So I have two suggestions for you: Suggestion One: Create a COMPLETELY NEW KSP installment using CKAN, importing a CKAN file I created for my test bed. My test bed was created using it. The file is here. Copy your savegames into the new rig and see if the problem goes away. DO NOT TOUCH YOUR ORIGINAL KSP INSTALLMENT. Sheet happens , don't risk your valuable savegames on potentially destructive tests. Suggestion Two (also on the new RIG, these ones are, indeed, destructive): Remove Parallax and all its dependencies Check if the problems goes away if yes, PROFIT! if not, keep walking Remove EVE and all its dependencies ditto If you reach this point, send me a new KSP.log. And let's start again. For the records, I found two things in your log that I failed to identify: * GameData/Custom * GameData/Custom_FARAeroData.cfg But I doubt they have any influence on the problem. At last, but not at least, TweakScale™ (the original) uses a OPT-IN doctrine, where I strictly refuse to mangle to 3rd parties directly - and even the Companions don't brute force anything on Add'Ons that removes TweakScale support from their parts preemptively. It's safe to use TweakScale™ with Realism Overhaul (and anything else) and make good use of it on the parts that are still scalable, as trusses. -- -- ping @redekr!

Damn, something is screwing up with your KSP!!! [Edit: yes, and it was me] This is what is being shown on mine: On Editor: On Flight: Do you have KSPCF installed? [EDIT: Just installed KSPCF and nothing wrong happens. KSPCF may, at worst, be just the trigger or the enabler, the root cause is something else] === == = POST EDIT I opened a ticked on KSP-Recall to investigate this issue!!! https://github.com/net-lisias-ksp/KSP-Recall/issues/75 @Krazy1, can you please share your CKAN Export and KSP.log where the problem happens? --- -- - POST EDIT Found the problem, my fault. Fixing it.

Looks like some 3rd party borking on you. Please send me your KSP.log after reproducing the problem (and quitting KSP to prevent it from truncating the log) and I will try to figure out what's happening. --- POST EDIT --- Note to my future self: case diagnosed, but I can't further help due the add'on involved.

Send me your KSP.log. I have a hunch about what it can be, but I want to be sure analyzing your log first. Additionally, what are these parts? I recognized the Mk1-3 and the Hitchhiker Storage , but I don't know the two between them.

I think you need to update your project's references. Unity 2019 changed how things are deployed - before that, lots of things were being packaged on a single Assembly. From 2019 they had granularized the packages a lot. Make sure you are referencing at least UnityEngine.CoreModule but also UnityEngine.ImageConversionModule. It's a bit weird, but the CoreModule "kinda knows" about where everything are, including the things it doesn't have itself. I think that Visual Studio hints you about the need to reference needed Modules somewhere in the log system. Try this link - but I can't help on SelectImage, I didn't knew about this one until you mentioned it. Google tells me it may be something related to Unity's AR? Are you using the IMGUI? This thing is kinda weird - you need to "draw" your widgets inside a callback called OnGUI . This thing is called on every frame so, yeah, you need to be careful about what you put on that callback. It's better to precompute everything you will need on OnGUI outside it, perhaps on OnStart or some other callback, and then use such precomputed info on OnGUI to save CPU cycles - not to mention avoiding screwing up with the Garbage Collector (that it's already screwed up by itself, it doesn't need help on that!)

Makes no sense. Really. Please send me the KSP.log - there's something else there, and I want to see what's happening.

Ugh. One month later… If you still have the problem publish your KSP.log and I will see what's missing. You, perhaps, had installed Firespitter Core only? In a way or another: ANNOUNCE Release 26.6.2.1 is available for downloading, with the following changes: Pulling a fast one: fixing the cause of the infamous TweakScale's warning NULL ConfigNode for <part-path> (unholy characters on the name?). Trying partConfig instead! at the same trying to salvage any current patchset, partset or UbioWeld made parts by keeping the meshes and textures on the original place. It's deceiving because the "problem" is still there, I only moved it around to a place where TweakScale will not complain. @Krazy1 asked about some annoying warnings trigged on AirplanePlus on the TweakScale Companion thread, and while explaining them the problem suddenly I got an crazy idea (pun not intended) about how to work around the problem without breaking legacy - and the damned thing worked! What's next I couldn't get in touch with @blackheart612 since my last release, did a last try today. But I'm not holding my breath on the hopes on reusing the CurseForge and SpaceDock entries - so I'm considering how to proceed from here without throwing anyone under the bus (neither putting my SAS on the window). Other than the stunt I pulled above, there's nothing new, and I'm still strugging a bit on working on the backlog I had posted in the last release: Disclaimer By last, but not the least... This Release will be published using the following Schedule: GitHub, reaching first manual installers and users of KSP-AVC. Right now. Others are still being worked out at this moment.

Using spaces on pathnames is a less than ideal habit that it's plaguing KSP since years ago. This lead to problems on patching, as well on the prefab. This is cumbersome because sometimes a part can be created at runtime, and then whatever you put on the pathname will not exist anyway - and then we get on an weird situation in which TS can't tell if a part exists only on the prefab or also in the GameData. So TS emits this warning to mark the event and help me on the diagnosing when things goes south - this warning saves me time on diagnosing. Ideally fixing the pathnames would be the best solution, but this will break anything else that would rely on these pathnames. It's a catch-22 situation, I fix this problem on A+, some people will get their games screwed (users of UbioWeld in special). So, until I find a proper solution that would not screw up current users, I concluded that living with this warning is the lesser of evils at this time. — — POST EDIT — — You can shove a file called KSPe.cfg in your <KSP_ROOT>/PluginData with the contents: KSPe { DebugMode = False Log { ThreadSafe = False LogLevel = 5 } LOCAL { TweakScale { DebugMode = False Log { ThreadSafe = False LogLevel = 1 } } TweakScale.Sanitizer { DebugMode = False Log { ThreadSafe = False LogLevel = 1 } } } } This will suppress all WARNINGS and INFOs from the log. But I will not be able to help you if you send me such a log, as it will be missing important data I use on diagnosing. — — POST POST EDIT — — Wait! You gave me an idea. Sounds like a stupid one at first glace, but I think it worths a shot… Stay tuned! — — POST POST POST EDIT — — Damn! The stunt worked! I'm releasing an new AirplanePlus (/L) release today!!! — — POST POST POST POST EDIT — — Done! Nothing fancy, only a dirty trick to keep TweakScale happy without screwing up legacy patches, or people using UbioWelding.

UGH, really UGH… I had coded that message for a reason, sorry. I hope one of the backups mentioned by @Aelfhe1m can restore your game - but I would advise to COPY & PASTE the file, and then rename the copy instead of just rename an "original'. If by a bad of luck another disaster happens, you may lose one of the backups - and, yeah, I was bitten by this before (I really had coded that message for a reason!) As @Aelfhe1m said above, in order to diagnose your problem I need access to your KSP.log (the whole one, so you need to quit KSP before copying it - trying to copy it with KSP running sometimes truncate the file, rendering it useless). You can use any file sharing service you want, as google drive (remember to allow people to download the file, or I will have to ask permission first and this will made things slower). If you have a github account, you can create a new discussion here: https://github.com/TweakScale/TweakScale/discussions/categories/support — — POST EDIT — -- The user's post were approved after I'm posting. So, @guyontheinternet2000, lets dig into your log: Anyway, let's dig on it. I found the parts mentioned by the FATALity: [LOG 13:58:29.334] [TweakScale] ERROR: **FATAL** Part NB0mLFOengine1 (MRS Liquid Fuel Engine, 0.625m "Sparkler") has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 13:58:29.335] [TweakScale] ERROR: **FATAL** Part NBfuelCell1m (MRS Inline Fuel Cell Array) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 Duplicated properties was a problem in the part, but nowadays they shouldn't be causing so much trouble. I don't know why your savegame got corrupted, it's some years since I duplicated module caused trouble. In a way or another, lets see who is patching your parts twice. Follow every patch applied into NB0mLFOengine1: [LOG 13:53:50.344] Applying update 999_KSP-Recall/patches/fundskeeper/@PART[*]:HAS[!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA]]:NEEDS[KSPRECALL-FUNDSKEEPER] to NecroBones/ModularRocketSystems/Parts/Engine/NB0mLFOengine1/part.cfg/PART[NB0mLFOengine1] [LOG 13:53:51.448] Applying update 999_KSP-Recall/patches/refunding/@PART[*]:HAS[!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA]]:NEEDS[KSPRECALL-REFUNDING] to NecroBones/ModularRocketSystems/Parts/Engine/NB0mLFOengine1/part.cfg/PART[NB0mLFOengine1] [LOG 13:53:52.075] Applying update 999_KSP-Recall/patches/stealbackfunds/@PART[*]:HAS[!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA]]:NEEDS[KSPRECALL-STEALBACKFUNDS] to NecroBones/ModularRocketSystems/Parts/Engine/NB0mLFOengine1/part.cfg/PART[NB0mLFOengine1] [LOG 13:54:10.602] Applying update UmbraSpaceIndustries/MKS/Patches/ScrapParts/@PART[*]:HAS[!MODULE[FlagSite],!MODULE[KerbalEVA]] to NecroBones/ModularRocketSystems/Parts/Engine/NB0mLFOengine1/part.cfg/PART[NB0mLFOengine1] [LOG 13:54:28.420] Applying update NecroBones/ModularRocketSystems/Patches/TweakScale/@PART[NB0mLFOengine1]:NEEDS[TweakScale]:FOR[ModularRocketSystems] to NecroBones/ModularRocketSystems/Parts/Engine/NB0mLFOengine1/part.cfg/PART[NB0mLFOengine1] [LOG 13:54:28.610] Applying update NecroBones/ModularRocketSystems/Patches/TweakScale/@PART[NB0mLFOengine1]:NEEDS[TweakScale]:FOR[ModularRocketSystems] to NecroBones/ModularRocketSystems/Parts/Engine/NB0mLFOengine1/part.cfg/PART[NB0mLFOengine1] [LOG 13:54:33.693] Applying update SigmaDimensions/Configs/ReDimension/rescaleAntennas/@PART:FOR[SigDim2] to NecroBones/ModularRocketSystems/Parts/Engine/NB0mLFOengine1/part.cfg/PART[NB0mLFOengine1] [LOG 13:54:35.754] Applying update SigmaDimensions/Configs/ReDimension/rescaleSCANsat/@PART:FOR[SigDim2] to NecroBones/ModularRocketSystems/Parts/Engine/NB0mLFOengine1/part.cfg/PART[NB0mLFOengine1] [LOG 13:54:59.450] Applying update KSPCommunityFixes/MMPatches/ModSupport/KSPRecall/@PART[*]:HAS[@MODULE[Refunding]]:LAST[999_KSP-Recall] to NecroBones/ModularRocketSystems/Parts/Engine/NB0mLFOengine1/part.cfg/PART[NB0mLFOengine1] [LOG 13:55:01.073] Applying update KSPCommunityFixes/MMPatches/ModSupport/KSPRecall/@PART[*]:HAS[#hasRefundingOnRecovery[?rue]]:LAST[999_KSP-Recall] to NecroBones/ModularRocketSystems/Parts/Engine/NB0mLFOengine1/part.cfg/PART[NB0mLFOengine1] [LOG 13:55:01.302] Applying update KSPCommunityFixes/MMPatches/ModSupport/KSPRecall/@PART[*]:HAS[#hasRefundingOnRecovery]:LAST[999_KSP-Recall] to NecroBones/ModularRocketSystems/Parts/Engine/NB0mLFOengine1/part.cfg/PART[NB0mLFOengine1] [LOG 13:55:02.008] Applying update 999_KSP-Recall/patches/attached-on-editor/@PART[*]:HAS[!MODULE[ProceduralPart],!MODULE[WingProcedural],!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA]]:LAST[KSPRECALL-ATTACHED-ON-EDITOR]:NEEDS[TweakScale] to NecroBones/ModularRocketSystems/Parts/Engine/NB0mLFOengine1/part.cfg/PART[NB0mLFOengine1] [LOG 13:55:03.329] Applying update InterstellarFuelSwitch/PatchManager/ActiveMMPatches/IntegratedDecoupler/@PART[*]:FINAL to NecroBones/ModularRocketSystems/Parts/Engine/NB0mLFOengine1/part.cfg/PART[NB0mLFOengine1] [LOG 13:55:06.792] Applying update UmbraSpaceIndustries/Konstruction/Patches/EVAConstructionTweaks/@PART[*]:HAS[!MODULE[ModuleCargoPart],#mass]:Final to NecroBones/ModularRocketSystems/Parts/Engine/NB0mLFOengine1/part.cfg/PART[NB0mLFOengine1] [LOG 13:55:08.767] Applying update WarpPlugin/Patches/OreTanksFix/@PART[*]:FINAL to NecroBones/ModularRocketSystems/Parts/Engine/NB0mLFOengine1/part.cfg/PART[NB0mLFOengine1] And I found it: [LOG 13:54:28.420] Applying update NecroBones/ModularRocketSystems/Patches/TweakScale/@PART[NB0mLFOengine1]:NEEDS[TweakScale]:FOR[ModularRocketSystems] to NecroBones/ModularRocketSystems/Parts/Engine/NB0mLFOengine1/part.cfg/PART[NB0mLFOengine1] [LOG 13:54:28.610] Applying update NecroBones/ModularRocketSystems/Patches/TweakScale/@PART[NB0mLFOengine1]:NEEDS[TweakScale]:FOR[ModularRocketSystems] to NecroBones/ModularRocketSystems/Parts/Engine/NB0mLFOengine1/part.cfg/PART[NB0mLFOengine1] Let's see the NBfuelCell1m: [LOG 13:54:28.427] Applying update NecroBones/ModularRocketSystems/Patches/TweakScale/@PART[NBfuelCell1m]:NEEDS[TweakScale]:FOR[ModularRocketSystems] to NecroBones/ModularRocketSystems/Parts/FuelCell/NBfuelCell1m.cfg/PART[NBfuelCell1m] [LOG 13:54:28.820] Applying update NecroBones/ModularRocketSystems/Patches/TweakScale/@PART[NBfuelCell1m]:NEEDS[TweakScale]:FOR[ModularRocketSystems] to NecroBones/ModularRocketSystems/Parts/FuelCell/NBfuelCell1m.cfg/PART[NBfuelCell1m] And, yep, same thing. The problematic patch is on <KSP_ROOT>/GameData/NecroBones/ModularRocketSystems/Patches/TweakScale.cfg. Curiously, I checked the repository for this patch https://github.com/zer0Kerbal/ModularRocketSystems/tree/master/GameData/NecroBones/ModularRocketSystems and didn't found any patches on it! What's not a surprise because this was already diagnosed and the author removed the problematic patch, that was removed on release 1.13.99.0 (the current one is 1.13.99.2). So you installed an older version, before the fix. Digging deeper, I detected you are using CKAN, and… Yeah. https://github.com/KSP-CKAN/NetKAN/blob/master/NetKAN/ModularRocketSystem.netkan CKAN is pointing to the rigtht place (Necrobones had passed the torch to @zer0Kerbal). The current maintainer fixed the problem but didn't updated SpaceDock. I will enter in touch with him. Until there, right now your quickest way our of the mess is to manually delete <KSP_ROOT>/GameData/NecroBones/ModularRocketSystems/Patches/TweakScale.cfg. Additionally, I strongly recommend you remove every instance of "MiniAVC.dll" from your rig. Your KSP.log is littered with exceptions like this: [LOG 13:53:40.794] MiniAVC -> System.IO.IOException: Sharing violation on path /home/deck/.local/share/Steam/steamapps/common/Kerbal Space Program/GameData/ContractPacks/GAP/MiniAVC.xml at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share, System.Int32 bufferSize, System.Boolean anonymous, System.IO.FileOptions options) [0x0019e] in <9577ac7a62ef43179789031239ba8798>:0 at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode) [0x00000] in <9577ac7a62ef43179789031239ba8798>:0 at (wrapper remoting-invoke-with-check) System.IO.FileStream..ctor(string,System.IO.FileMode) at MiniAVC.AddonSettings.Load (System.String rootPath) [0x0001b] in <ad9b32d02f1147feadee20ffab2cf737>:0 at MiniAVC.AddonLibrary.ProcessAddonPopulation (System.Object state) [0x0006c] in <ad9b32d02f1147feadee20ffab2cf737>:0 I would also recommend to install the latest TweakScale Companion The ÜberPaket. You have only a handful of Companions installed (FS, PKMC and Restock_Plus), but some add'ons in your rig needs updated patches, like: None of these are mandatory installs (there's a few add'ons that must have the respective Companion when TweakScale is present), but I think you would like to have them installed nevertheless - at least I think you would like to have your Engines' FX scaled. Cheers!

This is absolutely odd. The Available attribute is not changeable by user's interaction, something need to set it programatically. The only situation in which TweakScale changes this attribute itself is when the part is declared insane by the Sanity Checks - but by this time, you would not be able to even scale the thing at first place. And since the Sanity Check only runs once on startup, we can rule out this code being triggered by a Check for sure. On a wild guess, there's something installed on your rig tampering with this attribute. The techRequired attribute was added to this part by the TriAlpha.cfg config file itself, so it's an intended feature for sure. No 3rd parties involved on the mess. Yet. BUT… Since you "fixed" the problem by removing this attribute, we can assume it's involved somehow on the mess. And, in fact, TweakScale filters the available scales for a part by the acquired techs. Digging into that code (it's some years since I looked on it by the last time already), the scales are filtered by matching the techRequired with the Techs nodes from the ResearchAndDevelopment Scenario on your savegame. Problem - unlocked Techs doesn't vanish from the savegame once they are unlocked. If you could scale that part on Editor, the Tech must also be available on Flight. So I can think on two possibilities: Something is screwing TweakScale on certain situations I'm guessing that it's almost sure this is happening, because someone had set Available to False in your savegame! And it was not TweakScale, otherwise you would be here complaining about that really pesky Houston messages on startup! An insidious bug on TweakScale is not ruled out, but I need to find a trigger! Something is screwing with the unlocked Techs on your savegame!! Pretty likely, because TweakScale virtually removes all the available scales that doesn't have it's techRequired satisfied. But since you created and launched the damn parte already scaled, you had that Tech unlocked for sure. We need to further diagnose your rig. There's something screwing your savegames and/or TweakScale. Neither you could. the techRequired only acts on a Career and Science games. On sandboxes, all the possible techs are assumed to be magically available. — @Turbo Ben, I think we should further pursue your issue. Everything related to unlocked Techs in your rig is at risk somehow. Please send me your savegame, your KSP.log, the Module Manager's log and configcache. Addionally, did you had played with these part scaled before? Did you updated something recently on your rig? What else did you installed on it? Are you using the Add'ons packed on the KSPIE zip file as they were packed or did you updated some of them? — — POST EDIT — — I found a probable bug on TweakScale that may explain part of the problems you describe. But not all! Stay tunned! — — POST POST EDIT — — Found the misbehaviour - and it explains the whole issue. A fix is work in progress, will be deployed ASAP.

Determined the exact Modus Operandi. The original part of the symmetry is being displaced, the cloned parts goes to the right place. This thing is the exactly opposite from what I was fearing - the cloned parts goes to the rigth place, it's the original part that is being misplaced. Go figure it out... Reproduced using: Harmony 2.2.1.0 KSP Recall 0.4.0.1 KSPCF 1.34.0.0. TweakScale 2.4.7.4 No changes on any config file. I don't even know what'a active or not on KSP-Recall. Yet. No part were scaled, they are all with the default scalings. No Exceptions found on KSP.log. [snip] Someone, somehow, is screwing the part symmetry when TweakScale™ is installed and BetterEditorUndoRedo is active. Given the hypotheses I raised above, it makes sense for me to check if I haven't missed any atrocities in my code (I'm not mad at you for thinking it could be TweakScale™, I was annoyed by you considering it without the due process first). [snip] the cloned parts on a symmetry are being correctly handled, it's the original part that it's misplaced. What's completely caught me with my pants down, because All the parts were unscaled. TweakScale™ is not even active on these parts! Literally, nothing is being executed!!! When you scale a part and apply symmetry on it, TweakScale™ gets some heat on the cloned parts, not on the original one. Worst, I didn't even used the Undo feature at any time neither! Fired up KSP Opened a random savegame Entered Editor Reproduced the problem pinpointed by @NippyFlippers, but using only the Command Module and the Fuel Tanks. This apparently rules out TweakScale™ from the list of probable suspects. Since I'm already here, I will proceed with the testings, this time checking if would not be KSP-Recall - besides having the remembrance that KSPCF deactivates some of its PartModules as it does the job itself.

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

Humm… On a wild guess, I think some of the files were shredded before you could remove them back from the recycle bin. Do you have how to redownload the SquadExpansion contents? I think that at this point, the best way out of the problem is to redownload the whole thing and then copy&paste the SquadExpansion directory from the fresh copy into your current rig. If even by doing that, you still get problems, please send me your KSP.log and ModuleManager.ConfigCache for inspection. I should be able to diagnose what's going on by inspecting these files.

Oukey, first the good news: [LOG 21:55:23.742] Applying update 999_KSP-Recall/patches/fundskeeper/@PART[*]:HAS[!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA]]:NEEDS[KSPRECALL-FUNDSKEEPER] to ProceduralParts/Parts/Tanks/1TankLiquid.cfg/PART[proceduralTankLiquid] [LOG 21:55:23.824] Applying update 999_KSP-Recall/patches/refunding/@PART[*]:HAS[!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA]]:NEEDS[KSPRECALL-REFUNDING] to ProceduralParts/Parts/Tanks/1TankLiquid.cfg/PART[proceduralTankLiquid] [LOG 21:55:23.957] Applying update 999_KSP-Recall/patches/stealbackfunds/@PART[*]:HAS[!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA]]:NEEDS[KSPRECALL-STEALBACKFUNDS] to ProceduralParts/Parts/Tanks/1TankLiquid.cfg/PART[proceduralTankLiquid] <...> [LOG 21:55:32.835] Applying update 999_KSP-Recall/patches/101_ProceduralPartsAttachmentNodesFix/@PART[*]:HAS[@MODULE[ProceduralShape*]]:N EEDS[KSPRECALL-PROCEDURALPARTS-AN]:FINAL to ProceduralParts/Parts/Tanks/1TankLiquid.cfg/PART[proceduralTankLiquid] Some of the KSP Recall Modules are being patched allright, including the Node Fixes. The bad news is that AttachedOnEditor, the PartModule that let attachment survives the Editor's screwups, wasn't patched on this part. I'm investigating the reason - I don't remember the detais of PP, I need to relearn some things here. — test -- this is a test.

That's interesting… Please restore your rig, reproduce the problem, quit KSP and send me somehow the KSP.log and the screwed craft file for analysis.

I think Forum still have that problem with attachments? Anyway, if you have a github account, shove the Log on a comment here: https://github.com/net-lisias-ksp/KSP-Recall/issues/41

Sometimes, Paranoid is the right word!! Hey, this is a known issue that I can't reproduce on my rig!! Thanks for your log, you don't have that much add'ons installed - so it reduced a lot the number of variables!! https://github.com/net-lisias-ksp/DistantObject/issues/32 Alt + Right Mouse Button - you must activate the option on DOE's control panel, "Show names on mouseover". Welcome and cheers! (I will check that bug again, now that I have a smaller footprint to work with!)

Well, first a pretty stupid answer: did you clicked on the Apply? The settings are persisted between scene changes? Now, a wild guess. I found two instances of this Exception on your KSP.log: [EXC 17:57:59.436] Exception: [VesselSpawner Error]: No part in loader found with name: PotatoRoid. ProtoVessel.CreatePartNode (Part part, System.String partName, System.UInt32 id, ProtoCrewMember[] crew) (at ProtoVessel.CreatePartNode (System.String partName, System.UInt32 id, ProtoCrewMember[] crew) (at <39c0323fb DiscoverableObjectsUtil.SpawnAsteroid (System.String asteroidName, Orbit o, System.UInt32 seed, UntrackedObj ScenarioDiscoverableObjects.SpawnHomeAsteroid (System.Int32 asteroidSeed) (at <39c0323fb6b449a4aaf3465c00ed3 KSPCommunityFixes.BugFixes.AsteroidSpawnerUniqueFlightId.ScenarioDiscoverableObjects_SpawnAsteroid_Prefix (S (wrapper dynamic-method) ScenarioDiscoverableObjects.ScenarioDiscoverableObjects.SpawnAsteroid_Patch1(Scenar ScenarioDiscoverableObjects.UpdateSpaceObjects () (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0) ScenarioDiscoverableObjects+<SpawnDaemon>d__33.MoveNext () (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0) UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnVa UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) Well, this is pretty suspicious as the PotatoRoid is the part used to… well… Asteroids. And since DOE enlists too the Asteroids, perhaps there's something mangling with the list of celestial bodies DOE uses to track… Celestial Bodies. You are not using Kopernicus neither anything I know that could mangle the that list. So unless you forgot some silly detail (as clicking "Apply"), we have something in need to be dug here in order to be diagnosed… I will see what I can do between working hours.

How they are staged? Everything is decoupled at the same time, or one by one? I'm assuming the decouplers are scaled, right? It would help me a bit if you could send me a minimum craft where the problem happens. edit: the patch above is useless, the problem is completely unrelated to TweakScale's scalings. — — POST EDIT — — I tried the following test: Both the TD-06 Decoupler as the HECS were scaled up twice. I staged them sequentially. I cheated my way into orbit, and hit Stage 3 times. Everything worked fine to me, with Force Percent =0 as well =100. I'm pretty sure this is a problem on something in your rig at this point - can you send me your KSP.log too? — — POST POST EDIT — — I think I finally understood. You found yet another bug on KSP 1.12.5 (I'm betting happening since 1.8.0 or something later, as I never got this on 1.7.3 and 1.4.3, my KSP versions of choice for serious playing). When launching a craft, there's a chance (not sure the statistics) that the first satellite being decoupled by hitting stage would be decoupled into the Infinity. The new vessel is not computed as destroyed, I think it's being launched into Kraken's sphere of influence instantaneously. I managed to (more or less) deterministically reproduce the problem the first time I launch a craft when I load a savegame. Reverting to VAB and launching the thing again fixed the problem on every further attempt, until reloading the savegame from Main Menu (didn't tried quicksave/quickload). Additionally, I also determined that the problem never happens when using the Decouple button on PAW, it's something that I only reproduced by hitting Stage! So this is not something I could handle on TweakScale (being its fault or not), because the decoupling itself is working as expected, it's something that is only happening when the decoupling is executed by the code that handles the Stage keypress. Closing KSP and inspecting KSP.log and Player.log, I found this : [LOG 16:47:08.315] Packing Untitled Space Craft Probe for orbit [LOG 16:47:08.327] ObT : NaN M : NaN E : NaN V : NaN Radius: NaN vel: [NaN, NaN, NaN] AN: [4527.46041793627, -686736.988244428, 0] period: Infinity [WRN 16:47:08.327] [OrbitDriver Warning!]: Untitled Space Craft Probe had a NaN Orbit and was removed. What confirms that the first stage of the first launch of a recently loaded savegame is leading to the annihilation of the new craft when it's created by decoupling using the Stage button. I want to emphasise again that manually decoupling the decoupler via PAW never leaded to this problem on any of my tests. TL;DR: this is a new misbehaviour on KSP, present for sure on 1.12.5 and absent for sure on 1.7.3 and 1.4.3. (other KSP versions weren't tested). TweakScale apparently is a trigger to the problem by reasons beyound me at this moment. Was the problem happening too when manually decoupling the thing, I could consider TweakScale as a possible suspect, but since the problem only happens on staging, I can't blame other than KSP itself at this moment. — — — POST POST POST EDIT — — — The misbehaviour was reproduced with UNSCALED PARTS, completely ruling out TweakScale from the equation. When the part is at default scale, the Module TweakScale deactivate itself to save some CPU and, so, it's incapable of misbehavings. It's still possible that the presence of TweakScale on a part can trigger the problem, but in this case I think that any other add'on would trigger the problem the same because, well, TweakScale is inactive on unscaled parts - unless KSP itself would be calling an inactive MonoBehaviour what, frankly, would be a very stupid move. — — — POST POST POST POST EDIT — — — KSP 1.8.1. did not presented the problem. — — — POST POST POST POST POST EDIT — — — KSP 1.9.1 did not presented the problem. The misbehaviour were reproduced on KSP 1.10.1 and KSP 1.11.2 . So it's something that started to happen on KSP 1.10.x as it appears.

This thing only happens once a month, and even that if the ConfigCache was modified since the last time the message was issued. What you are describing is a clear anomaly. You will find a file called KSPe.InstallChecker.cfg on the directory <KSP-ROOT>/PluginData with the timestamp of the last CKAN message. Check if the contents of this file is being correctly updated on your rig. It's an anomaly. Please send me your KSP.log, but for good measure also the Player.log and the ModuleManager.ConfigCache. There's something wrong happening on your rig, and there's a good chance this is happening due a unfortunate interaction with a 3rd party or even some unhappy monkey patching and I will need every bit of information available to infer the reason is it's something non trivial!

This is, for sure, something preventing TweakScale from being correctly loaded into memory! Publish the KSP.log where the problem happens and I will inspect it, looking for the problem. hint: check if there's a file called 999_Scale_Redist.dll on the GameData directory - most of the time, it's absence is the problem. If this was the problem, please consider installing ModuleManagerWatchDog - it does a series of defensive checks for the most frequent problems and it would had prevented you from being bitten by this mishap.

I found the problem. Dude, this one is a new for me! [LOG 09:18:31.667] Config(+PART[]) ModeratelyPlaneRelated/Compatibility/SAE_BetaPart_Compatibility/+PART[] <...> [LOG 09:16:44.555] Applying copy ModeratelyPlaneRelated/Compatibility/SAE_BetaPart_Compatibility/+PART[] to B9_Aerospace_ProceduralWings/Parts/Aero_Wing_Procedural/wing_ procedural_typeA.cfg/PART[B9_Aero_Wing_Procedural_TypeA] [LOG 09:16:44.555] Applying copy ModeratelyPlaneRelated/Compatibility/SAE_BetaPart_Compatibility/+PART[] to B9_Aerospace_ProceduralWings/Parts/Aero_Wing_Procedural/wing_ procedural_typeB.cfg/PART[B9_Aero_Wing_Procedural_TypeB] <...> [LOG 09:16:58.921] Applying update WildBlueIndustries/Pathfinder/ModuleManagerPatches/MM_Skills/@PART[*]:NEEDS[Pathfinder]:HAS[!MODULE[KerbalEVA],!MODULE[ModuleAsteroid]] to ModeratelyPlaneRelated/Parts/Engine/caesar_hone_75_tvn__TALON/tfj_229.cfg/PART[SAE_tfj_229_avc] [LOG 09:16:58.922] Applying update WildBlueIndustries/Pathfinder/ModuleManagerPatches/MM_Skills/@PART[*]:NEEDS[Pathfinder]:HAS[!MODULE[KerbalEVA],!MODULE[ModuleAsteroid]] to ModeratelyPlaneRelated/Parts/Engine/caesar_hone_75_tvn__TALON/tfj_229.cfg/PART[] All your problems started after applying a patch from ModeratelyPlaneRelated . I'm afraid you will need to remove ModeratelyPlaneRelated to have a wealthy KSP again. I also suggest you apply a bug report to them - TweakScale may be the one complaining now, but you can bet your SAS this is affecting more people, just check how many reports for this problem you have only here on Forum!

Absolutely nothing wrong, the partConfig after patched is flawless. There's something wrong happening at runtime for sure. Now the problem is diagnosing what. This CopyToRecursive problem is plaguing KSP for ages. I handled that once on TweakScale, this happens when we have a PART with name = "". And since we have a lot of complains about "part ''" on your log, it fits. Problem is that I don't have the slightest idea about who, where and when this huge amount of parts with name = "" is being created on your rig. And analysing your ConfigCache I found 1622 "name" entries with empty strings! Checking again your ConfigCache, I found: UrlConfig { parentUrl = ColdWarAerospace/Parts/Command/Helix-A_Cockpit/Helix-A_Cockpit.cfg PART { name = Helix-A_Cockpit module = Part author = L0ck0n <yadda, yadda, yadda!! } UrlConfig { parentUrl = ColdWarAerospace/Parts/Command/Helix-A_Cockpit/Helix-A_Cockpit.cfg PART { name = module = Part author = L0ck0n <yadda, yadda, yadda!! } And this pattern is being repeated for every single PART in your game. Oukey, you are royally screwed, but at least we now know what and where - now we need to find when and who. Checking again your KSP.log, it finally caught my attention that every single part was being patched twice, what's a symptom of having multiple Module Managers running. Since your CPU is not prone to that KSP bug when running on asymmetric CPUs, my best bet is you having more than one MM copy in your rig. HOWEVER… You have Module Manager Watch Dog installed, and it would had barked on you about this problem, and I didn't found any rogue DLL on your KSP.log neither. Damn. Well, so I looked for anything I historically know to play havoc on the system, and found this: [LOG 11:22:57.017] MiniAVC-V2 -> Executing: MiniAVC-V2 - 2.0.0.0 [LOG 11:22:57.017] MiniAVC-V2 -> Assembly: C:\Kerbal Space Program\GameData\KIS\Plugins\MiniAVC-V2.dll [LOG 11:22:57.017] MiniAVC-V2 -> Config not found: C:/Kerbal Space Program/KSP_x64_Data/../GameData/MiniAVCUpdateFrequency.dat [LOG 11:22:57.023] MiniAVC -> Executing: MiniAVC - 1.0.3.2 [LOG 11:22:57.023] MiniAVC -> Assembly: C:\Kerbal Space Program\GameData\WorldStabilizer\Plugins\MiniAVC.dll [LOG 11:22:57.023] MiniAVC -> Starter was created. MiniAVC is known to inject some problems on KSP in the past, so perhaps this is the problem now? Remove all instances of MiniAVC and see if the problem goes away.

Great. I probably screwed it, I will check ASAP . Thanks for the heads up! Found it: [LOG 11:29:54.815] [TweakScale] ERROR: part=SAE.tfj.229.avc (TFJ-229 "Talon" Afterburning Turbofan) Exception on Sanity Checks: System.Nul lReferenceException: Object reference not set to an instance of an object at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x00000] in <0435390348b6470d8166bd1c53b4b100>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <0435390348b6470d8166bd1c53b4b100>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <0435390348b6470d8166bd1c53b4b100>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <0435390348b6470d8166bd1c53b4b100>:0 at ConfigNode.CreateCopy () [0x00006] in <0435390348b6470d8166bd1c53b4b100>:0 at GameDatabase.GetConfigNode (System.String url) [0x0002f] in <0435390348b6470d8166bd1c53b4b100>:0 at TweakScale.PrefabDryCostWriter.GetMeThatConfigNode (Part p) [0x0002a] in <8e463f0c7a754587854563c7c6517452>:0 at TweakScale.PrefabDryCostWriter.checkForOverrules (Part p) [0x00000] in <8e463f0c7a754587854563c7c6517452>:0 at TweakScale.PrefabDryCostWriter+<WriteDryCost>d__3.MoveNext () [0x00417] in <8e463f0c7a754587854563c7c6517452>:0 at error:0 That's weird. Last time I got something like that, it was way back there on the 1.4.x times when Making History was introduced and screwed TweakScale due concurrent access to prefab on the Main Menu. I solved the problem by doing the checks before starting a game by the first time. Assuming there's no one screwing with TweakScale again, what we would have is a screwed part config in memory, and this happens dure some problems on Module Manager being instantiated more than once due (unsurprisingly!) one of the many bugs on KSP. But the trigger I know for this problem is a CPU with asymmetric cores, that e-core and p-core stunt and your i7-10750H is not one of them. Damn. So it must be something on the prefab. I ended up finding this: [LOG 11:24:53.679] [AtmosphereAutopilot]: part '' config node contains ModuleGimbal, moving it [LOG 11:24:53.680] [AtmosphereAutopilot]: part 'SAE_tfj_229_avc' config node contains ModuleGimbal, moving it [LOG 11:24:53.680] [AtmosphereAutopilot]: part '' config node contains ModuleGimbal, moving it What's pretty suspicious, as every part should have a name and it must be unique. Send me your ModuleManager.ConfigCache, I need to see exactly what's in your prefab.