JonnyOThan

Pretty doubtful. As I said - it's extremely common for "verify files" to report 1 or 2 modified files because the game updates them (settings.cfg and partdatabase.cfg) with new data.

This confirms that you ran out of memory: System Commit Total/Limit/Peak: 30502MB/30536MB/31211MB Disk space data for '...': 198877184 bytes free of 238122168320 total. The peak commit size is greater than the limit, so an allocation failed and the game generally can't handle that. The commit limit is only ~30GB, which is strange given a physical ram size of 16GB - but we can also see that your drive is nearly full (189MiB free!) so the pagefile could not grow automatically. You need to keep at least 48GB free on your drive. Also note there were bugs in older versions of KK, especially regarding launch sites on other bodies. In any case, glad it's working.

Thanks! Copying my response here too: Thumbs.db is a windows cache file, and windows will edit or delete it as it feels like. So the file isn’t missing from the mod; it was probably installed and then removed by windows. Ideally this would not be included in any mod releases, but we can also filter it out in CKAN’s install instructions for the mods that do include it. Or you can add a global filter so that thumbs.db files are never included.

Thumbs.db is a windows cache file, and windows will edit or delete it as it feels like. So the file isn’t missing from the mod; it was probably installed and then removed by windows. Ideally this would not be included in any mod releases, but we can also filter it out in CKAN’s install instructions for the mods that do include it. Or you can add a global filter so that thumbs.db files are never included.

Post your KSP.log file.

Sure. By all means, good science is changing one variable at a time. But my money is on running out of memory. The error.log file contains a record of the peak commit size and the commit limit. Windows typically restricts the pagefile to 3x the physical ram size so if OP has 8gb or less that can easily not be enough for everything KSP allocates. Another common cause is limited free space on the drive where the pagefile is stored.

You certainly do not have the same install because OP has stuff in NewInstances that are not part of Kerbinside. I can’t be sure if those are causing the issue but at the same time you can’t be sure they aren’t. As I mentioned: most crashes are from running out of memory and the error.log file will prove or disprove that.

Well that's the thing. That wasn't a hardware problem, it was an out of date mod. Most crashes are caused by running out of memory, but considering that it crashed downstream from the KK code and the build OP is using is is 3 years and 6 versions old, updating is probably a good first step. @Elite_937 if you could post the error.log file from the most recent folder in C:/Users/furio/AppData/Local/Temp/Squad/Kerbal Space Program/Crashes, that could help narrow down the problem. It's not uncommon at all for KSP to rewrite settings.cfg and partdatabase.cfg, which are also part of the Steam install. Verifying files almost always flags these as modified, but it's not an issue. If only one file is mismatched, I'd bet it was one of those. OP certainly did not have a bare minium Kerbinside install. I'm not sure where these came from, but they don't exist in kerbinside. KK has an annoying behavior of transposing certain configs into its own NewInstances folder, which means that if you uninstall certain KK packs you could still have files left behind and things can break. KK: GetModelByName: No StaticModel found with name: BADTFlatconcrete KK: LoadModelInstances: No Model named BADTFlatconcrete found as defined in: KerbalKonstructs/NewInstances/BADTFlatconcrete-instances.cfg KK: LoadModelInstances: No Model named BADTFlatConcreteTri found as defined in: KerbalKonstructs/NewInstances/BADTFlatConcreteTri-instances.cfg KK: [LaunchSiteManager] RegisterLaunchSite: Registering LaunchSite: Hillier Airbase Runway 1 isHidden: False

Hey Gryspar seems to be missing its biome map: [LOG 15:37:58.588] [Kopernicus]: texture does not exist! C:/Program Files (x86)/Steam/steamapps/common/KSP Vanilla/KSP_x64_Data/../GameData/OPX-NeidonPlus/Textures/PluginData/Gryspar_Biome.png

Yeah @Exo's Lab to be clear, and I don't know why we're all suddenly realizing this today (kcalbeloh and other worlds also do this): @Parallax:FOR[MPE] { Body { name = Edas This is going to apply to *every* top-level Parallax node, which means if you have other mods installed that have their own it will create multiple copies of the body configs.

Hey, you have an old version of Kerbal Konstructs installed. I'd suggest just using CKAN to install.

Apparently this has been fixed by the MPE dev but they hadn’t been able to update spacedock. But GitHub has the updated version. I switched ckan over to download from GitHub now so if you just hit refresh in ckan you should see an update available for MPE.

The infinite loading screen with parallax occurs because there is no Material node in the scatters for Zore. Adding one there fixes the issue. Should we change the CKAN metadata to point to github only? EDIT: I went ahead and did this; it should update in CKAN within 35 minutes. We can always undo or change that, just let us know.

I was able to reproduce the problem by installing MPE and Parallax. Looking at the exceptions and the parallax code, The issue is that MPE\Patches\Parallax\Scatters\Zore.cfg does not have a Material node. I added one and it loads fine.

Well yes, the ASET IVA is for the mk1-2 pod, which is the old version of the 2.5m pod. There's just some patches that shoehorn it into the new part, but stuff doesn't line up as you noticed. Not likely to be fixed, because it would basically mean redoing the entire IVA.

The ckan change has been reverted, try clicking refresh and make sure kopernicus expansion is updated to beta 9.1.1.

Can you post some logs somewhere? Did you use ckan to install? You may have been bitten by a recent change. If you did use CKAN, you should be able to fix this by installing the development build and setting the release stability threshold to “testing” in the ckan settings window.

Which part specifically?

Are you sure the colliders move? If it does that actually could be bad if it wiggles the center of mass of the part. Updating collider transforms is generally slow too...

Well, not really. Or just shoddy documentation (no surprise there). It’s not hard to see that “fixing” this is untenable. You can’t evaluate NEEDS until you know what mods are installed, therefore FOR clauses must be evaluated first. Otherwise you could end in a cyclical dependency. So…I guess you didn’t read the source code before you offered to help me read it?

Cool - just FYI, AFTER implies NEEDS so including DwarfPlanetsPlus in the NEEDS clause is redundant, but harmless. No, it doesn't. Why didn't you test it instead of relying on the documentation? The documentation you cited is explaining the patch ordering. It doesn't say anything about how MM gathers which pass identifiers exist, which is where the potential stumbling block is. Given this patch: @KOPERNICUS:FOR[ThisModDoesntExist]:NEEDS[AnotherModThatDoesntExist] { } !PART[mk1pod_v2]:NEEDS[ThisModDoesntExist] { } You'd expect the mk1pod to NOT be deleted, because the first patch should be removed, right? Wrong: [LOG 10:37:34.166] Config(@KOPERNICUS:FOR[ThisModDoesntExist]:NEEDS[AnotherModThatDoesntExist]) /weirdpatch/@KOPERNICUS:FOR[ThisModDoesntExist]:NEEDS[AnotherModThatDoesntExist] [LOG 10:37:34.166] Config(!PART[mk1pod_v2]:NEEDS[ThisModDoesntExist]) /weirdpatch/!PART[mk1pod_v2]:NEEDS[ThisModDoesntExist] [LOG 10:37:34.228] Config(PART) Squad/Parts/Command/mk1pod_v2/mk1Pod_v2/mk1pod_v2 Changed : /weirdpatch.cfg.cfg ThisModDoesntExist [LOG 10:37:33.968] Deleting root node in file /weirdpatch node: @KOPERNICUS:FOR[ThisModDoesntExist]:NEEDS[AnotherModThatDoesntExist] as it can't satisfy its NEEDS [LOG 10:37:34.115] Applying delete /weirdpatch/!PART[mk1pod_v2]:NEEDS[ThisModDoesntExist] to Squad/Parts/Command/mk1pod_v2/mk1Pod_v2.cfg/PART[mk1pod_v2] [LOG 10:37:34.330] :BEFORE[THISMODDOESNTEXIST] pass [LOG 10:37:34.330] :FOR[THISMODDOESNTEXIST] pass [LOG 10:37:34.330] :AFTER[THISMODDOESNTEXIST] pass

No, it doesn’t. That’s exactly what I’m warning about. FOR[X]:NEEDS[Y] declares that X exists regardless of whether Y does. Sure, but you said “kopernicus should be patching”

Kopernicus isn’t the mod doing that patch, it’s DwarfPlanetsPlus itself. Therefore NEEDS is redundant. I don’t know if there are things in the Kopernicus pass that DwarfPlanetsPlus actually needs to be ordered after (probably not). Be careful with FOR and conditional patches, because the existence of FOR is *not* conditional. Any patch that includes a FOR clause tells MM that the mod is installed regardless of whether its conditions are met. It is a cardinal sin to use FOR with a mod identifier that is not the mod containing the patch itself, because it will cause other patches to activate when they shouldn’t. Can you elaborate on this? Ah, you added this to the DwarfPlanetsPlus files? That seems reasonable.

See “through the eyes of a kerbal” Iirc some of the heat shields from tantares and bdb support this (as historically appropriate). It’s not hard to do as a patch, but I don’t really agree with the balance aspect in the stock game. Heat shields don’t even support fuel crossfeed! It might make sense for someone to provide an alternate copy of the stock heat shields that cost more money, mass, more tech to unlock, etc.

MKS is kind of a mess from the IVA standpoint: https://github.com/FirstPersonKSP/FreeIva/issues/289