ZeroG

For slider values you can adjust with the controller this is an OK workaround, but IMO this is a long-standing UI issue. I often adjust engine outputs on-the-fly so I can make precise adjustments with largeish engines (so set the engine thrust limit to something like 1 for fine-tuning), but it's a serious pain if a rocket has multiple engines. I'm sure other players have other sliders where this is annoying. What would really be nice is something like alt+click or right-click on any slider anywhere on the UI to bring up a number input where I can just type a number. Since the slider appears to be a ubiquitous control on the UI, I think that would be a big quality of life improvement.

I do it with because I don't actually burn straight prograde, and I also want to estimate how long the burn will be. If it's supposed to take 40 seconds to circularize, I start the burn 20 seconds before apoapsis and point at the maneuver vector. Otherwise if you literally aim at prograde for your whole burn, you'll raise your apoapsis. If it's a high-acceleration ship or shallow trajectory I don't bother, but sometimes I use the node.

Today I noticed that there's a "Hibernate in Warp" setting on probe cores with advanced tweakables on. This may be a stupid question, but is there any downside to that? I'm inclined to always set that to "Auto" when putting a probe core on a ship, since it's not like the core is doing anything during warp anyway. I sometimes have bald spots on my ships' solar panel coverage, and it seems like this is a life-saver for that circumstance.

It's true that Dres is trickier to get to than most other places in the system, but IMHO it's nothing like the scale of how hard Moho is. At least anecdotally, almost all my missions to Moho fail, whereas I've rarely had trouble with Dres. Mostly it's because while both involve an inclination change, Moho has a very extreme capture delta-V requirement when coming from Kerbin. Both are interesting I think, but I'm just saying as far as difficulty goes, Moho is in its own class. I think if you really want to feel the love for Dres though, consider it's rough solar system counterpart Ceres, which I also feel doesn't get the attention it deserves. Did you know NASA launched the Dawn Spacecraft there? Fascinating stuff, but it certainly didn't get the attention of New Horizions (in fairness because Pluto is super-interesting on its own). Lots of cool discoveries were made on Ceres, but it seems like in KSP and real life, those mid-system dwarf planets just don't quite cross the threshold of inspiring for most people. ADDENDUM: Also, I really like going to Dres because it's difficult to get to without making me weep in failed attempts (see Moho)

Ah, forgetting to set up staging; this never gets old. On the plus side, the probe core survived.

So, I've been working on an interesting math problem and was wondering if anyone else had tried this. I wanted to figure out using only what stock KSP actually provides in-game to determine orbital parameters of the planets. KSP provides things like masses and radii, and you can mouse-over a planet in map view to get its current altitude and velocity, but no angles or eccentricities are provided anywhere. Bottom line, I'd like to get a value for semi-major axis and eccentricity for every planet on my own. Yes, I know there are reference values on the wiki, and it's possible to figure it out by inspecting the game's files, but I wanted to know how you could calculate such a thing. I got as far as being able to calculate a semi-major axis based on one reading of a planet's altitude and velocity; I rearranged the orbital speed equation to provide the semi-major axis when given velocity and radius, but I still don't know how to get eccentricity. I thought about taking two readings and using a solution to Lambert's problem, but I don't really have a good fix on the positions; all I get is the distance from Kerbol, but no angle that I can fix a position on. Another route I tried to go down was to use the semi-major axis to calculate the orbital period, then grab the radius/velocity once, then again exactly half-way through the orbit as timed by the clock; Kepler's second law says I'll get two equivalent areas that way, and their total makes up the total area within the orbit, but I couldn't figure a way to relate that back to the eccentricity. I learned a lot trying this exercise, but I seem to be stuck. Any orbital mechanics experts out there who know how to do something like this or can tell me it's a lost cause?

Ah OK, thanks, that helps. So there isn't a way to map a controller axis to Kerbal movement, like going up/down a ladder, or walking on the ground?

I searched around a bit and didn't see this issue posted anywhere else, but sorry if this is a repeat and I missed it. I'm using a controller for KSP. I have both a Steam controller and an XBox 360 Controller; I use the Steam controller, but I checked and this is a problem for both. The Steam controller's left stick is mapped to a controller left stick. I can map pitch/yaw/roll arbitrarily to any joystick or controller axis I like for flight, but there doesn't seem to be a way to map a controller to movement on a Kerbal in EVA. In control mapping on the "Kerbals" tab, the character axis bindings have places for translation and roll/pitch/yaw, but none of those things really make sense here. I tried mapping to translate, but that didn't seem to do anything (as in, if I move a controller axis mapped to any character translate action, nothing happens). For now, as a workaround, I can still use a/s/d/w for Kerbal EVA movement, but it would sure be more convenient to be able to use those same controller axes that are working great on rockets on Kerbals. Did I just miss the setting somewhere? Was one of the translate actions really the one I was looking for and this is just a bug? Thanks in advance if anyone has suggestions!

If anything, I think this helps highlight why NASA already holds Mars missions as a high priority. They're already planning another rover now - the Mars 2020 mission (https://en.wikipedia.org/wiki/Mars_2020). Another exciting Mars-related thing I recently read was the Planetary society's report on how feasible it would be for humans to orbit mars: http://hom.planetary.org/. But yes, I totally agree, this will I'm sure factor into future exploration; it might be prominent in where they decide to send the next rover; I'd love to see some analysis of that water. Also, water on Duna? Yes please!

So, I've noticed a trend in the way I play KSP recently. I noticed somebody mention how many Kerbals they'd lost over the course of a career playthrough, and I thought, "Yeah, I've returned a surface sample from every surface except Eve and Jool in one playthrough without loosing a Kerbal!" Then I realized... every time I land, I quicksave before trying, then quickload if something goes wrong, so it's not really fair to say I haven't lost any. In fact, by doing it that way, I've mostly eliminated the need for rescue missions, which can be entertaining. However, I'd rather not completely forbid myself from using quicksaves. The Tylo mission was agonizing enough already - I can see repeating it once if there's a disaster, but not as many times as I quickloaded when I tried it. So, I've been thinking, maybe there's a way to compromise, so that I can't always quickload. Way back in the day, I used to play a little Battletech (the tabletop RPG that Mechwarrior and other games are based on); I was thinking maybe there could be a dice-roll mechanic to offset ease of access to quickloading. So, for quickloads, I would use a set of rules to determine a dice roll that must be successful to load; otherwise, no loading, and deal with the consequences. Would anyone else be interested in such a system? Here's some ideas I've come up with so far. The roll should be largely based on the Kerbal's "luck"; if we wanted to make a more traditional roleplay system, that could even be a stat in and of itself. So, the various modifiers may have to do with how the circumstances affect the Kerbal's luck at that moment. Also, I think the reason for the quickload should make a difference, as well as some other factors. I'll base this on 2d6, since that's what I'm nostalgic for . Also, I'm counting "revert" as the same thing as "quickload". Here are the following reasons I can think of why you might quickload, and their base rolls: 1. Any roll for an unmanned ship: 9 2. Kerbal(s) die on attempted landing (non-atmosphere body): 7 3. Kerbal(s) die on attempted landing (atmosphere body): 9 4. Kerbal(s) are stranded after landing (broken rocket, not enough fuel, etc.): 5 5. Kerbal(s) die due to operator error (accidental staging, rocket pointing the wrong way, etc.): 4 6. Kerbal(s) are stranded in space but alive (mistimed burn, operator error, etc.): 6 7. Kerbal(s) die while lifting off from Kerbin on rocket which has worked in the past: 4 8. Kerbal(s) die while lifting off from Kerbin in untested rocket (not due to operator error): 7 9. Your manned ship has pulled a non-optimal maneuver you'd like to try again: 5 10. Kerbal(s) die while landing plane (non-parachute, horizontal landing): 4 11. Kerbal(s) die while lifting off from non-Kerbin body: 6 If anyone can think of other reasons you might quickload/revert, please chime in. I generally figure other circumstances won't require a roll. Also, notice I'm using a "testing" mechanic here for circumstances 7 and 8; to me, that means I've flown this exact rocket before and it worked. I usually play a sandbox game and a career game, where sandbox is treated like my testbed (I wouldn't enforce these rules there), and career is "for-real". If I pull a craft file that I've tested in a sandbox save to a career save, I consider that valid testing. I think Kerbals may respawn in certain circumstances; obviously, I'd forbid usage of respawned Kerbals if they've died. For modifiers, I was thinking of using a system like Fallout 3 or Skyrim's "perks", except they won't necessarily be helpful. Each will have a name and modifier: Luck of the Kerbals: For circumstances 2 and 3, all Kerbals have a bank of "luck" to optionally draw from; at first, this modifier is -5. Each time you invoke this modifier, you draw from the luck pool, so you must keep track of how many times you've invoked it since the beginning of the save. Use the following lookup table: [table=width: 500, class: grid, align: center] [tr] [td]Invocations (including current one)[/td] [td]Modifier[/td] [/tr] [tr] [td]1[/td] [td]-5[/td] [/tr] [tr] [td]2-3[/td] [td]-4[/td] [/tr] [tr] [td]3-4[/td] [td]-3[/td] [/tr] [tr] [td]5-6[/td] [td]-2[/td] [/tr] [tr] [td]7-8[/td] [td]-1[/td] [/tr] [tr] [td]9+[/td] [td]0[/td] [/tr] [/table] Hot Shot: If the craft is a plane and Bill Kermin is on-board, -1 (player discretion on what counts as a "plane") Living Legend: If Jebediah Kermin is on-board and the craft is not a plane, -1 MOAR ROCKETS: Big rockets are considered lucky; for circumstances 2 and 3, if there is any rocket nozzle attached with thrust greater than 120 kN, -2 (does not have to be working, just attached at time of incident) The Kraken: Jool's Mun Bop is unlucky; +1 if within Bop's SOI More like BlechJeb: Usage of MechJeb is unlucky; +1 if MechJeb has been used for anything except information since launch from Kerbin Manual Override: If MechJeb is currently in use at time of quickload for anything other than information, +1 (stacks with "More like BlechJeb") Tempting Fate: If there are any Kerbals in external command seats while in atmosphere, +1 Yay for Aerodynamics: If there are any Kerbals hanging on to ladders etc. while in atmosphere, +2 (does not stack with "Tempting Fate") Purple Power: Eve's atmosphere is tricky; the celestrial powers that be have granted -3 while in Eve's atmosphere to compensate Finally, I consider a few other mods worth mentioning; dying from burning up in atmosphere using deadly reentry should count as circumstance 3 (I haven't used Deadly Reentry, but with decent testing death is easily avoidable, right?). Also, I'm aware of life support mods; I figure if you're quickloading because you realized your Kerbal is going to die from lack of oxygen, etc., or they have in fact already died, that should be a base 8 to reload. Anyway, thoughts on that? Suggestions? More modifications? Are there maybe other places a dice-roll mechanic might be useful in KSP?

OK, cool. Inspired by Redshift OTF's post, I actually went ahead and put some parachutes on top of the plane, figuring I'd do a vertical landing by activating the parachutes right before landing, then a standard take-off. I was landing at KSC and decided to try it out - it more-or-less worked; obviously the sudden jerk upward threw my plane out of control for a little while, and it's way off-balance, but it actually landed that way (on the back engines). I was also able to take off from a non-runway as well. Here's a couple of screenshots of the landing on Kerbin: I'll try using hyperedit and see if I can make this work on Laythe before doing my full-blown mission. Thanks! [update] Indeed, it worked! (with only a little breakage). I hyper-edited the plane into Laythe orbit, then used MechJeb's Landing Guidance feature; I entered some coordinates I found here: http://forum.kerbalspaceprogram.com/threads/47979-Any-flat-spots-on-Laythe-the-length-of-a-runway-other-SSTO-questions, and let let the autopilot put me into a descent path. I shut the autopilot off after the descent was plotted (I'm pretty sure it would have cratered me if I had just let it do its thing), and it put me in the general vicinity. It turned out to be a nighttime landing, and I don't recommend that; it made it way more difficult. I quicksaved before attempting to land, and botched quite a few landings before I finally started getting a few right. Really, I think the trickiest part is finding a flat area; even the coast can be pretty hilly. The nighttime aspect was definitely a part of that problem. I had several takeoffs botched as well; for some reason I went into a flat spin on several attempts, seemingly as a result of being on slopes. I finally did take off on one attempt, and I ended up breaking off a control surface. I had four in total, so now I only had three. Smart A.S.S. couldn't really cope with an uneven number of control surfaces, but SAS helped out a bit. I managed to get back into orbit, and actually found that Laythe takes quite a lot less fuel; even having expended some oxidizer to descend, I had more than enough to get back to a 60+K orbit. If anyone's interested, here's the .craft file of the plane I used; action group 1 toggles turbojets, 2, toggles the 909s, and 0 deploys chutes: https://drive.google.com/file/d/0B2wOLhKlE-_9cklfZVRSY3FRSTg/edit?usp=sharing. Thanks for the help!

So, I'm just starting to get the hang of spaceplanes - I'm tweaking a design now and testing it out on Kerbin. I was wondering, though - if I have a spaceplane that can get to orbit and land again on the KSC runway, is that same plane likely going to work on Laythe, where there is no runway? I can land a plane on the runway at Kerbin, but I've never successfully landed a plane on the ground. Will Laythe's lower gravity help me out there, or should I try to master non-runway landings on Kerbin? I suppose it goes without saying, but I'm also going to want to take off from Laythe. My overall plan is to ferry the spaceplane to Laythe orbit, refuel it, and land/do science/take off all using one fully-fueled spaceplane. I use Mechjeb, but would prefer not to use other mods. I hope very soon I'll have my first working spaceplane finished, and I can post pictures and the .craft file. Right at this second, I have a roughly 16-ton plane.

Thanks for the answers on how to get Kerbals out of the module - I was wondering how to do that as well! Left-clicking instead of right-clicking was the trick for me.