4x4cheesecake

Well done mission and thanks for keeping the space clean by crashing your debris Don't worry too much about missing an screenshot of the last aerobreak, it's really just the first one which is interesting Congratulations to the upgrade of your badge Correct, 350km is not geostationary but also, no one said it must be a circular 350km+ orbit Of course you can launch into a circular orbit above 350km, release the comsats and bring them in their final position on their own power, it's perfectly fine. A different approach would be a resonant orbit, for two reasons: The Pe would be above 350km (to fulfill the requirement) and it will also allow you to place the comsats in equidistant position. If you've never heard of resonant orbits, you may want to look at this nice tool: Well, if you actually want to try it without a resonant orbit: there is no official threshold and I'm not going to measure the angles of your final triangle. If you can look down at your satellites in map view and think "yeah, looks like an equilateral triangle", that's totally fine (It's also not perfect when using a resonant orbit though^^)

Yes, you already performed an aerocapture in your last mun mission. If you enter the atmosphere multiple times or just once, is up to you. It is just important, that you have to use the atmosphere to slow down your orbiter to reach an orbit around kerbin (circular or elliptical, doesn't matter). The opposite would be a "powered break" by using the engines and firing them in retrograde direction. This one as well I personally prefer to create the screenshot close to the Pe...if you got there without burning up, you'll be fine. Uh, nice! What are all these explosions during the launch? Looks like you got some parts overheating by exposing them to the engine exhausts Beside of that, it was a really good flight and you demonstrated some serious piloting skills by adjusting the engine thrust during the launch to reduce the torque and by controlling your descent trajectory by changing the pitch of the orbiter during the whole flight. The orbit of the fuel pod looks fine and luckily, all the fuel is still in it this time Also, you actually hit the runway this time, that's an important improvement This badge is for you and well deserved If you don't mind, I have a little suggestion though: It looks like your reaction wheels take too much control during the final approach of the runway and prevent small adjustments. You may want to switch their mode to "SAS only" (probably via actiongroup) or turn them off at all, so your orbiter is actually controlled by the elevons and not the reaction wheels

Silly me, you are absolute right. Commander needs a manned research facility, I'm sorry. Thanks for correcting me, here is your correct bade (I'll edit my previous post as well, just to prevent confusion) I see, thanks Well, I already thought that it will help you with this mission Oh, so close to the runway...that's unfortunate How did that happen? You were lined up very well during your approach. While I'm inclined to turn a blind eye regarding the landing this time, I need to ask you for another screenshot to proof that every tank of the 40t pod is actually filled and untouched. I can see the amount of ore in the resource window and you show the LFO tank but there is also a monoprop tank which need to be untouched and since you have used some monoprop during your mission, there is no way for me to see if the fuel was provided by the orbiter or the fuel pod. Just load your game, switch to the pod in orbit (which is hopefully still there) and open the resource window or right click every tank

Looks like you are right The shuttle looks very stable through the flight whole flight and even survived the steep reentry. I'm a bit surprised that you aimed for the Dessert Airfield instead of the KSC but of course, that's up to you and a perfectly fine choice I have a few questions though, just out of curiousity: These are a lot of engines you're firing during the launch, do you really need all of them? And why did you place the landing gear in an angle? Just for your personal style? Anyway, congratulations to your first badge

Career was added in version 0.22 and apparently, you try to play version 0.21... which is ancient. Where exactly did you buy the game?

That was fast Landing a shuttle on the mun can be quite challenging but you made it look like any other standard mun mission, well done! Interesting construction for the research facility, you are probably the first who build it in form of a rover For future interplanetary missions, please do me a favor and add a screenshot of your shuttle during the aerobreak, at least the first one. It's a very critical moment during these missions and it can be quite difficult to hit the "sweetspot", where you break just enough to get captured but don't burn up in the atmosphere. I have no doubt you made it, especially since your shuttle is pretty lightweight and there is no way you can burn up during this trip with a Pe of 60km around kerbin, but if you skip this phase in the mun missions already, you'll probably skip it during other missions as well Anyway, congratulations to your new badge Welcome back to KSP Your shuttle looks promising and I'm certain you'll be able to teach the ground crew how the booster should be attached to the orbiter in a way, it can be separated Good job on lithobreaking just enough to get rid of the unnecessary parts without flipping the whole thing around. If you didn't loose a wing, this would actually qualify you for a badge but it's probably not the best start into this challenge^^ Thanks for sharing this first impression, looking forward to your first actual entry

Under 40m/s? Wow, you need a lot of lift and pitch authority for this You can always go back to do skipped optional missions and/or to repeat missions you've already done (for fun or to qualify for a different category)

Thank you, very kind Very impressive landing on the first mission, you should record a video next time and make a tutorial "how to land a shuttle without a front wheel" And yes, of course this landing still counts since you didn't loose any parts The station looks cool, well done! I'm a bit surprised to find the MPL on it though but I guess you've asked about it so you don't have to use it twice? Also, I'm curious: the engines on the service module, are these puff engines? It's always a bit dark when they are visible ^^ Congratulations to your new badge Are we going to see STS-9 next or do you jump directly to the mun missions?

You don't need to use the MPL but you should put some scientific experiments on the modules to qualify them as "scientific modules" No, you can launch the modules in any order you like

@michal.don Enjoy your holiday Like the last time, I'll try my best to keep the challenge running

As soon as it is fixed? It's not like someone fixed the issue and thought "Let's wait one week more to activate the rep button again, just to annoy everyone" It is save to assume they are still working on it but sometimes, a bug need some time to be fixed and there is no way to tell, when it is done.

That's a bad mistake, logs are ALWAYS helpful In this case, it contains stuff like this: [EVE TextureConfig]: Unable to parse config node: OBJECT { name = EarthAuroras type = TEX_CUBE_6 isCompressed = True isReadable = True texXn = RSSVE/Textures/MainTextures/EarthAuroras/EarthAurorasXn texXp = RSSVE/Textures/MainTextures/EarthAuroras/EarthAurorasXp texYn = RSSVE/Textures/MainTextures/EarthAuroras/EarthAurorasYn texYp = RSSVE/Textures/MainTextures/EarthAuroras/EarthAurorasYp texZn = RSSVE/Textures/MainTextures/EarthAuroras/EarthAurorasZn texZp = RSSVE/Textures/MainTextures/EarthAuroras/EarthAurorasZp } And then you scroll up to the part where the textures are actually loaded to find stuff like this: Load(Texture): RSSVE/Textures/MainTextures/EarthAuroras_LR/EarthAurorasXn And that probably explains the whole issue already. The texture path in the config are different from the actual path. The "RSSVE/Textures/MainTextures" directory contains sub-directories for "High Resolution" (_HR) and "Low Resolution" (_LR) textures but the config expects a single directory. To solve this, choose one resolution of textures and remove the "_HR" or "_LR" extension of the directory names (you may want to remove the other directories which contain the unused textures) OR add the extension to the filepath in the configs (since there are multiple configs, this will take more time though).

Perfect, thanks Since the error happens quite early, there are not a lot of information but I guess, you installed the wrong version of kopernicus, because the version of Modular Flight Integrator (dependency shipped with kopernicus) is 1.2.6, while it should be 1.2.4. This would also perfectly explain the typeload exception. Uninstall Kopernicus AND Modular Flight Integrator, then install the latest 1.3.1 backport: https://github.com/Kopernicus/Kopernicus-Backport/releases/tag/backport-1.3.1-26

You still run Kopernicus 1.7.3-1. Try the latest version of Kopernicus (1.7.3-2), it fixes a serious FPS issue like yours.

It is the 6th question in this neat little "how-to" Of course, the answer is there as well

I almost missed it as well and was already typing my answer (which was pretty similar to yours) but coincidentally I've noticed a lot more parts which weren't able to compile, so I checked the paths^^

Perfect You installed a few mods wrong, incl. "Near Future Construction" which changes the model of the "strutCube". You have a file structure which looks like this: Kerbal Space Program GameData 1 AdjustableLandingGear 2 AviationLights 3 Mk3Expansion 4 NearFutureConstruction 5 Mk3Airliner These additional folders 1, 2, 3, 4 and 5 will break your mods. Move these mod folders to your GameData directory, so it looks like: Kerbal Space Program GameData AdjustableLandingGear AviationLights Mk3Expansion NearFutureConstruction Mk3Airliner That should fix your issue. Edit: Uff, there are actually a few more things you should fix: There is an additional "GameData" directory in your actual "GameData" directory, which contains ModuleManager. Move the ModuleManager.dll file to "Kerbal Sace Program/GameData"

Hard to say what's wrong there without a log file. You already checked manually that the part actually exists in your install, so it must be something in the loading process of KSP or one of your mods contains a buggy ModuleManager patch which renames the part or some other weird things. Since you seem to have some trouble to find the output_log, let's try the "KSP.log" which is located in your KSP directory, next to the executable "KSP_x64.exe" Please upload the log file to a filehosting service or a cloud service like dropbox, google drive, one drive, etc... and share a download link for us. Might be interesting to see the ModuleManager.ConfigCache, please upload this file as well (it's located in the GameData directory of your KSP install).

I'm not aware of any other issues, should work perfectly fine with these fixes

GPP and After Kerbin provide a dV map on it's own. The map for GPP is included in the download and also access-able on github, the map for After Kerbin is available in the OP of the release thread

CKAN is up-to-date but maybe, it's an issue with your ckan settings. Please open "Settings -> Compatible KSP versions" and check which versions are marked as compatible. I have the gut feeling, 1.4 might by marked as compatible but not 1.5 or 1.6 but you need 1.6 in order to get the latest version of scatterer.

Correct but actually the other way around in this case @tsaven You have scatterer 0.0331 installed but some of the config syntax changed during the update of scatterer to 0.05x. The latest version of SVE already uses the new syntax so you will also need the latest version of scatterer to work properly (or you can downgrade SVE but I would recommend to upgrade scatterer instead )

Ok, I'll try to explain it to you: There is a difference between the "crash log" (named "error.log") and the "output_log". The crash log is only created on a game crash and a popup window will ask you, if you want to open the directory which contains this log together with the crash.dmp. This log contains some basic information about your system like ram usage at the moment the game crashed: the crash reason: and right at the top, the unity version (that's the game engine KSP is build on) Since KSP 1.4, the version is "2017.1.3p1". The output_log on the other hand, is created every time you launch the game and it contains a lot of information about stuff which happens in the background, like details about the game loading progress, installed mods and issues which happen at runtime but don't crash the game. It also contains the unity version: and the actual game version: Since the unity version in your output_log doesn't match the unity version of your error.log, it tells me that you picked an old output_log Like I said before, this happens quite often because every KSP version up to 1.3.1 stored the output_log in the game files but unity changed this behavior and when KSP was updated to 1.4, SQUAD also updated to a newer unity version, so KSP started to save the output_log in a new location as well but the old output_log was never deleted or moved. When you uninstall the game through steam, it will only remove the files which were also installed by steam but logs, mods, savegames and some configs are created during the game launch and steam doesn't know anything about these files, so they are not affected by the uninstalling progress until they are removed manually.

This happens quite often so it became one of the first things I'll check when someone posts a log file Yep, they are and you are definitely more skilled in reviewing these dumps than me, so I stick to the logs *Sends a like in your direction which may or may not appear some day* xD

Glad to hear you already fixed your issue but just in case you are curious about some details why this happened: It looks like KSP didn't find all the mod .dlls: Just ModuleManager and Kopernicus were loaded but other mods like TweakScale or MemGraph are ignored, so I guess, the windows update somehow changed some file permissions or changed something in the behaviour, how .dll files from "unknown" sources are handled.