herbal space program

Boy do you and I have different pedagogical styles. In case you have forgotten, for a brand new player landing on the Mun without the benefit of RCS translation is really, really hard. I sure haven't forgotten. I could never have done it in the first few months of playing, but of course like you I can do it pretty easily now. It is absolutely false that having RCS as a "crutch" early on made me unable to learn how to do it "right". What it did was make it fun instead of a mind-numbingly frustrating and tedious challenge. As to getting in hot water with RCS, I wasn't suggesting trying to correct manually. Of course that will do more harm than good. But it will of course also add significant power to the SAS system, which could easily make the difference between ending up upright vs. sideways. Anyway, I seldom find that I make somebody feel like they've actually been helped by telling them they're doing it all wrong from the get-go. YMMV.

I don't know how you can say that having RCS helps with neither approach nor tipping over. Maybe it doesn't help you with your awesome flying skilz , but you know us regular folks do like to be able to line up all the indicators with RCS translation rather than by pitching this way and that while plummeting towards the surface. And if one doesn't stick the landing as I'm sure you always do, every bit of rotational damping you can get from having RCS/SAS engaged also helps. As you might have noticed looking upthread, I already suggested to OP that the capsule should be lower down, below the two bays, and the legs higher. Those changes will decrease the MOI far, far more than getting rid of a measly .05t of monoprop.

But OP's problem was tipping over when landing, not fuel consumption. Eliminating RCS will make that worse and not better, both by requiring better flying skills to manage the approach and by providing less rotational stabilization after contact.

Those both look like they could do the job, but there's lots of stuff you could do to make them less flippy. It's important to position your legs as high as possible relative to your center of mass, and your center of mass is currently way above them. It's also good to minimize your overall moment of inertia by concentrating the heavy parts in the center. You can accomplish the first thing by mounting your landing legs higher on your bottom tanks. Your exhaust nozzle should clear the ground after you've landed by just enough that you don't bottom out. Your legs are way lower than they need to be for that. Actually, you should be using the bigger struts on the bigger lander too. The other thing you can do, although it looks kind of silly, would be to mount your light materials bay on top of your command pod using a couple of struts and radial parachutes. That would concentrate mass in the middle and make you less tippy in general. I'll bet if you do just those two things you'll find you have a lot less difficulty landing upright....And I agree with other that that Poodle is waay OP for a basic Mun lander. You could lift a 22-ton lander off of Tylo with that! Nonono, they need to be as *high* as possible. The further above the point of attachment the COM of the lander is, the more it will want to flip if it hits the ground slanted. Also, four legs requires significantly more rotational energy to flip on its side than three, so that will also make the lander perform worse and not better.

I agree that demanding for Squad to answer to these accusations publicly is unrealistic and pointlessly antagonistic. But it does seem pretty clear at this point that they are still using a garage band development model even after their game has hit the big time. The devoted fans are screaming for more, and it is really very slow in coming. Modders are cranking out content way faster than the core development team is. I understand that there was a physics port and that's a whole lot of work for no content advantage, but still it is not unreasonable to expect them to have taken this ball and run further with it by now. If that's because they have in fact taken the bulk of the revenue from KSP and put it towards other ventures, leaving us out in the cold, then I do think it is pitchforks-and-torches time. Mind you, I could never begin to begrudge them the $20 that my early access purchase cost for the 1500+ hours of play that I've (mostly) enjoyed, but I want so much more, and I'm willing to pay what a big league game would cost right now just for a promise I can believe that a lot more is forthcoming in the next year or two. But if Squad is going to take that money and not deliver, then I'd rather see somebody with a real commitment to game development buy them out and finish the job properly.

If Squad is really more interested in things other than game development, maybe the best thing would actually be if somebody bought KSP from them and then got serious about taking it to the next step. I know for my part that I'm more than ready to pay more money if it will get me a program that begins to do all the things that are possible in this environment.

Wow, what a depressing thread. There is no reason that a game that is such a viral hit should languish in a half-finished state like this, and there is no reason that the people who developed it from the ground up shouldn't be amply rewarded for their efforts.

Thanks for the pointers. I found last night that turning off steering on the back wheels helped significantly, and oddly that turning off the springs and dampers, while it made the plane do a ridiculous little dance while stationary, seemed to cause it to be willing to go straight down the runway once real forces were applied. I would start it off that way, immediately engage the brakes, then time warp briefly to kill the physics and stop all the jiggling. Only then it seemed could I take off like I could before without inexorably veering off the runway.

Actually I was talking about landing gear as well, but as it turns out the really weird behavior I was getting seems to have been an installation-specific issue.

Thanks! I'll see if that fixes my problem...

Could you please tell me where to look up the discussion? I can't seem to find it in any of the obvious places, and I'm having trouble working around it on my own. Or maybe I'm having a different sort of bug, but I can't seem to get down the runway anymore.

Proper placement of both the decoupler (just above COM of the side booster) and the stabilizing strut (near the top) help a lot with this also. Also too, instead of using Sepratrons you can just impart a little rotation to your stack just before hitting the staging button. I've found that this throws my boosters clear pretty well.

Hello all, I'm having problems finding an in-depth discussion of the current issues with wheels/landing gear and how to deal with them. Could some kind person please point me to one if it exists or else post some advice here about how to get behavior more similar to 1.0.5 if it does not? Thanks!

I think it works pretty well as a means of teaching noobs how to play the game, but once you reach a certain level of proficiency I agree that most of what you said is true. There were some fun challenges for me a least in early career though -- managing a Kerbal orbital rescue with no target indicator and no maneuver nodes was IMO a worthwhile exercise in SOTP flying, for example. But that only lasts for one play-through. We can only hope that now that the physics model upgrade is (mostly) complete, the Devs will step up and provide some of this sorely lacking content.

Funny, I've had no trouble at all building rockets that work in the current game. It's things like planes that need wheels that seem to be FUBAR in my hands. I did have some really weird behavior with hybrid vessels that had new parts placed on a ship saved from a previous version though. Could that be you issue?

When I did this, I used those near-massless cubic octagonal struts, not girders. They were plenty rigid enough to do the job, at least for my itty-bitty plane in 1.0.5.

I played around with my longest-range Mk1 SSTO design from 1.0.5 for a bit last night, and it seems like the air has gotten significantly more favorable for this sort of design. In 1.0.5 it could only go transonic in the stratosphere with some loss of altitude. Now it seems to shrug off the sound barrier as if it's not even there anymore. I presume this is because of the reduction in Mk1 part drag, and I'm really happy about it because it seems like it more than undoes the nerfing that these designs suffered in 1.0.5. My best-ever dV left on LKO in 1.0.3-4 was just shy of 6km/s (with nukes, no ions), which came down to around 5km/s in 1.0.5.Now I feel like I could beat even the numbers from 1.0.4. Unfortunately, I made the mistake of trying to upgrade my landing gear from the previous save and overwrote the original file, and I ended up spending the rest of my time struggling on the runway. I'm not sure yet if this is due to all the wheel bugs people have been talking about or just my own problems adapting to the new parts, but it pretty much shut down my efforts to see what this plane could do for last night. I'll have to investigate further with a copy of that save file from a different machine tonight. It was very strange. When I had the plane as its original save, it took off just fine but the gear usually got damaged on takeoff. Then when I tried to use the next size up, the plane would not go straight no matter what I did and wanted to steer the wrong way. Inverting the steering on the gears made it steer the right way, but then engaging the SAS caused it to flip the wrong way. Without SAS it kept wanting to veer off course so much that takeoff was essentially impossible, and repeated attempts to re-place the parts fixed nothing. I sure hope I can figure these problems out tonight, because if I can then I think flying these Mk1 space planes is going to be a lot of fun again!

I did the same thing back in 1.0.5 for a Juno-based SSTO challenge. I can't say it worked great, but it worked!

I just spent a little time playing 1.1.2 after rather a long KSP hiatus. I must say that I am quite impressed by the improvement in frame rate with the combined upgrades to Unity 5 and 64 bit, but even after the two patches there still seems to be a host of weird little bugs. Toggling back and forth between the orbital and staging views has been a particularly consistent cause of problems for me (playing 64-bit Windows 10, unmodded, flying a fairly simple LOR-type Mun landing mission). Sometimes it just won't let me go back to the staging view, sometimes it only lets me go back after I click on the orbital view button a second time, and sometimes going to the orbital view (so far always while under acceleration in the 40-70km range above Kerbin) seems to cause a brief but strong phantom rotational impulse, resulting in the end that should not point towards space suddenly pointing towards space. I'd be interested to know if anyone else is seeing that behavior, as I did not note anyone talking about it in the bug forum. The game also seems to fully crash significantly more often, but I haven't been able to discern yet if there's a consistent gameplay circumstance involved. Overall, I think this upgrade was much needed to make the game more playable, but I also think it's going to be a long haul to iron out all these glitches. Anyway, based on comments above I'm eager to see if my Mk1 spaceplanes can once again get the same level of performance they had before the nerfing of 1.0.5! I haven't tried that in this version yet, but I'm guessing that if you hit 70km close to the apex of your trajectory, it won't take much of a retro burn to make re-entry pretty trivial.

The Wheesley can go supersonic now? Cool!

I was about to express my dumbfoundedness at what OP said, since every other scientific agency of the US government has used SI units since I was in elementary school.

Stuff like this (and the Kraken) is why I never played genuine hard career mode. I always left at least the quicksave option in there, because if the hardware doesn't fail you the software surely will sooner or later. I don't know how anybody can get through all of the tech tree without the program glitching out on them at least once.

Soon you can join the ranks of those exasperated by their refusal to behave the way you want them to! Seriously, though, you can get amazingly far just twiddling around with maneuver nodes. With a little experience and a table of Hohman transfer phase angles for bodies outside the Kerbolar system (or using the online calculators accessible through the KSP Wiki), you can go just about anywhere.

It's not an equation exactly. What I do is make spreadsheets with columns containing the periodic return times of the target body to some particular spot, generally wherever my ship's orbit intersects the target's, then I make another column next to that listing the return times of my ship to the same spot on its current trajectory. I usually line things up so that the target body is in the spot where I want to encounter it, then place a node for my ship at the same spot. From that position, I can calculate exactly when in the future, ad infinitum, both my ship and the target body will return to that spot, expressed as multiples of the target's orbital period for the first column and multiples of my period offset by the initial approach time in the second. I then scan down the two columns to try to find two numbers that are particularly close. When I do, I adjust the orbital period of my ship at the encounter point either up or down so that it will eventually return to that spot at the same time as the target body. This requires solving a pretty simple equation, i.e. time to encounter = Pship*X+ Ti = Ptarget*Y where Pship and Ptarget are the respective orbital periods, Ti is the initial approach time of the ship to the intersect, and X and Y are any integers small enough that you won't fall asleep in front of your computer during the time warp. In practice, it amounts to subtracting the initial approach time from some integer multiple of the target body's orbital period, then dividing that number by whatever integer gives the value closest to your ship's current orbital period. If you start with a target return time that is close to one of your ship's return times, the new period should require only a relatively small correction. Unless the two orbits are in some kind of exact phase relationship, the longer you are willing to wait the less energy you will generally need to expend to eventually reach an encounter. I'm currently using this method to calculate repeated encounters in an attempt to reach Moho capture from LKO for less than 1700 m/s total dV, a feat that I can now say with confidence is harder than anything else I've ever attempted in this game. This involves orchestrating a whole bunch of consecutive Moho encounters to gradually walk the ship through gravity assists down a ladder of resonant energy levels, eventually leading to an encounter that requires only a small burn to achieve capture. The above procedure is what I use for calculating initial encounters or encounters at different orbital intersects. For repeated encounters at the same spot, I've made tables of resonant orbital periods, e.g. 3:2, 3:4, 2:1 etc., arranged in order of decreasing energy. Using these, you can plan your encounter so that it exactly drops you to an orbit that will re-encounter the target body some number of orbits later. In this way, with careful enough planning, its possible to coast a really long way up or down with only tiny correction burns.

That was my back-of-the-envelope method as well, and as you said it generally underestimates your actual dV, so it's pretty safe. If you have Excel though, plugging the rocket equation into it is pretty quick, and then your spreadsheet is faster than even doing that on a calculator.