Jason Patterson

None. I generally don't plan trips with vessels that have burns longer than ~10 minutes (2.5 minutes with 4x physics.) The only time I'm not actively playing is when I'm waiting on a vessel to get to Eeloo or similar.

I honestly hope that the game eventually will give us an option when it believes we have completed a mission. Something like a right click menu option "Use this vessel to complete Contract XYZ." If you click it the vessel is taken from your control. If you don't, the contract isn't completed even if it's a satellite in the perfect place/condition.

I find that the probe cores are able to hold position on a navball marking (prograde/retrograde, etc) much better than they do on any random spot where I've hit T. It's nice to have one that can hold normal when you're trying to put a satellite into a particular orbit and its apses are already more or less correct. I agree with 5thHorseman that it's largely asthetics though - that's what most of the parts in the game wind up being in the long run.

My mind instantly went to the xkcd comic. They had a bad problem and did not go to space today.

It's a cute little plane; I found it quite easy to control. I don't know whether the old and new versions are truly comparable. I've tried a few times and my best attempt is 2:37, but none were over 3 minutes, so I'm suspecting that the new version is a bit peppier than the old one.

To be clear, the direction of the navball markings and the velocity marks on it are based on the reference frame for your SOI (or Target/Surface, if you have those selected), not the parts - not in any way at all. If you are flying due east with 0° inclination, then you switch the control to a new object, the navball will turn and reorient to that part, but every one of the orbital vector marks will be in the exact same place that they were previously. It's just as if you've spun the ship around to face in a new direction. It can be annoying to fly if it is significantly off, but a velocity vector that is parallel to your control orientation works just as well, though it tends to induce rotation. Sometimes you are stuck with a less than perfect option though.

Just in case you haven't experienced the fun yet, rocket exhaust can be blocked and/or destroy parts that it hits, so keep that in mind when you build your tug.

The prograde/retrograde vectors are based on the vessel's velocity, not on the thrust of its engines. As the engines apply thrust and change the velocity, the markers will move accordingly, but they will not (and should not) solely because an engine is pushing the vessel "sideways" instead of "forward." Addtionally, maneuver nodes indicate the direction of a required velocity change; they do not reference the direction of the engines' thrust at all. However, if you want to have the entire navball reorient, that is possible as well. Suppose in your drawing that you wanted to launch with the box you've marked Toys pointed forward on the ship, but at a later point, you want the crew module to be the front (as far as the navball is concerned, that is.) If you put a controllable part at each of those positions (a command module or probe core - a docking port might work here as well, I can't recall) then you can right click on the part whose orientation you want the navball to reference and choose "Control From Here." The navball will reorient so that the object you chose is in control. You can change back at any time with a right click. You would launch with the Toys in control, and when you wanted to switch engines, switch control to the Crew module, rotate the vessel, and make your burn.

Like most of the more involved things in this game, it takes a lot of practice. You can use drogue chutes (that you cut) to get yourself slowed significantly as well. Otherwise it boils down to making a good approach so that you're aerobraking as best you can and at the end of that aerobrake, you wind up in a good spot to land.

It's not exactly the right sentiment for me, but I chose #1. I actually get mad when a mission fails so badly that a kerbal dies. That said, I won't quicksave/reload to save one unless it dies in one of those mysterious POOF events that happen from time to time. You know, EVA --> Gently land --> 2 Steps --> POOF! DEAD! I definitely never leave kerbals abandoned off of Kerbin. If it's not a permanent outpost I've built, everybody makes it home every time.

In my opinion, mods should be for altering the behavior of a game in new ways, not for fixing problems. Also, as per my update on the OP, this appears to affect exploration missions as well.

The Bug: If you build a vessel with a mobile processing lab, launch it, and use the Process in Lab Module button, the science window's right edge is misaligned with the buttons. I don't know if the buttons moved or if the window resized or what. I used a Science Jr. here but it also works with ooze and presumably the thermometer/accelerometer/etc.

As others have said, this depends heavily on your intent and the location, but I have to think that for most situations shedding mass will be superior. That may not mean full stages, perhaps only drop tanks... In lots of cases this is probably going to be a marginal savings in either direction - there are a bunch of bodies that are trivial in terms of delta-v to land and return to orbit.

The image quality is pretty poor, but this is my biggest vessel ever. A ship to land on and return from the surface of Eve in a single launch using only 0.18.3 demo parts. I can't recall the tonnage, but the part number was right at the limit of breaking the game. If I added more, the game simply wouldn't include them when it launched the vessel. It took roughly an hour to reach orbit due to lag.

Just to be clear, did you see all 4 parts land safely? It's possible that two exploded on impact as well. I think that amagheddonsgw is probably right though.

It really doesn't matter what the surface gravity on Kerbin is, the formula has absolutely nothing to do with that. If KSP's Isp calculation really does use 9.82 instead of 9.81, it's just wrong. Think of it this way, if we built this rocket on the surface of the Mun, would it's delta-v be any different? No, even though the surface gravity there is much lower. The delta-v calculation and the actual surface gravity of the planet are completely independent of one another - as was mentioned earlier, g is used as a conversion factor, and they apparently used the wrong value for some reason.

It can also be the result of a contract to rescue a specific kerbal. If you look through your contract_finished sections for kerbals who were in your game but no longer are, there might be one.

If you are trying to fly a low altitude suborbital flight (without jet engines) then you're setting yourself up for failure. You want to go high, avoiding most of the atmosphere, just as you would to get into orbit. You should be able to do the usual ~10km vertical climb, then turn to the north and aim for your target. I'm surprised that Mechjeb can't hit those targets... What is it doing instead? Honestly though, the most efficient way to get around Kerbin is by high altitude jet. The flights take a while, but you can build some amazingly long distance fliers and return all (or nearly all, if you use drop tanks) of the vehicle to base for a full refund.

Your delta-v calculation is the maximum change in velocity that your ship can generate from its fuel. While you're flying upward, gravity drag reduces the effect of your ship's engines (that's why we do gravity turns on launch, to reduce the component of gravity against which we are burning.) While you're in an atmosphere, atmospheric drag does the same, regardless of your direction of travel. If you find the integral of the acceleration from aerodynamic drag with respect to time and the integral of the component of the acceleration from gravity that you are opposing with respect to time, those should make up the difference between the calculated delta-v of the rocket and your actual change in velocity. Unfortunately those calculations can really only be done with a flight path simulation. As was said previously, if you took this vessel out into space and fired the rocket prograde or retrograde to a circular orbit, you should find that the delta-v value that you calculated very nearly matches the actual change in velocity.

First one is the hardest. It's all downhill from there.

Making good progress with my hard career mode save. EVAed on Minmus, when my kerbal hit the ground the neighboring vessel exploded, crashing the game, killing my pilot, and sending pieces on solar escape trajectories. Frustrating hour or so of persistence file editing required to recover to a functional file. Really wish that this would get sorted out; it's been happening since I started playing.

In general the conditions of a contract must all be met simultaneously. Even if they're stupid (and most of the "Test X while splashed down." ones are...) that's what is required to complete the contract. There are exceptions, but these are laid out in the contracts window in a more obvious fashion. An example would be the Explore the Mun contract, where it is stipulated that you need to land on the Mun, collect science, and a couple of other things. These missions are listed with major subcategories, each of which offers its own rewards.

In the case of the KSC becoming unresponsive, this can be fixed in a couple of different ways that are referred to in the thread that VirtualCLD linked. It's not going to solve everyone's problem, but it seems to be the result of firing a Kerbal who is referred to elsewhere in the persistence file. Once they are no longer around, the game gets confused when it tries to find them.

It's a small thing, but it seems like it should be straightforward to change. The Change: Rather than having each of the altitude challenges that are given at the beginning of career mode as separate contracts, switch them to a single contract with goals and rewards for each altitude. The Why: Suppose you get the contract to fly to 5km and you get to 6km. The game pays you and you are then offered a contract for 11km. If instead you get to 12km on your first flight, the 11km contract is never offered; it skips directly to the 22km contract. If you make the mistake of going for orbit straightaway, you lose -all- of the altitude contracts and the money, reputation, and science that is associated with them. It makes a significant difference early in hard career mode, and it forces players to fly repeated, boring missions in order to max out the money from these contracts. Further, players who are unaware of the system don't even get the choice. A single contract with multiple parameters should solve this nicely. Update: It appears that the planet/moon exploration missions function in this way as well. I've gotten contracts to explore all of the Jool system except Vall, which happens to be the one moon I orbited prior to accepting its contract. I got Jool, Bop, and Pol, then Laythe and Tylo, but never Vall. It's possible that it's coming, but it seems unlikely.

I have the same issue. Jeb died fairly early in the game with no issues. Somewhat later I fired someone I had rescued from orbit who never flew a mission, still no issues (for several more hours of play.) Just recently, I completed a contract to place a satellite in a (more or less) retrograde orbit around Kerbin and accepted another to create a polar orbit and collect science data from space. Originally couldn't right click the VAB, but on reloading the save right clicking worked, though now I can't left click the VAB. SPH still works, as well as the other buildings, however, the KSC scene won't reload when I try to exit. It also won't allow me to quit using menu buttons, have to Alt-F4. New saves work properly. Here is my persistence file, if that is helpful. Update: I found the issue in contracts. If you rescue someone from orbit then fire them, they will return to the hirable Kerbal list, so there is no problem in the short term. However, eventually they are replaced by another Kerbal and disappear from the game. Once they are gone, the game throws an exception when it refers back to the contract you completed when you rescued them from space. Rename an existing Kerbal with their name to fix the problem or delete their rescue contract. Not a long term solution, but doable. The real problem comes when you've got more rescues than Kerbals. Guess you could add them as dead Kerbals instead of living. In my savegame it's Wilry Kerman who caused the issue.