Omaha

The game tries to be fun but it has always been rather realistic. If you want to do anything of consequence, i.e. interplanetary travel--whether you do it by sitting down and doing math or using mods or whatever--you need to come up with a delta-V budget and build a vehicle that provides it. Then you need to execute that mission using simulated rocket engine burns at the right spot. You need to plan transfer orbits and plan for launch windows. You can't ludicrous your way through space. But then when you get there, it's OK to have super bouncy clown landing legs because it's a silly game? Eh... you can't have it both ways. I agree that the landing legs bounce too much. The purpose of the legs is the absorb the impact and slow the vehicle down so that the equipment and crew aren't subjected to rapid deceleration. Normally the legs would then stay mostly compressed. The problem is KSP's legs then push back with a tremendous amount of force and expand again, producing a bounce on the vehicle. I think Mike is right--it makes it feel like the spacecraft has no mass.

I have also noticed that hiccups (maybe a second or so freeze) occur when creating a maneuver node, or adjusting one such that it crosses an SOI boundary. It makes planning maneuvers arduous, particularly trying to dial in an encounter.

I can confirm you can use the Blender plugin to import entire vessels and then export as STL which should be supported by any major 3D Slicer or printing service. I've printed up instances of my Munar lander, and the command module for my Munar/Minmal missions. I'd like to print up some more once I dial in a few more settings. The problem is once you get the craft into into Blender you need to do cleanup to make sure you only print what you want (i.e. no paracute canopies and solar panels are too thin to print) and working with Blender is absolutely awful. It can also be challenging to orient the vessel on the printing surface such that it will print well.

I've tried this but the ship is still thrown violently into the air at load. Luckily the gravity on Gilly is so low that there is plenty of time to stop the spinning and correct the attitude, but for a station I could see it being just as fatal as a spontaneous detonation. I think my only solution is to do this to safely reactivate the ships and then put them back into orbit before exiting.

Here's a video of my experience. I've edited out the loading screens, making it appear extremely snappy. For some reason the ship seems to be floating when it loads. That doesn't always happen, but the destruction is consistent. Last night I tried landing the second ship nearby. I actually managed to land 200m down range from this ship. It looked fine from that viewpoint. But as soon as I switch to it (via [ or ]) it self destructs. Also, if I go back to KSC and then try to switch back to either landed ship, it explodes. I believe the only way I'm getting these ships home is via the debug menu and disabling collisions. The lesson learned: Gilly is fun to visit, but don't spend the night.

@Cpt Kerbalkrunch I did think of trying that, seeing if I could land the second vessel nearby and then directly switch over to the first one, and it certainly would be a good exercise in precision landing.

I ran into this problem just last night with a much smaller ship and a much smaller body. I sent a prototype lander to Gilly prior to sending manned missions there, and touched down without issue on the side of a hill. (It's hilly on Gilly.) I had a second prototype in orbit too, and I wanted to bring it down prior to attempting to return to Kerbin with both of them. But while I was getting ready to do that, I realized it was getting late so I decided to switch back to the landed one and re-launch prior to quitting for the evening. But as soon as I switched to the landed ship, no sooner did it load up than it exploded gloriously. I instinctively did a quick alt-F4 to save the ship (ironically by preventing it from being saved) and went back into the game. No luck--as soon as I switch to the ship sitting on the surface of Gilly, it violently destroys itself. It's frustrating; I'll try the debug window workaround since that seems to be an endorsed solution, and this is clearly a malfunction of the game.

I have thought about replacing the Duna leg with a quick dip in solar orbit.

How do you train new crew members? How do you build their experience levels prior to sending them on real missions? I start by sending all of them on tours to the surfaces of Mun and Minmus, which gets them to Level 2. After that, they're put in the queue for Duna, and by the time they get back they are at Level 3, ready for anything. Unfortunately, there is currently a serious backlog for the Duna flights.

After years of looking outward and sending manned missions to Duna, we finally decided to see what was on the big purple rock circling the sun beneath us. We had launched a lander probe toward Eve many months ago, and it arrived yesterday. After an interesting aerobraking process, the probe touched down safely on a small island in the northern hemisphere. Very shortly after landing, it was treated to an Eve sunrise, captured here: Once the oohs and aahs subsided, we began transmitting the data that the probe had gathered during its descent. As its original Eve orbit was almost exactly polar, it had a chance to pass over multiple areas of the planet and take many measurements on the way in, including its surface measurements after touchdown. I think the net haul was about 1000 science points, though that is kind of meaningless since all research has been completed in this game. Based on what we learned about landing on Eve as part of this mission, plans are in way to send another spacecraft carrying three updated probes and pepper the planet with additional robotic landers.

Wow, I suddenly feel insignificant. Once I start getting over a pad mass of 400t, I start to think I'm approaching the design wrong. It's one of the reasons my Eve program is stalled. It looks like my most massive, current, active design is about 433t; the payload is an LKO tanker.

I do this but I'll go to the Tracking Station view where you can easily skip a day ahead or set speed to maximum without limitation. Then I just eyeball the "T-" displays on the craft roster until the one I want is within a few hours. If a ship is on a course that allows major warping (like an interplanetary transfer) I'll usually just climb aboard and jump to maneuver. Unless of course that next maneuver is significantly longer than a minute burn! This is my mindset. If I can be productive during the time it takes my guys to get from one planet to the next, I'll prefer to do that. Close out some contracts, test a few prototypes, rescue some new recruits and bring them up to snuff with trips to the moons, etc.

I try to do this, but sometimes it's not feasible. Even the two Duna missions: one is a manned landing with three astronauts and one is a permanent robotic lander. The manned launch uses my tried, tested, dependable Duna vehicle while the lander is using a one-off upper stage attached to one of my most common launch vehicles. Putting them together would have meant designing an entirely new rocket instead of just launching the Kerbal-capable Duna ship and matching the mass of the robotic upper stage to a compatible launch vehicle. Doing multiple things at once is often part of the fun for me. Some single threaded missions can be a bit dull just waiting for transfer windows or rendezvous. Having a few game weeks of jumping between multiple craft can break the monotony up. I honestly almost burned myself out on the game during my Duna test runs earlier this year because it got so repetitive, but once I locked in the design and the mission profile, I now look forward to each Duna mission because it's still an exciting little trip. Sometimes the challenge for me is remembering burn times since the maneuver tool has a habit of forgetting them when you leave a craft and return to it. I can recalculate them but that's wasted time; I'll often just update the craft name with something like "SHIP NAME (46s)" so I can remind myself when I get back what the next burn is; another feature I've always wanted is a "ship's log" or some way to take notes on a particular ship. There's pen and paper, yes, but it would be easier (hopefully) if there was an in-game mechanism for just jotting stuff down. This was a total ramble. KSP good. Variety good.

I'll do that sometimes, but in this case since the Duna and Eve departure windows were so close together, it was inevitable. I will probably do the same now that it's going to be months before those three ships will be ready to brake into orbit of their destinations. Although I do have a few other things I can accomplish in the meantime... I wish stock had a "jump to time" function or a tracking-station level "warp to next maneuver taking all flights into account" or a way to push a maneuver node further into the future than one orbit. It can take a lot of clicks to schedule a node for next week when each orbit is only an hour long.

What is the greatest number of concurrent missions you've juggled, and what do you average? Not just how many flights do you have active, but missions that require active participation at the same time, with maneuvers to tend to, landings to manage, etc? Last night I had two ships departing for Duna, with their departure burns within 10 minutes of one another, while a training mission to Minmus was on its way home and needed my attention to manage aerobraking. By the time that ship had completed a few laps to decelerate enough to land, the departure window for a vessel going to Eve had come up and I needed to quickly go over there and complete that maneuver. Then it was right back to the returning Minmus ship to bring it home. As an added bonus, I then noticed that one of the Duna ships had somehow lost its encounter so I had to jump back there and do a quick (and annoying) boost to line it back up to intercept the red planet. It had been a while since I had to jump between missions that actively.