Captain H@dock

I've recently found that moving the mouse away for a couple a seconds will make the pop-up close, but not the maneuver node. Also, a fix to 3) Dragging a maneuver node 'resets' any advancement to future orbits is to place a dummy maneuver node where you want to work at (N orbits later), with 0 dV, then create a second one which will be the maneuver you want to work with. Since this one is automatically added after the previous one, it is already N orbit in the future, and you can drag it. Oh, the things we have to do to use that irritating maneuver node IU...

Now, for bonus, what's the tiny down facing triangle shaped light on the top left of that dial? It sometime green, sometime orange, most of the time it's off (black). Looks like a gear ground contact light to me, but I'm not sure... It seems to be new-ish, when googling for screenshot it wasn't visible. But this one has it: http://i.share.pho.to/fef4446f_o.png

For the record, I've played a bit with using control surfaces as flaps in stock 1.0.4, and you can get significant results, especially if you are putting them in pairs or slats/flaps. Better results are observed when placing them close to the CoG (on the longitudinal axis). Sink the Slat in the leading edge for better results. Most impressive results are with really really heavy planes powered by those weak jets (think 100 tons mk3 planes with airliner wing). Properly simulated consequences are: Higher lift for the same speed (aka, lower take-off and landing speed). (also means you can break your wing by deploying them above the safe speed) Higher lift for the same AoA (aka, level flight possible at much lower approach speeds, and less rotation needed for take-off) Higher drag when deployed Instant 'KSP stall' when retracting the flaps while flying too slow for a clean wing configuration. Ballooning effect induced by flap deployment Caveats: Sunk slats/flaps will still produce lift with AOA, which means they will increase your wing area when then shouldn't. sunk slats/flaps will still produce drag with speed, which means adding flaps to your design will probably reduce a bit the aircraft high speed performance. You can't 'stage' flaps (unlike the picture above, no double slot system) since control surfaces attached to another control surface don't move when the parent control surface does. [1] [1] All objects display the same behaviour. Which is really weird visually, and quite a shame when trying to do multi-positions flaps. However you can have several flaps along the wing and have them bound to different action groups. This way you have the desired intermediate lift/drag configurations. I could provide pictures if someone is interested.

Well, I don't know which spaceplane doesn't qualify as a wingless sausage then... If a plane is going to be doing close to 1500 m/s at 20,000m, it's sure isn't going to have a high aspect ratio... At any rate, small SSTO (with rapier) are easy to do in 1.0.2 - 1.0.4 with the right flight profile. Such as the Tevelord's one, or this one (1.0.2 fuel configuration). Keep it simple, and it will accelerate quickly enough to make the 12,000 to 20,000 flight profile easy: This takes off at 110 m/s (no need to rotate). Gear in, hold attitude until reaching 290, climb to keep speed constant until 13,000 (speed slaved pitch, concorde's style), level off and accelerate to 1100. From there 1.0.2 and 1.0.4 differ (climb rate was differing too due to different TWR) 1.0.2: you'll soon see your speed reach 1100 with heat bars, so you get in a climb just enough to avoid them, yet enough to be climbing at 20-25 degrees with 1375 m/s by the time you're really loosing speed. 1.0.4: leveling off will make you loose quite some altitude, but on the other hand you can accelerate a lot more yet, at a slower rate. So it's up to you how you want to balance top speed (between 1400 and 1500) and angle of climb (between 20 and 5 degrees). But in both case this design will take you to orbit with plenty of fuel (add 150 LF for 1.0.4) for rescues / tourists / crew ferrying. And it's around 20 parts. So learn the profile that fits your version with small build first, then move onto bigger ones. As an aside, i recently realized I've been putting my airbreaks in reverse of their designed orientation... that's due to the adapter itself being 180 flipped Good luck closing these in the real world!

Indeed, 5000 ish m/s sounds quite doable within the limits of the Kerbin SOI. Thanks for the asnwer.

Is that even possible? If, as suggested by the OP, you want to never, ever have been orbiting the sun, you would need to be leaving kerbin SOI with enough speed already to be right away on a Solar escape trajectory. I'm not really aware of the required speed for an escape trajectory from as low as Kerbin in the Sun gravity well, so this might be a stupid question...

Now, I consider completing several contracts with the same station as cheating! Unlike sending a grossly poorly-equipped empty station on a random solar orbit, which is surely not! More seriously, it's all about the money gain compared to the time it needs. I play multi-mission (KAC), and solar station are simple: launch, burn all your fuel, set KAC alarm for sun SOI. 1d later you can cash the reward and get a new contract. With mun (and kerbin) station, they are that good breed of contract that won't clutter your "active contract" section for too long. But sure, they make no sense... (My career is around Year1 Day40, and I've probably flown 500 contracts already... I only go interplanetary once I've got a complete tech tree and level3 crews, until then I usually have KAc events regarding contract on an hourly basis)

On the subject of easy money contract, the solar station are the nicest... You get paid hundreds of thousands just to launch straight up to the edge of the SOI... If the "science from" are the slow and steady revenue ones, the solar orbits are the equivalent of robbing a bank....

I'm fairly sure we're saying the same thing... LAB is slow (a handful of science an hour), landing is fast (200+ science per landing, which shouldn't take more than 2h). I'm not asking for the LAB to contribute more than it currently does. I'm just surprised because 1.0.0 brought dozens of threads on how over powered the lab was. Being in a slow career, it's only recenlty that's I've reach the MPL node. My conclusion was that it really doesn't make sense to call it OP since you can probably complete the tree in Kerbin SOI without the LAB, in under 50 Kerbin days. It would probably take years to lab-timewarp to the required 15.000ish science points.

I was refering to the last moment of the hypersonic on air-breathing. From something like 1100 (and accelerating) at 9K-11K, I am either: A. Climb at 20-25 degrees, but peaking around 1400 at 25K. B. Climb at 10-15 degrees, thus peaking around 1475 at 25K. A is not maxing what I could get from air-breathing, but B is quite shallow a climb, which means quite a lot of time in draggy territory (25K-35K) on rocket mode. I feel I could benefit from getting the B scenario speed with a A angle of climb. And that would only be possible by increasing TWR, hence my question...

I agree. The MPL is just not time effective enough to be helping. In a polar orbit of the mun I can land on a biome every second orbit (one to land, one to take off and RDV with the fuel/science station). By the time I'm done doing all mun biome, I might have 50 or 60 science in the lab... Compared to half a dozen thousand science from farming the mun for science, that's really pointless.

That is the really important part. If you don't do this, you might end up with inverted half range throttle course.

By the way, since I now spend long period of time in map view when flying my SSTO planes, I think i've noticed a graphic bug with overheating effect on part. When a part is close to overheating, it turns red. When it cools down, the red goes away. I've got a feeling if you're in Map view when the red was supposed to go away, it doesn't, ever. I was wondering if anybody else had that feeling. That could require a bit of time to reproduce... Note that i've got all fancy effects de-activated (no edge lighting), so this might be specific to that config.

The KSP wiki on experience is a good start. The level3 Tour is the following: take off from kerbin, orbit the moon, exit kerbin SOI (enter sun orbit then get back to kerbin SOI), land and plant a flag on minmus. Order doesn't matter. Preferably in a space Bus with 16 or 24 seats (the 24 flags are a pain to do, though)

I haven't tried it yet, but does it help to add some engines? It feels like it's needed, as my profile were mostly running of air before reaching what felt the RAPIER top speed. But maybe the extra weight is too much to help...

It's random, but a different kind of random for everyone... Mine currently lacks engineer.

After flying my tanker SSTO (refuel orbit depot), I think you're right. We might loose a bit in term of payload fraction. Either that we need to add more engines than before. It is quite hard to accelerate on big planes while keeping at high enough pitch to not spend too much time in the low atmo. I'll probably need a few days to get a definitive figure on the efficiency loss.

I really disagree.... I just did about 30 climbs to orbit since I came back home, with a lot of very different profile (from 800 at sea level to climb at 30° to the 1.0.2 way of doing it) and they all seem to work pretty well, I'm using more liquid fuel than before, but I can easily get 1300 m/s at 25K on airbreathing, and my i've got a profile that does 1475 (accelerate at 9000 m, climb at 1100 m/s just enough to avoid burning up, that should be around 15°). All in all I think it's slightly easier, but you have to forget about the 1.0.2 profile and see what works best. Quick save before entering hypersonic to try different things. And re-entry.... I've only done 2 today and I'm now confident I can glide to the KSP on every attempt, and with no speed brake. I don't know if this was possible in 1.0.2 (I don't think so), but you can manage speed/gliding distance with your angle of attack as soon as 50K. Going to over-shoot the KSP? Set for 30-40° AoA! Going to undershoot? Set for 5-10° AoA! You can litteraly move you landing point forward/backward with this. No overheating issues (though you see bars) in sight. I flew from map view until 2000m from the KSP... If you wondering about the plane I used, check this thread: http://forum.kerbalspaceprogram.com/threads/126304-RAPIERs-and-Turbojets-are-amazing-in-1-0-3?p=2036507&viewfull=1#post2036507

Just fired up my light mk2 RAPIER SSTO in 1.0.4 (which for all purpose is 1.0.3). We're slighlty back to air-breathing territory now. From an early feeling (two quick ascents to orbits), it's a lot easier to not overheat (i'm yet to see temp gauge on my plane...), you can climb faster from sea level if you wish to, and you can get 30% faster (and slighly higher) on air breathing RAPIER. I reckon you can also have a shallower climb in the rocket territory due to less heat, and less drag. No need to pull up like crazy when reaching 1100 m/s like before. You therefore need to pack up a bit more LF. Also, it takes longer to accelerate on the runway. But if you could do it in 1.0.2, you should be fine in 1.0.4. Note: Rear tank is full. Fuel was balanced for 1.0.2, so it's now quite unbalanced toward Ox, but you can get to orbit with that. I'm yet to de-orbit, because that's not the part I worry about (yet?). That might have changed... But ascent is now a lot less hair rising.

I learned that the docking indicator bug is still not fixed in 1.0.2 stock for docking port unaligned with the CoG (such as the inline ones). It's hard to believe nobody at SQUAD found the time to fix this in the lead up to 1.0: This is a pretty well known bug (countless reports here), it's trivial to reproduce, and I'm fairly sure it would take less than half a day to fix. First time rant at SQUAD, but seriously! Like if docking space plane (which have huge moment of inertia) wasn't finicky enough... I know these are two incompatible docking ports. It's the same with compatible ones, but this allowed me to litterally stick the two docking ports onto one another to better demonstrate the issue. In b4 "you could just install the docking aids mod instead of waiting for SQUAD to fix it".

I had it in 1.0.2 but i didn't have the minus explore one... I think there is less reliability in these than there used to be.

I reckon you can, because that's what people do when they build something in the VAB like : tricoupler -> 3 jr Docking port -> 3 jr Docking port -> tricoupler. You only have a connection between one of each set of docking ports in the VAB, but the other two, being align with their counterpart, dock as soon as physic loads on launch. Also, ring stations would probably end-up in the same situation (the last docking port pair to attached would be located on the same ship)

These are space tug: (middle ship. chemical = not so efficient) Nuclear = more efficient. (these are mock-up, they lack electricity and RCS)

The point of the spreadsheet is to do the math once, then worry less about it, yet somehow decouple it from the game (aka no mod) The selected cell below will show you the one formula you need (TWR is not the hardest...). Disclaimer, most of the data I use is still 0.90, don't blindly copy it. Assuming this fictionnal lander Gross Mass is 10.2 T, Tanks are 2 x mk2 short (the adapter is identical to a short tank) and 4 x T200. 1 x 909 engine. I'm inputing these in the yellow cells at the top. I can see (A) that I have 2600 m/s of vacuum dV, as well as a Kerbin TWR of .6. Barely enough for two perfect consecutive moon landings from and back to low orbit. Now, if I want to take this to Duna, its atmosphere will mean i might get as little as 650 of dV (it's really an approximation since Duna has less than 1 atmo, and not all the burn will be at sea level), but still, it's a concerning low. So with (, I'm checking what the results would be with 3 x 48-7S engines. While vac dV is similar (2300), atmo dv is really good (2100). I don't have the 1.0.x numbers for Duna, but this should really be enough for one parachute assisted landing followed by a return to orbit. Note: 0.90 atmosphere didn't impact TWR, but 1.0.x does. I'll therefore need to add a column for TWR (atmo). All in all, I'll probably add a body ID selector/lookup table. It doesn't matter in our case because the ratio between vac and atmo Isp gives us a good idea on how the TWR will scale: the 48-7S is a safe atmo bet, the 909 isn't. I can also see that one LV-N would give me almost 4500 dV in vac with quite an acceptable TWR. I could probably go from Kerbin orbit to Ike surface and back with that. The tanks and engines are using lookup IDs from that lookup table (outdated data, my career isn't far enough to need most of these updated). So that's how I do it, it's very rought, and you should add some margin for error. But it does help a lot when designing yet it still leaves a bit of room for the un-expected when flying. As an aside for interplanetary mission planning: Since tug payloads are just dead weight, you can go to the next level and have another spreadsheet with your transfer tugs precomputed dV and TWR that will scale with payload weight: (warning, these numbers are for 0.90) Crude example of N tugs (Nuclear tech) mentionned in this list: PS: Apologies for mixing Weight/Mass and expressing TWR in Kerbin Gs. As well as the poorly formated spreadsheet. I was trying to be practical.

I made my own one as I couldn't find anything like what I wanted, and I'd rather not install a mod for that. I enter wet mass, tanks type and count, and it gives me the deltaV (this way i don't have to measure empty tank weight). It also lists the deltaV for any of the alternative engines, which is a good way to trim down your lander. It won't do multistage, but this is mostly designed for orbital tugs and Landers. While it also displays atmospheric and kerbin TWR, I don't use it for reaching LKO. I've got a a range of launcher that I know can bring xx tons to orbit, and I always refuel up there. I'd encourage you to do it yourself. It's fairly easy (except the boring part of copying all the Isp/mass/tank capacity from the VAB screen), and if you're familiar-ish with Excel (mostly VLOOKUP) you can come up with nice features that suit your specific needs. I'll try to post an image later today.