Hypocee

Wow, nice timing.

Ooh, very nice. Just because you\'ve reminded me and I\'m surprised it\'s not here already, some time ago user Napster made one based on the pod in front of Kerbin. Decisions decisions.

Well. From the books that are the same as that sitcom

Welcome! I hope you guys have fun working on the game.

http://kerbalspaceprogram.com/forum/index.php?board=9.0 http://kerbalspaceprogram.com/forum/index.php?board=8.0

Theoretically I think it may also be necessary to know that the planet\'s radius is 600km, to translate into point-source measurements. In general form the velocity at any point can be converted to angular momentum at any point in the orbit, which is conserved, and tells you the central mass. Given the mass and the semimajor axis and...crazy math term that the periapsis is...you can calculate the semiminor axis and get your eccentricity. In terms of me actually knowing the steps? NOPE Edit: One Wikicheat later, you can do it from just periapsis and apoapsis. Huh! That does require the radius info to translate from altitudes to...distances.

As well you shouldn\'t have to, of course. In general I\'m not aware of any good methods for getting around these annoyances. All that can be said is that HarvesteR is aware of the upper-stage problem and symmetry breakdowns and has been slowly hammering out some breakages with each update.

Make the burn at the right point in your parking orbit; this general situation is what astronavigators mean when they talk about a 'window'. The Orbit Mechanic or guides can give you precise figures, but I haven\'t yet been let down by the rule of thumb that a Hohmann orbit to the Mün should lead it by about 30 degrees. There\'s no value in widening your transfer orbit, unless you\'re orbiting opposite the Mün\'s revolution to make damned sure you hit it first try. Yes, some people have taken that approach

Not directly, and not precisely - there\'s quite a lot of both science and art in predicting your downrange distance from interface. Roughly and theoretically, yes. If you\'re in an orbit which passes over KSC (true assuming no plane change maneuvers and a remotely sane liftoff profile), you could use it to time your perikerb adjustment burn for the 'moment' when the to-KSC marker passes (slowly prograde) through brown-90 on the far side of the planet. In practice, pending lifting flight and reentry heat, if you want a precise landing a steeper entry is preferable. You could start a less-efficient but steeper burn when the KSC marker rises to a specific angle. Be aware the KSC markers are just a crude orientation measure dating from long before the map view existed, and have really been supplanted by the map. I\'ve considered flying some mystery orbit recoveries without the orbit projection for fun, but I imagine learning the geography in that scenario; I don\'t personally view serious use of the magic home indicator as any more fun than using the magic map view, and it provides less useful orbital data than even a crude topographical map.

Well, 'space travel like a pro' continues to evolve, and this game isn\'t exactly intended for that. In terms of the pure 'travel' part, Orbiter\'s likely to be a better learning tool if only because of the ability to spawn in a given situation without ten minutes of fuss. If you want combined engineering and travel, KSP\'s in a field of one, good and getting better. My three favorite courses on orbital mechanics and spaceflight whys and wherefores are NASA\'s http://space.au.af.mil/primer/orbital_mechanics.pdf , http://www2.jpl.nasa.gov/basics/index.php , and http://history.nasa.gov/afj/loressay.htm WX_Echo\'s KSP Orbit Mechanic is a great tool for rapidly exploring how these phenomena act in the Kerbalverse specifically. In terms of design your fundamental tool is going to be the Tsiolkovsky equation, especially if you choose to explore Silisko Edition which incentivizes staging much more heavily.

Except that it also doesn\'t simulate any real-world chaotic perturbations, so the two points that are fully stable are (as) stable (as every other orbit) in KSP too. 1. Go to L4 or L5. 2. Stay there forever. 3. Profit.

Radial fins on the SRBS can also help, provided they\'re well aft of the decoupler. In general decoupler torquing is a semi-intentional aspect of the game\'s design, and one approach is that if you can keep the nose on the right spot rolling actually doesn\'t matter. It\'s also guaranteed to last only 25 seconds.

It\'s difficult to work out stage structures from pictures; the .craft file from your KSP/Ships directory would be a better way for people to get their hands on your problem. For what it\'s worth, RCS was initially created with a counterintuitive but customizable algorithm that used tanks in the order they were placed on the craft. It\'s now supposedly changed to purely using the physically lowest tank on the craft first. A couple of people are having issues that suggest that the latter may not be true, or may become untrue in some circumstances.

In general winglets at the nose of a craft create instability. Barring a fundamental redesign, my first recommendation would be in the lines of 'fight fire with fire': Stick more winglets on the back. The stabilizing torque they create will hopefully override the unstable torque created by your 'legs'. The aerodynamic model is simple enough right now that fins are purely additive and don\'t need to be in clear air. How much you want to exploit that is an aesthetic consideration An initial tip: Stick your fins to the centermost thing you can, or can bear to. Fins with flexible lever arms tend to a different kind of amusing instability.

ThatCrazyPilot\'s a dumb kid. Whatchagonnado. The others are definitely, or could be, just kidding around. I\'d considered posting very much like that - approaching a line, we all start somewhere - but on second reading I think it\'s all intended in good humor.

ASAS doesn\'t handle touchdown, though it can handle keeping your craft vertical while you play with RCS. Touching down on the Mün is still a bit weird sometimes, but the number one rule is do not take the impact on your engine bell; LFEs in particular just can\'t take any impact. There are people whose ships have Jengad at .1m/s touchdowns. Strap on some dedicated lander legs or improvise with SRBs or winglets and decouplers if you want for vanilla.

Which is to say, in the meantime get into <KSP>/Parts/<partname>/textures and hack up your PNGs. Welcome to the world of UV mapping.

More discussion here. Conclusion, it may juuust be possible in KSP. Edit: I failed to notice this topic was old and I\'d already said basically the same thing.

Not too much help, but if you\'re trying to extract 'altitude' you\'re probably best going through kinetic and potential energy-style equations rather than translating things into velocity; presumably the mass and time units will fall out in the end. I also notice that if I\'m reading your equations right, your altitude result is going to be altitude at burnout rather than maximum altitude reached. I suspect you\'re more interested in the latter, and they\'d only be equal by massive coincidence. Also, because I\'m an Internet Cheater...it\'s been too long since I worked with logarithms and I wasn\'t great anyway, but are you sure your fundamental equation is a correct transform of the Tsiolkovsky Equation?

Right. Launch west at the equator and you\'re paying 200 extra m/s. Kerbal? Maybe. Economical? No.

Well, there\'s not much more to it. Newtonian equations only care about velocity relative to the planet\'s center of mass, and the ground (and atmosphere) of a rotating planet are moving relative to the center, fastest at the equator, zero at the poles. That free velocity is a major reason launchpads are as equatorial as their owners can make them. On Kerbin, that\'s about 200 m/s at the equator; on Earth it\'s... 6E6*2pi/24*3600... 450 or so. 'Just remember that you\'re standing on a planet that\'s evolving, revolving at 900 miles an hour...' You\'ll notice a big jump eastward on your NavBall when it switches, or you switch it, from the surface to the orbital REFSMMAT and that horizontal velocity gets integrated. That\'s also the reason weather systems rotate one way in the northern hemisphere and the opposite in the southern. It\'s called 'Coriolis force', and it relates to changing your radius in a rotating system. You\'re actually very gradually adding angular momentum through a tiny 'sideways' force when you move anything toward the equator, and subtracting it as you move toward a pole. On very large scales that force can become significant or overwhelming.

They\'re intended for tank-to-tank use, and don\'t feed directly into engines. You need to have a tank above the engine - or any other side-mountable component, technically.

Tested. Craft attached. Answers appear to be no and no.

You\'ll sprain your brain trying to translate from WASD to the camera. The camera\'s mainly for Pretty, with occasional moments of usefulness. When flying, clamp your eyeballs to the NavBall at the bottom. It contains the useful flight information, and your keys always move in the same direction on it.

\'Kay, well, it\'s half-workaround and half-diagnostic but how about manually hacking your settings.cfg in the KSP directory? It\'s where that panel writes to. The relevant chunk from mine: AXIS_PITCH = joy0.1, SideWinder Precision 2 Joystick 1, False, 1, 0.03745231 AXIS_ROLL = joy0.2, SideWinder Precision 2 Joystick 2, False, 2.011212, 0 AXIS_YAW = joy0.0, SideWinder Precision 2 Joystick 0, False, 1, 0.02808923 AXIS_THROTTLE = joy0.3, SideWinder Precision 2 Joystick 3, True, 1, 0.02808923 AXIS_THROTTLE_INC = None, None, False, 1, 0 AXIS_CAMERA_HDG = joy0.4, SideWinder Precision 2 Joystick 4, False, 1, 0 AXIS_CAMERA_PITCH = joy0.5, SideWinder Precision 2 Joystick 5, True, 1, 0 The format is axis index, human-readable name, invert axis, sensitivity, KSP additional deadzone. I suspect that all sane joystick manufacturers assign axes in pretty much that sequence, but of course that doesn\'t mean you can count on it. If hand-hacking works, it becomes a question of the detection code falling down.