Plusck

I'm sorry but this really isn't true. It's also not very relevant to the question of arbitration for consumer contracts... What you've been talking about (such as that Article 5 you quoted) are consitutionally protected rights. They exist in all legal systems in one form or another. Often referred to as fundamental rights and freedoms, human rights and so on. It is absolutely not true to say that you don't have these rights if they don't appear in your constitution or some other document. They exist as such. There is a whole slew of philosophies, and especially legal philosophies, that try to provide a logical basis to what most people would call "common sense": the right to breathe, move around, speak to people and so on. The whole issue of "natural law" tries to deal with this, but there are plenty of ways of attacking the logic of each of these philosophies, so there is definitely no consensus there. And that lack of consensus as to how to determine your basic rights is exactly what prompts this sort of consitutional provision: your freedom of movement is desirable; you cannot be certain that future governments won't try to limit it unreasonably based on some odd logic; therefore you enshrine that right in your constitution. There is no way you can claim that enshrined rights exist where others don't (which is basically what your subtractive/additive comparison is saying); however it is certainly true that unenshrined rights can be much more easily taken away from you. And the US is a perfect example of a common law system where the enshrined rights (additive, in your terms) form a huge part of the ordinary non-lawyer person's understanding of his "rights". The first, second, fourth and fifth amendments to the US constitution are constantly mentioned, cited, debated, argued, challenged and asserted by non-lawyery people both inside and outside the US. Still, to get back on topic ... There are two issues to this whole consumer arbitration thing. - conflict of laws: part of "international private law" which is only "international" in that it deals with a domestic legal system's approach to dealing with international subjects. This breaks down into rules on choice of law, and rules on jurisdiction and enforcement. Arbitration comes into it as it can have a complicated relationship with both choice of law and jurisdiction. - unfair contract terms: part of the protective laws of all legal systems, but with vastly differing rules from one system to another. One of the most important questions that runs through both issues is "are you acting in an informed professional capacity?". If yes, then many of the protective provisions in both areas (privilege of jurisdiction, for example, which consumers certainly have, employees may have, and mere citizens of some States may also have) no longer apply. If not, then there are lots of rights that you cannot easily sign away, even if someone clearly tells you that will do so by signing or clicking a link or whatever. So under European Regulations, you can freely choose a foreign law but that will never exclude the "mandatory provisions" of the laws of your place of residence - and protecting consumers from arbitration clauses is one of those mandatory provisions for many countries, including Germany, France and probably the UK). You can give jurisdiction to a foreign court but a non-professional's privilege of suing a professional before his home courts may be protected. You can agree to arbitration after a dispute arises but, in many legal systems, never beforehand if you are a consumer. And purporting to add a clause to a contract with a non-professional that contradicts these rights is, again in many but not necessarily all legal systems, simply null and void. And as the VKI v Amazon case shows, trying to impose your own preferred laws on a European consumer to the exclusion of all others is itself misleading and therefore an unfair contract term. So by doing so, you fail and you also get "misleading consumers" tacked on to your reputation... Incidentally, the New York Convention is fairly irrelevant. Yes, it is the basis by which arbitration as such is recognised internationally as a form of dispute settlement and therefore allows international enforcement... but it cannot affect the question of whether it is even possible for a person to consent to arbitration. In much of Europe (maybe all?), the answer is no, as a consumer you cannot consent to arbitration before the fact, and quite possibly not after the fact either.

Haha, love the idea of forced "arbitration" for forum users. Would I ever accept it? No. Except maybe in China, since China is basically the opposite to everywhere else as far as arbitration is concerned (at least it used to be, basically the opposite of the sort of private arrangement that arbitration is in the west). Not that I'm surprised. It sounds suspiciously similar to the standard NDA that TTI imposes on beta testers. I had to refuse their outrageous demands (arbitration, ownership of every passing thought I might have during the beta-testing period), so I never got to beta test (Not that they actually accepted the modified NDA I sent them, so no I am not bound by it at all... and no, they can't sign it now and claim I'm bound by it: that would be pure fraud). So I feel a bit sorry for all you US users, since you aren't protected by the sort of laws that absolutely prohibit this sort of thing in Europe. I was intrigued to see someone say that TTI's lawyers must be good and wouldn't impose something on its users that would be unenforceable. I have to say that that is a very optimistic view; I'd suspect instead that the lawyers who decided it would be a good idea to draft this sort of mumbo-jumbo were more of the school of thought that says you try to impose endless insane terms because at the end of the day, some of them might stick, and that's a positive result. If it can work in 5% of cases, that's still 5% more than if you didn't try. 5% of utterly undeserved benefits is always better than 0. Still, I'm a bit sad to see where we are now. I first came here and tested the demo because of XKCD. I bought the game because of that certain esprit. I've contributed to the forums and played every version because of it. And now I'm thinking I might just stop checking the forums at all, at all, because I don't want to seem to support money-grabbing, idea-grabbing, jurisdiction-grabbing insanity.

Quite simply, each rocket engine is "sized" for the type of loads that fit its profile. The only real exception is the Vector, which is hugely overpowered (it's heavy, but arguably not heavy enough for what it can do), basically because it's designed to fit as one of 3 on the back of a Shuttle-sized vehicle. Mostly, though, the bigger the engine, the heavier. Also (generally): the bigger, the more efficient. Also, bigger engines generate some electricity, which can be a life-saver, but none of the smaller engines (Terrier and smaller) do. So it makes sense to build bigger rockets, but they become expensive and harder to control. And a bigger rocket in space means a much bigger rocket on the launchpad. The idea is therefore to reduce the size until you start losing more in inefficiency than you're gaining in ease of use and ease of getting the thing into orbit. So if you have 60kN thrust from a Terrier, you can produce 1g of acceleration on 6 tonnes of craft (roughly). Since the Terrier weighs half a tonne already, that means the engine is 1/12th of the total craft mass if you want a TWR of one, under Kerbin's gravity. Since the Mun has a sixth the gravity of Kerbin, then that 6-tonne, one-Terrier craft has a local TWR of 6. That's much more than you need to land comfortably, so you could easily double the size of the craft if you have to, but I wouldn't drop the TWR any further down than that (remember 0.5g acceleration means that you need to burn for 2 minutes to slow down before you hit the ground). That means that on the Mun, a single Terrier can happily carry about 3 or 4 FL-T400 tanks, plus a couple of tonnes of lander can, batteries etc. If you're using a Rockomax X200-16, that's 9 tonnes of fuel tank already, meaning your craft is going to be at the limit of what is comfortable with a single Terrier. Therefore, a single Terrier can feasibly power a 2-man landing craft for the Mun using 2.5m parts... but it's about at the limit. Two Terriers would be much more comfortable. The Poodle, with 250kN thrust, is arguably a bit too much engine for this purpose, but it would give you much more comfort while carrying a very decent fuel load. If you drop down to the Spark, you get 20kN thrust. Therefore a 2-tonne craft for 1g acceleration. The Spark only masses 0.1t, so therefore the engine only counts for 1/20th of the total mass of the vehicle (the Spark is arguably a touch too light, compared to the Terrier, and should instead mass closer to 0.2t). Again, double the mass for 0.5g acceleration, that gives you 4 tonnes to play with. Considering that the lightest 1-man lander can is two thirds of a tonne, you can see that a single Spark is going to be about right for a one-man craft and a reasonable amount of fuel. But again, it's nearing the limit. A pair of Sparks, however, would be perfect for a one-man pod.

Along the bottom, there is a dV symbol (next to the engineer button that turns orange when you have problems). Click on that and switch to vacuum (button on the right). It jumped hugely going from a Terrier to a Spark because the Spark is not all that bad in an atmosphere. The Terrier and the Poodle, on the other hand, are really optimised for vacuum and are next to useless down in the lower atmosphere. It isn't the thrust that changes anything for dV - it's purely the rocket's ISP. From one atmosphere to vacuum, the Spark goes from 270s to 320s ISP. Meanwhile the Terrier goes from 85s to 345s, and the Poodle from 90s to 350s, which is enormous. edit: ok, looks like I'm about 3 posts too late with all this. Dang.

Going from the Mun to Minmus is a bit tricky. It is also extremely slow - you should count on about 8-10 days transit time. In fact, it's very much like a small-scale version of what you'd do to go from Kerbin to Duna, Dres or Jool. You need to leave the Mun's SOI going prograde, while the Mun is about a quarter orbit or so behind Minmus. You eject from the Mun into a broad orbit and catch Minmus on the other side of Kerbin. You'll almost certainly have to drag the manouvre node around the orbit a bit to get the right ejection angle. The way to do it is: Check that Minmus is ahead of the Mun. About a quarter turn should be fine, maybe a bit less, but you can compensate for error by accepting a less efficient trajectory. In any event you are unlikely to get the exact angle, since the Mun moves so much each time you complete an orbit around it, so both your ejection angle and the difference in positions between the Mun and Minmus will vary enormously from one orbit to the next. Set Minmus as target. Drop a node and set it up for a prograde ejection from the Mun to give a resulting orbit remaining within Kerbin's SOI (assuming a standard prograde low orbit, that probably means a node on the far side of the Mun, with roughly a 350m/s burn (pure guess for that number, don't count on it!)). Drop a second node about halfway to Minmus so that you get intercept "close approach" markers. If you need a plane-change correction (and you probably will), add a bit of normal or antinormal to that second node to get a better approach, but don't try to do too much yet. You need to improve the ejection burn first. Go back to your first node, add or subtract prograde and drag it around your orbit until you get a very close approach. If your closest approach has Minmus relatively far ahead of you, you need to either wait an orbit or two around the Mun (since the Mun will be catching up) or you need to head more towards Kerbin so that you dip down and then rise back up to meet Minmus. In the latter case, your ejection burn and your capture burn at Minmus will be higher. If your closest approach has Minmus relatively far behind you, you've left it a bit too late and you'll need to head out away from Kerbin (i.e. you need to drag the node back along the orbit around the Mun) with a significantly harder burn, and a significantly higher capture burn at Minmus. The only advantage is that it'll be a much quicker transfer. Go back to your second node and fine-tune your intercept.

Thanks to @Zhetaan for responding to this. I'd just add that this is 8k vacuum dV we're talking about, and assuming that your choice of engine is an efficient one. Orbital velocity in low Eve orbit is not all that high. I seem to remember it's something like 3500 m/s. Therefore, assuming you "lose" about 2k m/s dV just getting out of the lower atmosphere, and then lose another 1k m/s completing your gravity turn much like you would on Kerbin, then your theoretical dV cost is actually more like 6.5k m/s. However, there is no way to calculate that in stock or with mods like KER, since your ISP is changing dramatically all the way up. You can make a rough guess, for example by setting altitude to 1km and checking the dV numbers for your first stage, then setting altitude at 20km and checking the second stage, etc. You might end up with a number of around 6k dV... or not...

@Foxster beat me to it... but yes, getting the encounter right will make a big difference. The other thing is when you get there. Dres's orbit is not circular. Therefore Dres is going faster in lower orbit around the sun (nearer to Kerbin) and slower at its higher orbit. Since you are approaching from a lower orbit, your ship is going at its slowest when it encounters Dres. Capturing at Dres therefore means speeding up to reduce the difference in velocity (yes, of course you are inside Dres's SOI so therefore your solar orbit is irrelevant... but it comes to the same thing in fact: your Dres-relative velocity on entering Dres's SOI is a function of the difference between your and Dres's orbital velocities around the sun). So the best time to capture cheaply at Dres is when it is furthest from the sun. This rule applies the same way for Eeloo (much cheaper to capture far from the sun), and conversely for Moho (it is lower down than you are, so you are going faster than Moho when you meet it, therefore you want to meet it as close to the sun as possible). If you check Alex Moon's trajectory planner, you'll see that you can leave Dres for a return to Kerbin for about 1300 m/s. It should therefore be perfectly possible to capture at Dres for that exact same amount, at that time.

Definitely follow @Zhetaan's advice: use IJKL/HN translation controls without using "docking mode" which doesn't help. Use SAS stability mode only other than in exceptional cases. In addition to that, the most natural thing (for me anyway) is to use "Locked" view mode. You really get a feel for exactly what your craft is doing, and it also reinforces the link between your movement and the change in position of the icons on the NavBall.

Essentially, yes. Theoretically, there are any number of possible solutions. Practically, though, you need a ship with a minimum vacuum dV of about 8k m/s. And of that, the first 2k m/s or so dV has to be provided by one of only 3 engines that you need to get up to an altitude of about 20km or so: the Aerospike, the Vector or the Mammoth. No other engines provide enough thrust at Eve sea level. If you were to start on a mountain, you might be able to use a Mainsail, Twin Boar, maybe even Thuds on your first stage. Once you get up to about 15 km, atmospheric pressure is about equal to sea level on Kerbin, so you can use any combination of engines that would work there. The trouble is that for efficiency, you really should be continuing to use whatever engines got you up there to start with, or at least a couple of them. Your ship is either truly massive and Mammoth-based, or a cluster of 1.25m cores propelled by a mix of Vectors/Aerospikes. And to get out of the thick lower atmosphere, you need to stay as sleek as possible. Adding wings is probably not a great idea... To get all that down to the surface to start with, you again have any number of options. You can do a powered slow-ish entry into the atmosphere then refuel using drills and ISRU. You might be able to make it down on wings. However, you really need a way to ditch excess weight and drag before trying to make it back up out of the atmosphere. And so, again, your options are limited. I find it hard to imagine a ship that would let you glide and land on wings, and maybe even take off on wings, but let you ditch the wings so you can power out of the lower atmosphere. Similarly, trying to carry drills and ISRU back up to orbit is going to be a huge handicap, so you need to ditch them... and so it would be simpler to start by just landing with a spare fuel tank rather than spending all that effort with mining equipment... So essentially that takes us back to "dropping everything with parachutes"...

That Alex Moon calculator really does work exactly as advertised. You just have to fiddle a bit. This is a sandbox attempt using roughly your date. I get an intercept with a single 1400 m/s burn... Basically, the manouvre node is at about 90°, heading retrograde. You do need a slight normal addition (upwards) because otherwise you cross Kerbin's orbit at the wrong time. That normal addition means that you dip down a bit further than Kerbin's orbit and then meet Kerbin as you are heading back up. This is a bit clearer here: So yes, you can definitely get home on less than 1700 m/s. This is from a 40 km orbit, but with Dres's weak gravity, a higher or lower orbit won't make all that much of a difference. edit: After more fiddling, I got a better intercept with lower dV cost, meeting Kerbin exactly at the right place (at solar Pe), with about 1380 m/s total. Still not perfect compared to the Alex Moon calculator, but close. That "88° to retrograde" angle you are supposed to use is a bit confusing. In any event, as @Reactordrone said, it necessarily has to be almost directly between Dres and the sun since you need to exit almost directly retrograde. As I understand it, "88° to retrograde" means you start at retrograde (with reference to Dres's solar orbit) and count back 88°... And so your exit from Dres's SOI will be heading slightly out and away from the sun. It didn't quite work for me because the closest approach I managed to get was when it was more like 95° to retrograde. Dres is hard.

Do you have the small grey tanks unlocked? If so, the easiest thing is to add a pair of drop tanks. Add a pair of the small decouplers to the top stage, just under the batteries would be fine. Add a pair of those grey tanks, then pile a couple more on top and under those. If you have the small nosecones unlocked, add them top and bottom. Make sure the decouplers are set to stage after your Terrier fires. Enable crossfeed on the decouplers, then check that the fuel priority on the drop tanks is a higher number than the core tank (or use fuel lines if you aren't using advanced tweakables).

The simple answer is: you can't. In the stock game, there is no way to display anything other than the AN/DN of the target orbit. Since you're using KER, you can see all the details of your current orbit using the floating KER window. The longitude of the AN of the orbit is, as I understand it, with reference to the game's absolute coordinates which you cannot see. I'm guessing that there is maybe part of the starscape background that you could identify as the direction of "zero longitude", but I doubt it would really help much. So the only way to do the satellite contracts, as far as I know, is to eyeball it. The tolerances for completing the contracts are generally quite generous. The only real problems people generally have are (a) getting the orbit the wrong way round, and (b) eyeballing the intersect points for solar orbits which are particularly fiddly to view. Still, I'm a bit confused with your image there. I don't see any target orbit... and I don't understand those "fast forward" arrows on Ap/Pe. Is this a mod, and is the contract part of the mod?

As @Aegolius13 says, an alternative to the two lander cans would be a good idea. By far the best solution - from a weight and aerodynamic perspective - is to use a crew cabin (1.25m, 0.5 tonnes per occupant) instead. The disadvantage is that you then have only one way in to the vessel (via the top pod) and will need to shuffle crew around inside and on EVA to get the rescuees in, and you no longer have the lander cans' reaction wheels to help manoeuvering (which also means you absolutely must keep perfect retrograde hold on "surface mode" on re-entry). Agreed also for the asparagus staging: place and stage the boosters in pairs, with fuel lines from the first pair to drop to the second, then from the second to the core. An alternative that might get you further is to replace one pair or both pairs with SRBs. You can still add small fuel tanks to the top and keep the fuel lines, so that when the SRBs are ready to drop, their associated tanks have emptied. It's a bit tricky to time without using mods, but as an example one Reliant will empty one FL-T400 in almost exactly the time it takes for one Hammer to burn out at 95% thrust... Since you have steering fins, you could also get away with replacing the Swivel with a Reliant and an additional small tank on the core. And you could replace those fins with elevons (elevon 1) to reduce the weight a touch. Also there is no need for two struts per booster on that size of craft. I've found that one strut is fine until you get really massive and complicated boosters (or specifically, for inner boosters where they themselves have outer boosters strutted to them).

Yes, starting the burn a little later around would have worked. Still, to get a retrograde orbit you will always have to burn a little harder than to get a prograde orbit. Picture what is happening when you reach the "top" of your orbit around Kerbin. You are far out on an eliptical orbit, so going slowly. If your Ap is slightly closer in to Kerbin than the Mun is (you didn't quite burn hard enough), the Mun comes sailing past above you and picks you up with its gravity. You therefore get dragged in and whipped around behind the Mun... giving a prograde flyby. You then burn against the direction the Mun is dragging you, to circularise into a prograde orbit. If, on the other hand, you burn harder out from Kerbin, so that your Ap is higher than the Mun's orbit, the opposite happens. The Mun comes racing up behind and below you, between your ship and Kerbin. It picks you up and drags you along again, but you've already passed in front of the Mun by the time it arrives. As the Mun drags you behind it, this time you're going clockwise. So yes, you need to start a bit further ahead to get a retrograde intercept, but the most important thing is getting your Ap slightly higher than the Mun to start with. Remember that whatever happens, you will always be going very slowly out there as you approach your Kerbin-relative Ap, so you are basically just waiting around in the right bit of space so that the Mun can swing by and scoop you up the right way.

Meeting something in orbit is actually a lot easier than it looks, especially if you simply use the NavBall and the map. Definitely use the tutorial to get the hang of intercepts. Then, when coming from far outside the orbit of your target craft, just remember that tiny changes at a distance can make a huge change in the time of arrival in orbit. Therefore you can always combine a little prograde/retrograde and a little radial in/out to make sure that you meet the target craft exactly at your Pe as it touches (or, ideally, very very slightly crosses) the target's orbit. Always. If you're having trouble with the tutorial, keep playing with the maneuvre node until it twigs for you. And once you have that intercept set up (to less than 1km, touching or crossing orbits), you can do all of the rest simply with the NavBall and map view without any planning required. You need to know your approximate acceleration. A small craft with a single Terrier probably has an acceleration of around 15-20 m/s2. In the map, click on the intercept chevron to see your "time to". Click on the NavBall to get target mode. Line up with the retrograde vector to target. Check velocity to target, and divide by your acceleration to get maximum burn time to match orbits. Start burning when you're about 2/3 of that time away from intercept (absolute minimum is 1/2 your velocity divided by acceleration, but you want a little room for error and therefore the ability to throttle). While burning, notice how if you aim off to one side of the retrograde vector, it will move away from where you are aiming. Use that "pushing the marble" effect to push the retrograde vector exactly over the anti-target (pink cross) marker. If your intercept was relatively close to start with, it will get closer and closer as you do this. Throttle down if the "time to" countdown stops counting down or slows too much. Stop burning altogether when the intercept chevron starts getting further away from your current location. Just by doing the above, you will perfectly match orbits at maximum efficiency in a minimum of time and effort. You can easily end up dozens of metres from your target at nearly zero difference in velocity with a single burn. Then you can switch to outside view for the docking procedure, which is way harder to start with

Exactly right for landing on the Mun. 3400 to LKO, 860 from LKO to flyby the Mun, 310 to turn a flyby into low orbit around the Mun, then 580 to land. Going home, take it in reverse: 580 to return to low Mun orbit. 310 to turn that orbit into a flyby heading back towards LKO. That's when you can stop using your engines, since you can hit the atmosphere and aerobrake instead. However, the dV map necessarily makes "average use" calls, and Your Mileage May Vary. One of the big YMMVs is the 310 m/s requirement to turn a flyby into a capture around the Mun. As far as I can remember, I've never had to spend 310 getting into low Mun orbit or to return from the Mun. It's more like 280 m/s. On the other hand, it takes a whole lot of skill to get a Mun landing down to 580 m/s: you essentially need to do a picture-perfect, nearly-horizontal suicide burn. The sort of burn that leaves you ramming into the surface at high speed with no possible escape route if you start the burn a touch too late... Averaging out the YMMVs, that does mean that you basically need a total of 6.1k m/s dV to get there and back. While possible (and there are challenges to prove it), that is very much at the extreme limit of what is feasible in career mode without upgrading buildings. It becomes a lot easier if you can start with 2.5m rocket parts to get up to LKO. I've found it easier to divide my rocket designs into two separate parts. "What do I need from LKO?" and "How do I get this to LKO?" For the Mun, therefore, you need about 2.8km/s dV from LKO. That is unfortunate, since the very easy setup is a 1.25m command pod, heatshield with 20% ablator, "400"-sized fuel tank and Terrier engine... which gives around 2.3km/s dV (if I remember correctly). Using the simplest and most obvious upper stage can get you down to the surface of the Mun, but will never get you home. Therefore, the design for doing a full Mun-surface-and-back trip needs a touch more thought. The most obvious is to have drop-tanks on your upper stage. An Apollo-style approach is possible but is actually a lot more complicated (separate lander, docking in low Munar orbit, etc.). Or simply making sure that your lifter stage gets you to orbit with another 500 m/s still in the tanks. The "how to get this to LKO" therefore needs a bigger lifter.. And I think that that's the reason why I always end up building a Mun space station quite early on. After all, the return from the Mun is very minor. Only 300 m/s or so needed. Getting to the Mun isn't a huge problem: 860+300 m/s from LKO to LMO. It's relatively trivial to get a load of fuel into LMO using 2.5m parts. It's the 580m/s x2 for the landing that is the pain, especially if you need to go home using the same ship: it needs to include a heatshield, parachutes, decouplers and whatnot, all of which are sapping away at your fuel economy. So, therefore, the Mun is just a touch too much to do, reasonably, on a single mission without exotic parts. A permanent orbiting station with fuel makes it so very much easier. So, if you want to get multiple Kerbals down to the surface of the Mun, the easiest way is to use 2.5m parts to get a 2.5m fuel tank + docking facilities into low orbit around the Mun, then use a dedicated lightweight lander to get to the surface, and use whatever supply ships you send out there (with heatshields, parachutes etc.) to bring them back home. It's certainly much more complicated than doing a single round trip, but even the simplest round trip requires a degree of over-engineering, so why not...

Absolutely agree! I suppose that I should have been a bit clearer about that "TTA stability" thing. Although I did worry that I'd end up writing too much. Indeed, you can only have engines actually firing all the way to orbit if you have a really low TWR towards the end. Also, getting it so that you're literally firing prograde at full power with a stable TTA of 40 seconds or so all the way to orbit is improbable and actually quite dangerous, since it means that you were very nearly too low and too low-powered to make it! So yes, there's bound to be a fair amount of throttling down in the latter stages, when gravity has very nearly lost the fight but is still hoping to grab you again in a few minutes. Still, if I find that time-to-Ap is increasing much in the middle of the atmosphere, I generally take that as meaning that my mid/upper-stage engines are overpowered, or my gravity turn too slow (trajectory too high) which in turn suggests that my first-stage engines were overpowered.

The optimum trajectory is: as flat as possible. There are only two reasons for it not to be perfectly horizontal on lift-off: you cannot accelerate hard enough to go fast enough to reach orbit before you start falling down to the ground again you cannot get streamlined enough to avoid huge drag losses in the lower atmosphere. The answer to issue 1 is essentially the same as on any airless body: you start going upwards to clear the terrain, then burn as horizontally as possible while maintaining a minimal positive vertical component to your velocity. In other words, head for the horizon on the navball while making sure that the prograde marker stays very slightly above it. The added complication of having an atmosphere is that your ship has drag, and that drag is probably (assuming normal ship design) going to be lowest when you're pointing nose directly forward and engines directly rearward. Therefore your only efficient solution is to be pointing prograde at all times. Drag also affects control over the ship, and you probably also have best control (assuming normal ship design...) when pointing exactly in the direction of travel. And this brings us to neatly to issue 2: you want to get out of the lower atmosphere quickly, while always pointing in the direction of travel (especially while in the lower atmosphere...). Therefore you have to start vertically and make a gradual turn to horizontal as soon as possible but slowly enough to get out of the thick atmosphere. That compromise: "as soon as possible but slowly enough to get out of the thick atmosphere", is your gravity turn. So, the gravity turn has to be: perfectly smooth (therefore minimising drag and control problems), i.e. facing prograde exactly at all times, at full power at all times (otherwise you could use less engines, saving weight), ideally, at lower altitudes, executed at a speed not exceeding the terminal velocity of your ship at that point (since on reaching terminal velocity, drag = 1g, rising exponentially: you'd lose less by climbing for a bit longer rather than trying to climb a bit faster). This is really only an issue for the first few mostly-vertical kilometres. Exactly what the gravity turn looks like will depend on your thrust-to-weight ratio. A high TWR means you reach orbital velocity faster. Therefore the gravity turn has to be finished quicker - which means starting it more agressively off-prograde or launching at less than 90°. Therefore you end up going a lot faster in the lower atmosphere and losing more energy to drag (converted into a lot more heat on your ship's skin). A low TWR means that the gravity turn has to be much more gentle. At the lowest feasible TWR, your gravity turn only comes to an end when you reach orbital altitude: you burn constantly from lift-off to orbit circularisation. You lose less to atmospheric drag and much more to gravity losses. What you lose on fuel, however, you more than make up for on cheaper and lighter engines. And finally, to find that best trajectory, one of the easiest tools to use is available in vanilla via the map: time-to-Ap. On lift-off, time-to-Ap is necessarily zero and rising. It therefore doesnt help much as you try to start your gravity turn right. However, it becomes a very good indicator of efficiency when you're at around 8-12km altitude, 45° inclined to the horizon. At that stage, time-to-Ap should be around 30s or 40s or so, climbing slowly before stabilising, then remaining that way until you're nearly in orbit. The lower your TWR, the higher this number has to be. For a low TWR ship, you need to stabilise at around 50s. For a higher TWR ship, at 40s or less. Maintaining prograde lock and this time-to-Ap should get you very efficiently to orbit. And conversely, if you have a low TWR and time-to-Ap starts falling below about 40s or 35s, you know that you've messed up and are losing vertical speed too fast. It's only recoverable (if at all) by aiming a lot more radially out, meaning a big loss of efficiency.

Well, that's certainly one way of making things difficult for yourself! I personally tend to avoid these contracts because of the potential glitch factor that @Cavscout74 mentioned. Add in the relatively high Moho gravity and the dV requirements of getting there and back to start with, and I'm sure I wouldn't touch it. And I certainly wouldn't rely on my piloting skills to come down exactly on my target. I've done that on Minmus a few times and it was frustrating enough. With Moho's gravity, that gives a huge potential fuel loss just trying to line up. No, I'm sure that I'd use a wheels-based design to move to the target and latch on. Moho's gravity, again, would make me wary of a design that lands on its tail then drops on its belly, leaving a sideways-pointing Klaw. That means the Klaw has to be central and downward-facing at all times. Therefore I'd go for a short, wide and squat design, a klaw under a 2.5m core tank with Aerospikes (probably) on a pair of side stacks (which would also hold rover wheels and docking ports fro driving purposes). Yes, it'll need a burst of the engines to jump on top of its prey, but that's only at the very end. All of the approach would be on wheels.

It's not a bug because it is by definition what SAS is and does. SAS is like using a perfect gyroscope - it always points exactly the same direction, no matter whether you're deep in a planet's gravity well or out in open space. And the trim functions simply don't do anything when SAS is on, because trim alters the position of aeodynamic surfaces, while SAS aims at a given direction. The two functions are simply impossible to reconcile. SAS moves the aerodynamic surfaces for you, and doesn't care much at all where their neutral point is. And since you're travelling around a sphere, SAS can never keep you flying at a given height or on a given heading. Because again, a height or a heading are impossible to reconcile with the "perfect gyroscope fixed direction" that SAS maintains.

Since your TWR is more than high enough to start with, you can easily add small fuel tanks to the top of those SRBs. Either use advanced tweakables or use fuel lines to feed them into the core stack. You might need to offset the SRBs down a bit on their decouplers so that they peel off cleanly without hitting the core stack. If you do that, you can then either (a) reduce the SRBs to two, decrease their thrust a touch, and run the main engine from liftoff. That should already net you a significant dV gain; or (b) place the SRBs in two pairs. Set one pair to about 90% thrust and the other pair to about 60%. Drop the first pair first. Put small fuel tanks on both pairs, making sure the first pair drains first. That lets you run the main engine for far longer before you even touch the fuel in the core stack, and should still keep you at a TWR of at least 2 at all times.

As @Snark says, there is no way to tease out the experiments you want to keep. The solution I use is to plan ahead. If planning ahead is complicated, then try to get every experiment twice (use the "container -> collect all" option on the probe core). Then use an EVA Kerbal to try to store every experiment into the return vehicle, and only then move across to the lab to store all the duplicates there. It certainly isn't ideal. In the best of all worlds, it would be possible to scan through your science reports and "send" the ones you want to a given crewed pod, but this isn't the best of all worlds...

Ah, OK. Still, I can't agree. Getting into any kind of destination-oriented orbit is not simple. I've never really tried for Minmus since it didn't seem worth the effort. On the other hand, I regularly do Moho-oriented orbits because the end result can make a huge difference to the dV budget (a hundred at least and maybe several hundred m/s overall). I've never found it "easy" to get exactly right...

What? No! Really? Changing inclination halfway costs at most dozens of dV, and even if it results in a steeply-angled burn in LMiO to capture into an equatorial orbit, will cost far less than trying to alter an LKO orbit to suit Minmus. Your posts are usually spot-on and correct. What happened here? Yes, definitely. :up: Yes, definitely again :up:

If you're using KER, you can "cheat"* and use the landing countdown to tell you when you absolutely need to burn at full blast. * "cheating" in this context means, basically, having modern navigation and guidance computers on board, giving you a HUD telling you how far you are from the surface and how hard you need to burn to come to a stop in time. "Not cheating" means winging it with a radar altimeter that you have to squint to see at the edge of the screen in cockpit view... On retrograde hold, just start a few seconds early (10-20 seconds early to be sure), and cut the engines as soon as your surface velocity is about 10 m/s. Then slowly ramp up the throttle until the velocity stabilises and starts falling. Keep it at about 10 m/s or so until you're only a few tens of metres high, then increase thrust until you're down to about 5 m/s for a while, then down to about 3 m/s until you touch the surface. Kill the engines immediately. If you're on retrograde hold, you'll never gain horizontal velocity. Rather, you'll constantly reduce your horizontal velocity as you come down. Of course, for this to work properly you really must have thrust aligned with the centre of mass. If they're significantly misaligned (and KER shows this during the build and in the vessel info (thrust offset) during flight) there is a very good chance that the problem gets worse the more fuel you burn, and therefore the closer you are to landing.