The_Rocketeer

You can't forget to deploy the OX-STAT. Very important.

Fascinating.

From MY experience, this is total hokum. But I'm happy to be proven wrong.

I'm with Wanderfound here, it sounds like you are misunderstanding something in the fundamentals of how the process is supposed to work but without a clearer demonstration of the steps you're taking it's impossible to give any sort of answer that isn't either too broad to be worthwhile or else presumes a significant degree of noobness (which may or may not apply). Make a little demo of what you're doing with a few screenshots and the answer will probably become clear to those of us who know. That, or we'll tell u to submit a bug report and go on to the next problem

Or in steam default is F12 and you can upload them straight to your steam account.

Steam downloads both 32-bit and 64-bit clients. Its essentially just a separate exe. You could just rename the 64-bit exe file to KSP.exe and Steam would be none the wiser, or you can do what I did and add it to your games list as a separate "non-steam" game.

1. Very best advise is to make course corrections very early, as late corrections cost much fuel. 2. Aim for a really low (but safe!) Periapsis on your flyby as this will maximise the benefit of the planet's gravity to assist matching speed. 3a. If the planet has at atmo you can aero-brake - this means dipping into the atmosphere to use drag to slow you down. It's dangerous because if you slow down too fast you will end up descending to the surface, but it can save a lot of fuel if done right. 3b. If not, you need to get as close to matching orbit during transfer as possible before the encounter starts, which will minimise fuel use during the encounter. 4. I recommend practising making transfers from Mun to Minmus and back. Using an ion engines will help to simulate the speed differences and longer burn times for planetary transfers, but 'hitting the target' (getting an encounter) is easier.

Maybe you just have remarkable night-vision Laie. In my experience, moonless nights in undeveloped regions are black as... well, night. Starlight is lovely stuff, but bright it ain't.

LOL @ myself, ok but that's some serious camouflage. Are you using the LV-Ns during takeoff? If so the rocket tanks will be draining too (unless you've hosed them - I looked but I don't see), probably more of the problem. Vertical stabiliser's never been an issue for me, but I fly stock. Some of my aircraft have very small stabilisers.

Sorry Laie, but this is hogwash. On a 'dark' night on Earth you still benefit from atmospheric light refraction and reflection from surface light sources. Go somewhere really dark and you won't be able to see your hand in front of your face. I remember a crystal clear moonless night on a small Scottish island and I couldn't make out the track under my feet. (Fell in the ditch 4 times.)

As far as I know, the chute doesn't actually need to deploy, it should complete through activating the stage. Doing this does actually set the chute to 'fired', so it will automatically deploy at the relevant altitude - you'll notice the icon changes from white to a blueish off-white to signify this. I've done a lot of high altitude chute contracts in 0.25, though not since 0.90, so it's just possible they tweaked it and what I'm saying is worthless.

Can you post a pic of CoL and CoM also showing? My first guess is your CoM is moving backwards rapidly as the nose tank drains first. Also, I may be wrong but I believe you should add an engine after its intakes and not the other way around. This may also be the problem.

Someone correct me if I'm wrong on any of these: The yellow notepad symbol is a marker for a current contract. Check you contract list for a 'survey' mission - that's where it is (map) and which way is towards it (navball). The purple markers are (I think) pro-normal and anti-normal, which is the direction to burn in if you want to change your orbit inclination (the angle between the ecliptic plane and your orbital plane) upward or downward. They are perpendicular to your orbital trajectory on the y (up-down or north/south) axis. The blue markers are (I think) pro-radial and anti-radial, which is the direction to burn in if you want to steepen your trajectory upwards or downwards (that is, more straight up/away from the ground, or more straight down/towards the ground). They are perpendicular to your orbital trajectory on the z (near-far or high/low) axis.

Are you orbiting around Mun in the right direction? A few people have posted similar problems and I believe this is typically the cause.

No, I don't know what a quantum leap is. I was making a figurative expression using language I don't understand. So sue me. Yeesh. Look out for the precision police. To stay on topic, in KSP it's not uneconomical to build a craft that does the job you intended it for within a budget that you consider reasonable. If shuttles meet those criteria, use them. If you derive the same satisfaction as I do from engineering such a craft and making it work, remember to factor that satisfaction into your design specification. Otherwise you become bored, jaded, and trawl the forum for unwitting contributors that you can mock and detract with your superior intellect.

I don't really see how that's relevant. I was highlighting the cost-advantages of the vehicle, not the administrative costs of bloat-NASA's mission expenditure. As above. I don't really see the advantage of comparing modern rocket design costs with 1970s era NASA design costs. Development budgets and actual bread-and-butter mission costs are two different things. I'm not trying to suggest that the Shuttle was the best way to do things. Most organisations work to budget, and NASAs 1970s budget was very, very large. Why bother making it cheap when you can make it expensive? Nonetheless, the Shuttle remains a very successful experiment, albeit one that's rather dated by modern standards and inferior in the light of other technological advances.

True,IN KSP. In RL, and the part the Ruskis never quite got to grips with with the Buran, is the NASA shuttles' engines - by far the most expensive part of the engineering - were 100% reuseable. Compared with multi-stage rockets for equivalent payload, the shuttle was a quantum leap advance in economy, with the only physical loss being the external tank, which was designed to be disposable. Scott Manley's video (which I have seen) wasn't a very thorough exploration of what can be done, and makes viable shuttles look far more costly than necessary - the NASA model is workable and is still very parts-efficient compared to multi-stage ascents. However the engineering challenge of building a functional shuttle is by no means for all and given KSP physics, dimensions and handling (read loss) of parachute-borne parts, there's no economic reason to use them over another SSTO vehicle. P.S. From the sounds of it you're using more SRB thrust than you need to for your Mk2 Shuttle - with some careful engineering you should be able to complete the ascent with a pair of BACCs and save some Kerbucks.

Put yourself on an atmo-scraping trajectory (PE ~60km, AP ~100km) and separate and land the tug while the lifeboat is making a second orbit, then land the lifeboat on the next pass/when aerobraking brings it down.

Yeh GoSlash27 is quite a font of know-how regarding many things kerbal.

The best autopilot I've found (by no means conclusively tested) was from the Lazor system. That had simple set altitude and set heading features which is pretty much how real autopilots work. I could be wrong, but I haven't seen this in Mechjeb (admittedly I haven't tried all the features - long flights are a rarity in any case, and, well, sometimes I just prefer to do it myself!)

Klesh has it about right. It doesn't matter very much where the CoL is vertically, but if it's not behind the CoM at any point during a flight, the plane will become very unstable. Did you ever have those toy polystyrene plane/gliders that came in a little envelope when you were small? You slot the wings thru the fuselage and add a plastic weight to the nose - if the weight wasn't on the front (the CoM in front of the CoL) the glider wouldn't stay pointing the right way and just tumbled to the ground.

Lol, I too am an enthusiastic amateur more than a real physicist, aircraft designer or top boffin of any description. Still, it's fun to pretend...

Sorry I made a typo last time - the correct spelling is stabilators (not stabiliators). What I said in my last post is actually wrong. I've now edited the post to correct my derp. In planes with a rigid tailplane, the whole tail assembly is sometimes called a stabiliser, because it helps to keep the nose pointing forward. It's common to refer to the individual rigid wings as horizontal or vertical stabilisers. Stabilator, though, does specifically refer to the pitch controlling surface rather than others. However, there's no reason that ruddervators and stabilators can't actually be the same thing. Edit: FWIW, yes the tailplane on a F-16 does use stabilators

They are called elevons, canards, and ruddervators and they generally combine a pair of the primary controls (pitch/roll/yaw). Elevons are combined elevators and ailerons, and are usually located on the trailing edge of a delta wing. The Space Shuttle and Concorde used these, as well as some other delta-wing jets. Canards perform the same function, but are located in front of the main wing, as in the case of the XB-70 Valkyrie or Eurofighter Typhoon. Ruddervators combine pitch and yaw control, and generally are located on the tail in a V-shape (sometimes called a V-tail). Stabilators are tail wings that pivot as one piece to control pitch, like the AV-R8 winglet rather than the Delta-Deluxe Winglet. In this respect they are similar to most canards.

I had assumed this was just an oversight and the guy meant elevons. To most people ailerons are just any control surface on the wings. Not saying that's right, just saying it is.