pincushionman

In space (more specifically, when there are no outside forces acting on the craft OR the craft is in the “landed” state), timewarp puts the craft “on rails” and it is allowed to travel along its orbital path without having to deal with pesky physics calculations. In the atmosphere, however, you always have forces aerodynamics and engines) acting on the craft, so standard timewarp is disallowed. Instead, you have what we often call “physics time warp,” which is accomplished by increasing the time step of the physics calculations. Not only does this decrease the fidelity of the trajectory, it also causes the parts to deform more under load (because the forces act for a longer time before the forces and stiffnesses are re-evaluated). So the state of the aircraft can quickly move beyond the limits of normal deformation before the simulation can stabilize, especially at high speeds or loads. This can, as you have seen, be quite dangerous to your aircraft. It used to be there was a warning on-screen the first time you engaged physics warp in a game; don’t know if it’s still there or not. By the way, you can engage physics warp at any time by using the Alt key with your warp up/down keys. It’s limited to 4x. EDIT: Ninja’d!

Not if @The_Cat_In_Space lives east of Paris!

There’s also the color of the staging icon, which can be useful in determining the appropriate speed. If it’s green, it’s probably safe. Yellow, maybe. Red, it will always break. This, of course, assumes you have enough parachute for your capsule. I don’t think it accounts for that. So it’s not very useful for planning.

Is the throttle setting (to the left of the navball) changing, or is just the ammount of thrust changing?

This would be very useful if we had coughrecurringmunthlycostscough

For clarification, the game only simulates objects that are the active vessel or within ~2 km of it. Everything else is "on rails," meaning it only moves along Keplerian conic orbits, just as if you engage standard time warp. This reduces processor load. However, it also means only gravitational accelerations apply to these other objects. No engine thrust is obvious, but also no aerodynamics are applied either. This isn't a problem with airless bodies; the vessel continues on rails forever unless it impacts the surface. Atmospheres, however, are a problem, because drag and lift are significant forces and have to be actively simulated. So the devs decided that an atmosphere pressure less than 1% Kerbin sea level pressure could be ignored under certain conditions. But anything leaving the simulation "bubble" in an atmosphere greater than that (or entering such an atmosphere) is assumed to experience "significant aerodynamic forces," and burn up, or lose control and crash. The game simply deletes the object to save processor effort. On Kerbin 1% atmosphere is anything below 23 km. By exiting the flight scene before landing, you're telling the game that you don't care what happens to that vessel, and it can safely assume it will be destroyed. Mods such as StageRecovery can override this behavior, so if you want to recover the vessel you need to either install such a mod or ride it all the way down.

Players now: "My plane veers to the left when I take off, and I crash!" Players if we have this: "My plane doesn't veer to the left enough when I take off, and I crash!

And yet it is far simpler than what happens IRL.

In the same context, "troll" also has a completely different meaning on the forum than it does back home. Ain't jargon fun?

Alternatively you can re-assign the "drive forward/reverse" and/or the "wheels turn" controls to some other control in settings. This helps in airplanes too by separating turn from yaw.

Very dangerous. The only advantage of the concept (that of being able to always take off/touch down directly into the wind) is completely wasted because the runway is only close enough to "into the wind" at two points at at time. The plane would have to turn during its takeoff and landing rolls, and planes are bad bad bad at turning at speed, due mainly to that whole "v" part of momentum. There's also a great risk of creating congestion on the runway itself due to the fact that in this sort of design, there can only one runway of a certain size, whereas major airports can often have two or three parallel runways with their current designs, if they need it for their flight volume. Furthermore, there's this thing called "prevailing wind". In most parts of the world, one can generally assume that the wind will come from a certain set of directions, and thus align your runways to take advantage of that. This is especially important at smaller airports, who can't afford to have more than one runway. Even the circular runway would use far more pavement than just picking a direction and building a straight runway. And even if the wind is off-direction, at least the runway is straight enough the pilot can effectively crab or sideslip down. These are well-understood, well-practiced maneuvers. If you look at a picture of my local airport, you'll notice the runway is aligned to take advantage of a wind blowing from the south-southwest. If you pan to the east, you can easily find three more airports/airfields aligned in nearly the same direction. I can quickly find an additional two pointed north-south in town (but that's of course because I live here and know where they are), and was able to just find several more just by grabbing the map and looking. I scrolled until I got to Topeka before I found an airport with a significant direction difference. This is no coincidence. Airport developers are well aware of the local wind conditions, and don't need to resort to esoteric solutions to get reliable landings. In short, not only is this a dangerous solution, it's also a solution in search of a problem. Learn your local wind directions and deal with it.

It's that time of year again! The Tour has begun anew and the need is as strong as ever! I've updated the OP with the information for this year's campaign.

but how do we get into BBCode mode?

I'm kind of over this emotional insistence that Pluto is a planet. It went from being the last and least among planets and became the first and greatest in a whole new important class of objects. Just like what happened to Ceres.

Add recurring costs, and the problem that the high hire cost was intended to address goes away. Same with the outlandish upgrade/rebuild costs. To be honest, recurring costs would fix a great many things with Career mode.

Short answer: Excel. Long answer: It's not ready yet. Consider this your official teaser screenshot for something called KOMET, and visualising this kind of thing is exactly why I'm writing it. Yes, it is. If that picture were zoomed out to show Duna's SOI, Ike's orbit would be smaller than the circle there that shows Duna's surface. Yet the SOI is still so significant it would not be auto-hidden at that zoom level. So yes, Duna's SOI is mostly clear of Ike…except the part that's useful to us.

Ike is a jealous lover, is what he is.

The problem is not in the flap parts, it's in the aerodynamic system. In real life, aerodynamic behavior is governed by the shape of the airfoil, while in KSP its the sum if the behaviors of individual wing parts. So in KSP, deploying flaps increases lift and drag at the location of that flap - but in real life deployment of flaps instead alters the characteristics of the airfoil as a whole, which has effects along the entire chord. This is even more pronounced if instead of flaps you try to do slats (which deploy down on the leading edge). In reality these can be tremendously effective on large wings, but in KSP I challenge you to make slats that look like they deploy in the correct direction without decreasing lift. As noted, in FAR it works better, but the best solution would be some kind of procedural wing that can recognize changes in wing geometry, rather than just a bunch of parts.

There is wheel throttle in settings, you just need an axis for it. But I get ya, keybinds for +/- speed on wheels would go a long way. There isn't something hidden in settings.cfg, is there?

I should have clarified - I meant planets, dwarf planets, and large moons. On the other hand, it's well-established that SSSBs are unstable over the long term, and the really small stuff (as in doomsday-size) isn't even stable in the short term. Partially because of the chaos effects, but also because other forces like solar wind, drag, and the Yarkovsky effect become non-negligible on those scales

The solar system orbits aren't "stable," they're "stable enough."

Probably possible. Brown dwarfs spring to mind. Do those count as "dead" for your purposes?

Yeah, there's a mini-joystick under the index finger on the throttle that would work well for that. Think I've seen that one before - but what I meant to ask was less "how, technically, do I do it" and more "which axes should I assign to what in KSP?"

One...Two...Three... ...four...fivesixseveneightnineteneleven...twelve! TWELVE ANALOG AXES! AH! AH! AH! Um...I'm kinda excited about this. But in all seriousness, any suggestions? I'm thinking of binding the toe brakes together in TARGET for a wheels-drive-forward/backward axis, and wheel steer with the throttle paddles. But beyond that I'm at a bit of a loss, except for the obvious pitch/roll/yaw/throttle stuff.

Does momoprop consumption even obey flow priority? Or does it just draw from all tanks, period? If it's the latter, and your lander tank is smaller than your xfer stage's, it will deplete first because it pulls MP from both tanks at the same rate.