4x4cheesecake

You're at least missing the dependencies for FMRS (ClickThroughBlocker and ToolbarController), as well as the required KerbinSide Remastered for KSC Extended. You probably also want to update EVE to EVE Redux, compiled for KSP 1.9-1.11.x. This should at least eliminate most issues I've found in your log, which honestly doesn't look too bad but may cause the game to crash anyway.

In case this is still relevant: yes, I can get back a normal state after switching back to the main menu and also after entering and leaving a building like the VAB or SPH but the KSC still starts floating after reloading a savegame again. Glad to hear I was able to find a way for you to replicate the issue, I hope it may help to find a way to solve it or at least to find a viable workaround

I dont have an idea but I was able to recreate the issue after noticing a minor detail in the logs: @SpaceInvader dont have any DLC installed and after removing them from my game, my KSC got burried under ground or started floating as soon as I reload any savegame. So these are the exact steps I took: -fresh install of KSP 1.11.1 -installed kopernicus, MFI und MM through CKAN -removed the "SquadExpansion" directoy from my install -removed physics.cfg und settings.cfg (just becasue I dont know if they contain any presets for the DLCs) -launched the game and started a new career savegame -created a quicksave at the KSC -load the quicksave -> KSC is mostly underground, after another reload it was gone at all and after a third reload it was floating, exactly like in the screenshots of SpaceInvader. I have absolutely no idea how the DLCs are connected to this issue but maybe you can recreate the bug now and get an idea

Okay, thank you. I'll file a bug report the next time Thank you for updating it as well Coming back from a long break, I'm glad to see this community being still as friendly and active as when I left

Hi there I stumbled upon a minor metadata issue for the "Routine Mission Manager" mod: the provided homepage link directs you to the old forum thread, not the one after LGG adopted the mod. Usually, I would report this directly on github, but I'm kinda puzzled which category I should put this in. After following the link in the OT to report metadata issues, I still had to choose between "bug report", "fetature request" and "mod request" and IMO, this wouldn't fit in neither of these. Is there anything I'm missing or would this actually classify as a "bug report"?

Thanks for the quick fix As far as I can tell, it works fine now

Unfortunately, release-27 failes to load in KSP 1.8.1. Tried updating through CKAN and manually installing the version found on github, always results in a massive exception spam. It happens in my highly modded JNSQ install: https://www.dropbox.com/s/easwjzjtmqug1ue/Player (kopernicus_issue).log?dl=0 And also in a fresh copy of KSP with just kopernicus installed (github version, release-27, manually installed): https://www.dropbox.com/s/b429s3rdh9vr6gi/Player(kopernicus_issue_fresh_copy).log?dl=0

Well, yes and no. CKAN doesn't update mods to another game version, this need to be done by a mod creator/maintainer. It is just a tool which simplifies the installation of mods to the game and it will always try to keep everything compatible to each other. But: You can always force CKAN to install every mod version to every game version you want. If you do this, you're always in the risk to break the game or at least the (probably incompatible) mod. I've described the process to do this in the "Advanced Stuff" section of the CKAN tutorial. Applied to the example in your question: You have to launch CKAN, pick your 1.10.1 install from the list of managed KSP instances (if you have more then one KSP instance installed and managed by CKAN). Then go to "settings" -> "compatible KSP versions" and select "1.7". This will allow CKAN to install mods which are not officially supported in 1.10.1 but 1.7.x. You can also select every other game version from 1.7 up to 1.10 to be sure, you'll always get the latest version of the mod. Alternative, if you don't want to allow EVERY 1.7.x mod to be available for your 1.10.1 game: In the CKAN main window, switch the filter from "compatible" to "all", search for the mod you want to install and select it. Then, switch to the "version" tab on the right side of the window to see a list of all available mod versions. Select the mod version you want to install... CKAN will warn you about the incompatibility but also asks you, if you really want to install the mod. Select "install" and CKAN will install the mod for you, despite any incompatibilities. For example:

Glad to hear it's working now

Check your difficulty settings for "Resource Transfer Obeys Crossfeed Rules": With this option enabled you are not able to transfer fuel through certain parts, mostly heatshields and constructural parts like this beam: You can disable/enable this option at any time but if you want to play with this option enabled, you can always bypass the crossfeed restriction by adding two fuel lines, one for each direction. For examples, it's not possible to transfer fuel between these tanks because of this option: But after adding a fuel line for each direction to bypass the beam, it works just fine: (pay attention to the direction of the arrows on the fuel lines) If you add just one fuel line, the option to transfer fuel will only appear on one of both tanks but it will still not work because the game tries to move fuel from one tank to the other but also to move "nothing" (let's assume some kind of gas to keep the tanks pressurized) in the other direction. Since the fuel line only transfer in a single direction, you need the second one for the other way

Maybe DOE can help you: it will render planets, moons and vessels in the distance and show you their names once you hover the cursor above them. It doesn't work for the stars on the skybox though (as far as I know, KSP uses a "fantasy" skybox so they are no names for the stars)

@Krzeszny As far as I can tell, clever sats doesn't set a expiration timer for their contracts so that's most likely the default time set by contract configurator. Also, you should read this post

The log is pretty clean for an install with that amount of mods, nothing really sticks out which would explain your issues. Did you monitor your RAM usage already? Planet packs usually add quite a bit to the RAM usage so maybe you just ran out of memory or you're close to it. Btw you can also try to remove just the planet pack but not kopernicus. If it loads fine, the reason is not kopernicus itself

yes, you can add a MM patch to your game to disable it: @kopernicus:final { @body,* { @pqs { @mods { @landcontrol { @scatters { @value,* { @components { !scattercolliders {} } } } } } } } } Just create a textfile within your GameData folder, name it however you like and change the filename extension to .cfg. Then copy&paste the patch into it, save the file and restart the game. I personally like to add custom patches in a specific folder which is named like "zzz_Final" or something like that, to keep everything sorted.

It's not an error, it's a warning and nothing to be worried about. Kopernicus checks the surroundings in a certain distance for scatter object and if there are any, it will add a collider to them but once you are "out of range" of a scatter object, it removes the collider again. I guess this is supposed to reduce the RAM usage. These kind of log messages can be used by the mod creator to verify, this part of the mod is working properly. No idea what's happend when your game shows just a black screen but when it happens the next time, you may want to save a copy of the log file and upload it for others to look at.

Should work as well, it's just important that you add the value you want to check for to the config node you want to modify. I've used a module because I had quite a few values to add and thought it would be more elegant to put all of them into a single module

As far as I know, you cannot check for variables in other nodes to apply a patch to something different. I tried it and failed miserably but I did something like that for my own config for simple fuel switch by adding the value from the settings to the parts I wanted to modify and then checking for the value in the actual patch. For example: Config file: My_Mod_Settings { change_this = true } 1. Patch: //This must adress everything which may or may not be patched depending on the settings //Use multiple patches like this if you cannot adress everything in a single patch @PART[*]:HAS[whatever_it_is_you_want_to_adress] { //Dummy Module MODULE { name = my_dummy change_this = #$My_Mod_Settings/change_this$ } } 2. Patch: //Actual patch to apply your changes @PART[*]:HAS[@MODULE[my_dummy]:HAS[#change_this[true]]] { //do whatevery you want to do } 3. Patch: //Cean up @PART[*]:HAS[@MODULE[my_dummy]] { !MODULE[my_dummy] {} }

Hm...that kinda looks like an issue within the mod itself to me. You installed everything properly, I can confirm that but there is a massive log spam of this line: So it looks like the mod is stuck in a loop. I would suggest to report the issue to the mod creator in the wind tunnel thread (I just took a look at the thread and there are actually already a few reports about the same issue): Sorry I cannot help you any further but I'm crossing finger that the bug will be fix soon

I just noticed that the mod already includes the dependency, sorry I should have checked that before. You can ignore the other github repo I've linked before. I've also tried the mod on my own to verify that it actually works and it does.... be sure that your GameData folder looks like this: (I didn't install AVP since it is just visuals) If you are sure you installed everything properly but the issue still persists, please launch the game, try to use the mod, close the game and then upload a log file to a filehoster or cloud service to share a download link here Check out the thread I've linked earlier if you don't know where the log file is located.

It's actually noticed in a pinned thread in this very subforum:

You forgot the most important dependency for every planet mod: Install Kopernicus (and the bundled ModularFlightIntegrator) as well and it should work By the way, the version of RSS on CurseForge and the linked ModuleManager version are for KSP 1.4.5, you may want to checkout the latest version of this RSS iteration: Same for Kopernicus: https://github.com/Kopernicus/Kopernicus/releases/tag/release-1.8.1-1

They are indeed pretty far away from each other but it may work out fine anyway. The reason you are not able to take off is a different though: The gear in the rear need to be between the center of lift and the center of mass. The elevons on the wings will not pull up your nose but they will push down your rear and as soon as your center of lift is behind the rear gears, this will actually lift your nose up. So move the gears a little bit forward and you should be fine. Well, you can also add some more elevons/winglets to your nose though but I would suggest to move the gears instead

Have you already tried if the other docking port still offers an "undock" option? Sometimes, when you have to switch the focus after undocking, the undocked craft will re-dock to the other craft and the "undock" option is usually just available for one of the ports. Well, if you are unlucky though, your craft might be corrupted. There are some rare cases, where KSP doesn't "cut off" the connection between two vessels properly and they stay connected after undocking. Do you have a savegame before you tried to undock the craft? If you actually run into this issue, it should be visible in the log at the exact moment you try to undock so that should be easy to find if you can reload a savegame, try to undock again and then upload the log file here for us. If you don't know anything about the KSP log files, take a look at this thread an read the section about logs, that should allow you to find them:

It works in the tutorial because it still uses the old flea engine instead of the updated one. I'm not sure if the new one is supposed to be better but using the new version will allow the vessel to gain additional ~11km height (23km vs 12km) while flying straight up. This causes your vessel to accelerate more while falling back towards the ground and therefore your chute will not open.

Do you play on a laptop or desktop pc? Which graphics card do you use? If you play on a desktop pc: is your display actually plugged into the graphics card or the mainboard?