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.

Hmm, I still get:

Still no file uploading, but at least it's progress!

Try wiping out your cookies for wiki.kerbalspaceprogram.com. That will log you out which should get the Wiki to load again. However, if you're like me, you will then not be able to log back in, which is unfortunate because I had some tips and new images I wanted to add this week.

Perhaps I came out of the gate swinging a bit hard on that one. Maneuver nodes are not available at game start in Career Mode; you need to do some work and upgrade first to earn them, which makes sense because the Kerbals need to learn how to do it. If we want to take orbital plots away in the very beginning of the game and turn it into a lower level upgrade, I wouldn't have a problem with that because again, it makes sense to the game flow. I usually do calculate my own burns because the in-game calculator is inaccurate in many cases, such as when you have a powerful rocket but a tiny maneuver, or you plot the maneuver before staging, and you'll need to do it yourself anyway if you want an accurate burn that crosses a stage, or if you plot your maneuver and then exit the game or just go back to KSC and return later. I can see a delta-v calculator being an upgrade-enabled feature, but I really hope it would be toggleable because it removes an entire segment of the gameplay. At its heart, KSP is a rocket science game; the first challenge in executing missions is designing a rocket that meets the mission profile, which involves meeting a delta-v budget. The delta-v budget of the rocket is a function of the rocket's design so if you're just going to slap a number on the screen, designing a rocket can degrade into a hunt-and-peck in the parts list rather than a design effort. Even with the maneuver node tool, you need to know how orbital basics to use maneuvers to effect the trajectories you want. That said, I admit that I am fairly draconian when it comes to game mechanics. I design my rockets with spreadsheets and calculators and actually fly test missions to see what works. I play the game because I am a gigantic nerd and I /enjoy/ doing the math to calculate these things and love the feeling of accomplishment when a mission plays out exactly as it should because I can look back at my own paper trail and see how I got there from here. I know that not everyone plays like this so I can definitely see the appeal of such a thing, but it would hurt my personal experience. I figure, if everyone else can talk about the things they want to see to make the game more exciting for them, why can't I talk about the things that would make the game less exciting for me.

Only if it's only available on easy mode or togglable in options. Otherwise you might as well just have a "build my rocket" button.

I think backspace still works to reset focus if you are in map view. I have seen the map view get buggered up, particularly when working with maneuver nodes, to where it will stop responding to input. Did you try going out of map view, back into map view, and then hitting backspace again?

I like the way you think. I don't use docking mode. RCS on, two handed: left hand rotates, right hand translates. It can get hairy, but space is a dangerous place, folks. (Actually I avoid docking mode because one time I hit the spacebar to toggle between angular and linear mode and for some reason the game thought I was in staging mode so it jettisoned my service module and left me with a command pod drifting right past its target and into a permanent orbit.)

I have noticed that putting the HG-5 on a craft makes the tracking station refer to it as a "relay" rather than a "probe." My guess would be that the contract fulfillment is looking for a craft that it identifies as a specific type of craft.

Nothing occurs in the event log when the launchpad explodes, so there are no clues there.

I appreciate the reply and the comments. I am glad I did it right. I like your idea, and it seems probable. I will try again later and try to keep the camera focused on the launchpad to see if the explosions originate at the debris. One thing that I"m not sure about is that if I change it to an interstage fairing (I did this by adding a structural fuselage above the probe core, nosing it with just the parachute, and then wrapping the fairing around the core in the middle) the problem does not occur, even though the fairing pieces fell on the launchpad again. I'll also check that event log--I did not not know how to view it outside of the catastrophic failure debriefing screen. However, in this instance, the launchpad itself is destroyed (You can make out the flaming wreckage at about :23 in the video if you're viewing it at a high enough resolution). I think my big question is: Should fairing debris on the launchpad, even if overheated, cause the launchpad to self destruct? That seems so incorrect and expensive for career games given the tiny size of the rocket involved.