4x4cheesecake

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