RexKramer

If you launch a vessel, it will be minimally crewed wether you have Kerbals or not. So, you could launch multiple vessels, then not recover them until you have the required crew.

I think some more information would be helpful to answer your question. 1. How high are you? 2. How many jet engines? 3. A picture of your plane would be helpful. Lacking the required information, I'm assuming you are using a spaceplane with at least two jet engines. So, you are probably flaming one engine out, which causes the plane to yaw right or left, depending on which engine flamed out first. There is not really a good fix to eliminate asymmetrical flameout (in stock KSP at least). One solution is to cut your jet engines prior to flameout, and switch to rocket engines. You can delay the flameout by reducing thrust at altitude, but eventually you are going to run out of atmospheric oxygen. You might also want to reconsider your flight profile. Pitching up at the top of your climb is not really an effective way to reach orbit. A different approach would be to accelerate horizontally, getting as fast as you can at the highest altitude which does not cause flameout. I typically achieve 2400m/s orbital velocity at 41,000m. At that point, I shut off the jets, and activate the rocket(s). At that point, a small amount of rocket thrust will push the AP above 72,000m (if it isn't already). There is no need to 'pitch up', just continue burning prograde. At AP, another short burn from the rocket(s) will circularize the orbit. Also, not sure how KSP handles this, but jet engines typically only work well with the air flowing straight into the intake. 'Pitching up' is going to reduce airflow into the intakes, making your flameout possibly occur at a lower altitude. To see this effect clearly, fly level at about 10,000m altitude. Pitch your aircraft up (or down) so it is pointing away from the prograde marker. Watch your intake air as you do this- you should see the intake air indicator drop off significantly as you point the nose away from prograde. Rockets don't really care which direction they are pointed, but jet engines do.

Yup, really nice to be able to remap the zoom keys, especially on computers (Like my MBP) which don't have a NUMPAD.

Chik, glad you had success. It was a little odd that I was able to decouple when clicking on one side, but not the other. Keep in mind the game is still in development. You can find solutions to most of the current quirks on this forum.

First, try clicking on the other docking collar. I was able to decouple, but only one of the docking collars gave me that option. If you could provide a little more information, it may help as well. Specifically, 1. Which tutorial? There are Training missions and Scenario missions. I'm assuming you are going through the Training mission To The Mun part 1? 2. Which game version are you using? Again, I'm assuming the latest version of 0.25. 3. What operating system do you use? (Windows 7, Linux, OSX..) 4. Are you using any Mods, if so a list of mods you are using is always useful. Thanks for reporting this! Again, try clicking on the other docking port. If that doesn't solve it, please report back with some more info.

Well, I normally shoot for about 120km when approaching directly from Kerbin. My most recent approach from Kerbin, I was shooting for Laythe. I had a target of about 117km, ended up with 116.87km PE and went with that. Worked out pretty good, my AP ended up being halfway between Laythe and Vall's orbits. If your orbit more closely matches Jool's when you hit Jool's SOI, you'll need a higher aerobraking PE.

I've used a two LV-N lander on Tylo with success. It was a fairly heavy lander. I'd imagine a single LV-N lander is possible if you keep it light. The problem with a single LV-N is keeping the center of mass low, because those engines are long.

What I would add to the previously stated is I rarely put landing legs on landers. Almost never, actually. Generally, if you get your velocity to less than 5 m/s, you won't damage engines or whatever is on the bottom. The impact tolerance of parts is listed in the VAB menu. Otherwise, the above suggestions all work well. Build wide and low landers. Radial mounted tanks help keep your center of mass low. Having adequate SAS helps also- usually the command module's SAS is sufficient, but for heavier landers adding SAS modules doesn't hurt. For really bumpy terrain which has caused you problems in the past: Don't plan a steep final descent which leaves you with few options to change your landing site. Instead, plan enough fuel to skim the surface maybe 1000m up, at a modest horizontal speed. When you find a flat(ish) landing spot, stop your horizontal motion and drift down. This takes more fuel than a suicide-burn drop, but leaves you more options.

Ok, I just took another look at this. Clicking on a stage icon over the exit button clicks 'through' to the exit button. However, by clicking and dragging, you can still drag a stage icon which is positioned over the exit button, without exiting the VAB. Are you saying that mousing over the exit button is causing the exit, or that single-clicking over the icon is causing the exit? Again, click and drag should work now (in 0.25). Also, thanks for bringing this up, I had forgotten there is still some oddness when staging overlaps the top of the screen.

I thought this issue had been resolved, but evidently not completely. Could you please indicate which game version and OS you are using?

Lift to drag ratio is dependent on airspeed. A simple way to estimate this ratio is go flying. Reduce thrust to zero, and maintain a constant speed. Horizontal distance traveled divided by vertical altitude lost is your lift to drag ratio for the airspeed you maintained. A complication to this method of finding L/D is the fact that in KSP infiniglide is going to skew your results.

This is a known issue. As far as I know, there is no fix for it at this time. I suggest quick saving before bringing a space plane home.

Any other electric loads? Was SAS on?

This is a known issue. It is difficult to reproduce this reliably, seems to happen randomly. It certainly provides some excitement when a wing suddenly blows up! While your screenshot indicates the wing thought it collided with the VAB, other buildings have been indicated as well, including the runway.

I consider the NavBall additions one of the most useful things added to KSP, ever. Without prograde/retrograde markers, it would be very difficult to accurately find those vectors, even in an equatorial orbit, except when you are exactly at AP/PE. Not having to fumble around guessing at normal or radial vectors is extremely useful. Personally, I don't find them intrusive at all, even when I'm not using them.

There appear to be a few issues with command pods, the MK1 in particular, in 0.25. One issue is that most items attached to the top of the MK1 pod can cause and EVAd Kerbal to be ejected away from the capsule. Some of the items which I've found cause this behavior when mounted on top of the MK1 include: Z-200 Battery, Oscar B fuel tank, MK16 parachute, OKTO2 probe core, PB-X150 Xenon tank, and the Small Inline Reaction Wheel. Here's a workaround you may want to try: Mounting a Cubic Octagonal Strut to the top of the MK1 does not cause the Kerbal to be ejected. You can then mount stuff on top of the Cubic Octagonal Strut, again not causing Kerbals to be ejected. Unfortunately, the Cubic Octagonal Strut does not appear until you are fairly deep into the Tech Tree.. Otherwise, you could also try not mounting anything to the top of the MK1. Kerbals now appear to be slowly sliding off hatch ladders, including the MK1 hatch ladder. So even if you eliminate the problem of being ejected, you still will need to pay attention to make sure the EVAd Kerbal doesn't slide off the hatch ladder. These are known issues, and appear to be new to 0.25.

Well, I wasn't able to duplicate the issue. However, I'm also thinking along the lines of camera mode. I was going to ask which camera mode you were in (Free, Chase...). I think there's a good chance the camera changed modes, as you suggested maybe because you were at an altitude border and the mode automatically changed. That can be frustrating sometimes. I did try different camera modes, and I experienced some camera strangeness while transitioning to Auto mode, and also while in Auto mode. Things happened pretty fast, so I'm not sure exactly what order things happened. At one point I was hitting the spacebar to orient the Kerbal while the camera was swinging around, causing some unwanted motion. Another time, the camera shifted as I was making some inputs, again causing some unwanted motion. I don't think I got the same effect or severity you got however. In short, I'm also thinking a camera mode transition is the culprit. It sounds like you saw this effect several times as you made several (probably frantic) attempts to push the capsule into orbit. I was testing this above Kerbin, not Mun, so it's possible I'm not seeing the same effect because of my location- I'll try Mun later. As a side note, I've actually had better luck just abandoning the ship and getting the Kerbal to EVA his way into a stable orbit- letting the ship crash and coming back later to pick up the floating Kerbal. Sadly, you lose the Science you had in the capsule, so I certainly understand the reasoning behind trying to push it into orbit.

You may want to check to make sure they haven't been deactivated. You can do this by right-clicking on the installed part in the SPH, which should bring up a pop-up window that allows you to select/deselect Pitch, Roll, and Yaw axes. Make sure the appropriate axes are active (Pitch for elevators...). They should default to all axes enabled on initial installation, but worth checking anyway. Dead battery? That's unlikely, as you stated you were able to activate the engines. Maybe double check to make sure the control keys are mapped the way you think they are. Also, not sure if caps-lock would affect control key inputs, but worth checking. Do rockets still respond to control inputs properly? Also curious if nose wheel steering works. I think nose wheel steering is disabled by default, so you may need to enable nose wheel steering by right-clicking to bring up the options. See if the nose wheel is turning. If it is, the problem is limited to the control surfaces. If the nose wheel also does not move, that might indicate the control inputs are not functioning correctly. That's all I can think of at the moment..

Which capsule were you using? Actually, a description of all the parts of the capsule, or better yet a screenshot of it, would be helpful. Also, how close were you to the capsule when the spinning started? There are a couple of known issues with EVAs on certain capsules, specifically the MK1 (starter capsule..). One issue is a tendency for Kerbals to slide off the ladder on EVA. The other issue is Kerbals being rapidly ejected away from the capsule when you EVA. The rapid ejection seems to only occur with certain part combinations. I've seen it with a Z200 inline Battery on top of a MK1 pod, but it may exist with other part combinations as well. Again, if you can provide more information that would be interesting.

Yes, not a bug. Replace them with the advanced inline stabilizer.

Confirmed 0.25 on OSX, stock. I'll generate a report. FYI, some of the other command capsules also have a tendency to cause Kerbals to slide off. I haven't seen a Kerbal shoot away rapidly yet, that's usually caused by an object near the hatch.

This behavior is not new to 0.25- it was present in 0.24 as well. Not sure what the mechanic is, might be the girder attached to a decoupler. Try the same setup with a fuel tank attached to the decoupler, instead of the girder. No crossflow. Weird. Paging Kashua.

I think the above posters have probably covered what is going on. However, there's another possibility, although it may not apply to you: If you have a probe core (or manned core) mounted upside down by accident, then your ship will be thrusting in the opposite direction. When the core is pointed prograde, the engines will be pushing retrograde. I've had this happen to me in a couple of different situations. 1. I accidentally mounted a probe core upside down. The cores can be tricky to determine which way should be facing up. To avoid this, I try to limit how much I rotate cores when placing them. 2. I've docked two ships together prior to a burn, and selected the incorrect side of the ship to control from. (Or just forgot to even check which core was controlling the ship. In this case, again the core was facing the opposite direction of the engines in use. So again, while the core in use was pointed prograde, the engines in use were pointing retrograde. I mention this because it's very surprising that a prograde burn would cause you dip low enough into the atmosphere to crash, if you start from a stable orbit.

Yup, works this way for me also- if I don't power up with the brakes engaged, they release fine.

If you are using OSX, there is a known issue (Bug #2804) which makes it difficult to keep AP/PE data up. The above suggestion by AlexinTokyo is one of the workarounds. As far as I know, this issue is limited to OSX installs.