4x4cheesecake

Looks like you launched straight up in the sky, that's a huge mistake. Parachutes don't open in the second you activate them, this will just set them to be "armed" but you still need to reach a certain altitude, atmospheric pressure and speed for the chute to actually deploy. If any of these checks fails, the chute will not deploy or will be ripped apart (if you allow the chute to deploy while it's unsafe or risky). Even though the parachute symbol is grey at the moment you activate it, you'll gain way too much speed on your way down so you will be too fast for the parachute to open safely as soon as you reach an altitude, where the parachute is supposed to deploy. Try to fly at an angle instead, maybe even reduce the thrust and fuel of the flea in the editor so you don't gain as much speed and height in the first place. Flying at an angle will stretch out the trajectory, so you spend more time in the thicker parts of the atmosphere to slow down before the parachute can take care of your vessel.

Did you install the dependency as well? Also, a log file is always appreciated

That's caused by the terrain shadow created by scatterer: https://github.com/LGhassen/Scatterer/issues/68 Deactivating the terrain shadow or ignoring it are the only solutions for now.

AVC will direct you to the website, noted in the .version file of the mod. Many mod creators will put their github repository there but not always the release section of it but the code section, which presents you with a convenient download button. BEWARE: This will download the source code of this repository, not the compiled mod. You have to navigate on your own to the release section and download the actual mod there. If you are slightly confused now, you may want to check out my tutorial on this topic, especially the chapter about downloading the correct mod version. I've added a few screenshots there to make everything easy to follow

I've tried the patch posted by @overkill13 and it works perfectly fine on a 1.9.1 install with MechJeb. I would personally add two minor details though: @PART[largeSolarPanel]:FINAL { @MODULE[ModuleDeployableSolarPanel] { %isTracking = false } } Adding the :FINAL statement to custom patches is usually a good idea and using the % sign allows ModuleManager to edit OR create this entrie, depending if it already exists or not. Tried both versions and both worked as expected. I also tried the patch you have posted, which honestly contains a few mistakes but even this still works. So, I'm going to ask the question no one bother to ask before: Do you actually have ModuleManager installed? I know it's a dependency for MechJeb but if you installed it manually, you may forgot it. If you did, I would be curious to see your ModuleManager.ConfigCache and your KSP.log, because like I said, these patches work, just not for you so there must be something wrong on your side.

In my opinion, vertical speed is more important during landings then horizontal speed. If you go too fast horizontally, the worst thing that can happen is running off the runway but you can always add chutes and tweak the breaks to slow down faster. But if you hit the ground with more then 10m/s vertical speed, you will most likely crash immediately or at least some parts will break apart. This becomes more easy to handle with larger wing areas because your AoA doesn't need to be very high at low velocities to keep the vertical speed below 10m/s but it is definitely doable with small wings as well, it may take some practice to perform the flare maneuver correct though.

You want to install all 2386 mods which are currently listed on CKAN? I don't think that's possible and I cannot think of any reason to do that, especially since many mods are incompatible with other mods. You can install a bunch of mods through CKAN and create a .ckan file to reinstall all of them the next time, for example for a second install, but you still have to select them manually first. Maybe the CLI version offers something some more options I'm not aware of but still, why would you (or anyone) want to do that?

This will make your wings breaking even faster though. A little wobble may looks dangerous but it will act like a spring/damper to your construction. Anyway, the easiest way to solve this issue is to attach the gears not on the wings but the body of the shuttle/spaceplane and use the offset tool to move them to the wings. It will look like the gears are attached to the wings but actually they are still connected to the body which is a lot less fragile. If you don't like to use the offset tool in this way, you can always try to add just more gears to distribute the stress on the wings/gears. Also, at least in the video, you seem to carry back a lot of fuel, you should consider to start with less fuel so your spaceplane becomes much lighter during the landing.

The mod already exists

Is there an elegant way to ignore the whitelist provided from a mod? I would prefer to run a custom MM patch, so the mod parts which rely on stock parts will actually use the models and textures from restock. Of course, I could just delete the whitelist but I had to do it on every mod update and just ignoring it, will leave me with some unused models and textures in RAM, which kinda defeats the purpose of the whole "unload the unnecessary stuff" procedure.

Gm stands for "Gigameter" and 1Gm = 1,000,000,000 meter so for the simulator, this is your distance to the sun. The KSP wiki says, Jool has a Pe of 65,334,882,253m (or ~65Gm) and an Ap of 72,212,238,387m (or ~72Gm), so if you run the simulation for these distances, you should be able to figure out how much power your solarpanels will generate. I'm not sure if the game provides these distances somewhere ingame, I'm used to look it up in the wiki if I need some basic numbers^^

On a german keyboard layout (QWERTZ), you can use the "ü" and "+" key to switch between vessel within physics range

You can find the download link in the ModulManager release thread: You have to scroll down a bit to find the download link: This is indeed something I haven't covered in my tutorial and I'll add it on the weekend, thanks for pointing it out

Sounds like you downloaded the repository (master- something) with the source code instead of the mod. The download link is at the bottom of the release thread: For your convenience, I'll post it here as well: https://ksp.sarbian.com/jenkins/job/ModuleManager/157/artifact/ModuleManager.4.1.3.dll This .dll file needs to be in your GameData folder, like this:

Depends on how you remove these planets. If you just delete the required files from the mod, you have to do it every time you update the mod, regardless which install process you've used. But if you add a custom MM patch to your game which removes these planets, you don't have to worry about any updates in 99% of the cases (1% chance that a planet got renamed or new planets were added which needs you to adjust the patch). Of course, you can always handle the modding however it fits the best for you This^ That's why I recommend right at the beginning of this guide to move the game out of the steam directory as well. Are my instruction on ModuleManager not clear enough? I could add another picture to make it easier to understand and/or edit the instructions at all if you can explain to me at which point you struggled to follow

Yes, but _Zee is a bit busy so it may take some time, he mentioned that in the first post on this page. Hm...hard to say. You can "follow" this thread (there is a button for this next to the title) which will notify you about any new post in this thread. Since a new mod version usually comes with a post from the mod creator, you wouldn't miss it but you will also get a notification if anyone else posts something here.

@lokee81 That's one way to do it but it's also the worst way to edit config files. The prefered method would be a ModuleManager patch. It follows pretty much the same syntax of the config files but with some addition features. A ModuleManager patch allows you to modify config files without actually touching the original config so if you want to share the rsult, you dont have to reupload the whole mod again but just your patches. It's way more convenient and if something went wrong in your patch, the original config values can be used. In your shown example, this would be something like this (not 100% correct, it's just to explain stuff) @PART[bluedog_125mDecoupler]:NEEDS[PDB, BDB] { @TechRequired = the nech node you want to move your part to } "@" will tell modulemanager to EDIT something, in this case a "PART". Which part is defined within the [ ], in this case it's the part with the name "bluedog_125mDecoupler". Then you should add some conditions with the :NEED operator, so your patch will only be applied, if PDB and BDB are actually installed (you need the correct mod names here, usually defined by the name of the mod folder) Now you want to edit a value within this config, the "TechRequired" value. It defines which technode of the TechTree the part will be associated with ("category" is just for the filters in the editor). Again, the "@" operator will tell ModulManager to edit a value, but this time you don't need the [ ] to define which value, just the plain name is fine. Just put the new value here (for example "Start" to move it in the very first node of the TechTree). But how do you get the names of the Technodes? Well, you have to look them up in the config files of the Community TechTree mod, at least I dont know if there is a more convenient way. It is also possible to address more then one part in a single patch but you have to find something, these parts have in common. You can group them by modules or values of the original parts by using the :HAS operator. For example, you could use: @PART[*]:HAS[@MODULE[ModuleCommand]] to address each part which can be used to control a vessel (all probe cores and command pods) or: @PART[*]:HAS[#TechRequired[start]] to address all parts which are currently in the first node of the TechTree. I would highly recommend to look at the wiki of ModuleManager to learn more about the syntax: https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Handbook and the mod thread of ModuleManager is also a good point to get more info or help. For a better understanding what will happen with these patches: KSP will read every single .cfg file within the GameData folder to configure parts and other stuff like game settings. ModuleManager hooks into this process and modifies these read config files by applying the patches to them so KSP will use different values to set up the parts but the original config files are still there and untouched. It is even possible to write patches for patches because ModuleManager will follow a strict order to apply patches which can be manipulated by using keywords like :BEFORE or :AFTER so you can force MM to apply your patch after or before another patch from a different mod will be applied to the same part. It is an incredible powerful tool and worth the time to learn the proper usage

I had to try it on my own to believe that but yeah, you are absolute right, it's not precise enough for that kind of task. Best I could do was ~0.05kN adjustments on the torque while rotating a vector engine. I'm actually surprised that "Precise Editor" can do it at this level of precision but it's good to know^^

Hm...the log contains quite a few exceptions but nothing which should cause a crash. Does KSP create a crash log as well? They are kinda hidden in this path: %USERPROFILE%\AppData\LocalLow\Squad\Kerbal Space Program\Crashes You can copy&paste this file path into the adressbar of your file explorer and you should fine some folders called "Crash_xxx" where "xxx" is the timestamp of the crash (for example "Crash_2020_04_09_130830"). These folders contain an error log, which might hold some useful info, like ram usage. If one of these exists with a timestamp that fits to on f your crashes, would you mind to upload it as well? In the mean time, you can also try to increase your paging file (that's a file created by windows to store data which doesn't fit into the ram or/and is rarely used) so if you just ran out of ram this might help. It's easy to do but hard to explain so pls just google for "win 10 paging file" and you will find like a million tutorials which are easy to follow

Should be fairly easy with a simple MM patch: @PART[Engineer7500]:NEEDS[kOS,KerbalEngineer]:FINAL { MODULE { name = kOSProcessor diskSpace = 255000 } } Of course, you can change the diskSpace however you like. Should work but it's untested

If you have at least a level 2 tracking station, then yes, it's stronger. The RA-15 relay antenna can cover a distance of 27.39Gm (connection to level 2 tracking station), 61.24Gm (connection to level 3 tracking station) or 15Gm (connection to a second RA-15). The distance between Duna and Kerbin varies between ~6Gm and ~35Gm, so your relay will only work while Duna is close. On the bright site: If you can upgrade your relay satellites around Kerbin to a 100G relay antenna (RA-100), you should be able to connect to Duna at any distance without upgrading the relay around Duna (100G <-> 15G connection can cover ~38Gm) You may want to check out the wiki page about this topic, it contains some helpful sheets: https://wiki.kerbalspaceprogram.com/wiki/CommNet There are also these neat diagrams, which can be tricky to read on the first sight but once you've figured it out you will always know which antennas you should used to cover specific distances:

Something went wrong with your images but I guess you're relays are just out of range. I've put the two relay antennas into this spread sheet: https://docs.google.com/spreadsheets/d/1qIgFB8OXnlgpPCGsxv7JYUYQq5O671IcZXpumVaStek/edit?usp=sharing And the result is: Signal strength a max distance is 0% and 64% at min distance between kerbin and duna. So depending on the current constellation, you might be just out of range.

Do you have a google account (for example for an android smartphone or just because)? Then you already have a cloud as well: Go to: https://www.google.com/drive/ and log in with your account to get to the web interface. You will find a button in the top left corner to add files to your storage. Wait for the files to upload, then they will appear on the same page. Rightclick the file(s) to create a sharing link and post the link here. I'm pretty sure it's very similar with apple, in case you own any apple product you most likely have an account already, but it's just a guess. There is also microsofts one drive, if you already own a microsoft account. I've never used it but it should be straight forward and easy to find if you google for "one drive". If you don't already own an account for any of these, you may want to check out dropbox: https://www.dropbox.com I don't have much to say about it, it's pretty much the same everywhere: log in or create an account, somewhere (usually at the top) on the web interface is a button to select files to upload and then you can create a sharing link. Alternatively, you can just google for "filehoster". There are millions around the web with different limitations to the filesize. Some of them don't even need an account, which usually comes with the drawback of a really small file size limitation. I haven't used any filehoster in years, so I cannot recommend any one to you, sorry.

It's a part from ReStock+

Have you tried to use the already available "fine adjust"? It's not a button but you can decrease the adjustments steps to 0.001 and move/rotate everything with the arrow keys. The "position debug" window should provide every information you need. You can find both options when you click on the EEX button in the editor.