Foxster

Umm, SSTO's are low cost (just the fuel) but they are rather payload limited, unless you go huge and that has it's challenges. A rocket is probably going to be your best bet. To save cost you could have a cheap disposable solid fuel first stage and a LF/O second stage that you either fly or parachute for recovery. What mass of payload are you thinking of?

Nope, not fixed in 1.4.2. Try it. Turn on aero data in Alt-F12, launch a craft and check out the drag of the fairing and the part beneath it.

Because fairings are currently bugged so they have zero drag themselves but the part right beneath them has massive drag, making them pretty useless at the moment.

"Actually" they aren't anything (just bits in a game) or they are whatever you want them to be. My guess is that they are pixie dust, fairy flakes and snot.

That's it really. The bounds of a FL-A150 adapter (a FL-A151S works too), a KV capsule and a size 1.5 tank all match. This means you can reduce the drag of a KV capsule at mach1+ in Kerbin's atmosphere from ~200 down to ~10. Looks rubbish but it works. You can improve the looks by offsetting the adapter down...

It's because it introduces a lot of drag at the front end that is well ahead of the centre of mass. The two things to be done are to get the CoM down near the heatshield and to get more drag at the back end. Common things implemented for Eve are to put one of more inflatable heat shields at the back of the craft to act as a kind of sea anchor. Personally, I prefer to attach a lot of disposable air brakes there. Just position them so they are within the heat occlusion cylinder area extending behind the heatshield.

There's obviously a lot of excellent work that went into MH but I consider it a failure. Here's why I think this... The whole challenge system was based on an incorrect assumption: That many players wanted to spend time a lot of time making challenges and that other players wanted to play these challenges. It's true that there was a small and regular group of players taking part in the written challenges that players set on this forum, but this is a small percentage of the playerbase. Most other players seemingly engaged in their career game, or building SSTOs, or designing aircraft, or planning a sandbox mission to Eve and back. I see little sign of this changing with the arrival of MH; people are happily continuing doing the same as before rather than using the MH challenge system, just being somewhat fed-up with the bugs introduced and the mods outdated. What would have been better is integration with the main game. The challenge system would have made an excellent contract design tool, especially with the addition of allowing contracts to be completed in sandbox and science modes. This would have made the functionality of interest to a much wider audience. The ability to deploy a launchsite on other bodies in sandbox and late career games would have been appreciated by many too. To pick challenges as the thing to give KSP players just seems odd. There has been many enhancement suggestions over the years but never this. For a much simpler DLC, another bunch of planets and the parts to reach them would have been easy to do and appreciated by many. A bigger challenge, but something that would have been very well received, would have been the much-asked-for multiplayer mode of some kind. Then there are the new parts: Another miss. There is nothing new or particulalrly useful in the parts. The engines are meh and don't fill any new niche, like an expansion to the groups of solid, LF, LF+O, nuke and ion. More nuke and ion engines would have been enjoyed by many. Many of the new and altered parts are buggy, with off-centre thrust or mass, broken drag properties, poor visuals, etc. The new capsules are meh too. The LEM-alike capsule is very un-Kerbal and should have been implemented as a set of parts. The KV capsules look half-finished and have little practical use. The new tanks are just more tanks but lacking the adapters that the other sizes have. It is now very difficult to tell the tank diameter and volume in the parts list because all the pictures are similar. Without reading the description (and even then the diameter is not stated) it's not possible to tell from the parts list whether a tall tank is 360, 810, 2880 or 23040 units of LF. So, considering all the effort that went into launching KSP into the DLC world, MH/1.4 delivered very little that has been well received. A missed opportunity.

You get a zoomable orbital view of the body you want to place the launchpad on. It's not hard to pick an interesting spot. It looks to me as though anything to do with career is not available, which makes sense as there is no integration.

They are pretty useless. Like most of 1.4.

It is two steps forward and one back. Or maybe the other way around. Quite a lot of show-stopper bugs for you to spot soon.

Dunno. I'll look for it in the bug tracker and add it if its not there. Oddly the fairing itself has zero drag but the part below it has enormous drag as though the drag of all the shielded parts was added to it. Update: Its already in the bug tracker with a status of "Being worked on".

Just found that there is a fairing bug in 1.4.2 that won't be helping Eve craft. The part mounted immediately below the fairing will have enormous drag. |n my craft above that worked fine in 1.3, the drag of the tank just below the fairing gets into the 100s. This means the craft won't make orbit. I'm playing with parts to see if there's an alternative but it might be a matter of waiting for a bug fix.

With some precise flying and a very low drag craft it is quite possible to make Eve orbit with <6000 dV from sea level. It can't be done though with most people's craft and with MJ or best-guess flight profiles. It can be done manually with care and I have also managed to automate it using the GravityTurn mod. The "secrets" are: Reduce drag losses to the absolute minimum through the use of a small number of thin stacks, eliminating everything possible. Control the throttle very carefully to limit Q to no more than about 220,000pa. My craft above uses full throttle for only the first few km and then is throttled back to 1/4-1/3 throttle until Q drops. AoA needs to be tightly controlled. You need it zero all the time except whilst making the initial gravity turn. The altitude you start your gravity turn is critical, typically around 4km from a sea level launch. No two craft (or variants of the same craft) will have the same flight profile to orbit. You will need to be prepared to experiment with the Q limit, gravity turn start altitude, and the pitch of your initial turn. Getting this right makes the difference between getting to orbit or coming up 1000dv short. My craft above is at the bleeding edge of what is possible, it was built and flown for a challenge. It shows what can be done if you are prepared to spend hours tweaking the design and then the matching flight profile. It is not for everyone, with most preferring to build something that is a lot easier to fly. However, it does demonstrate the principles of low weight and low dV craft on Eve. Using similar principles you can make a craft weighing ~50-60t that is relatively easy to get to orbit.

That craft is rather over-engineered. The biggest battle on Eve is with drag. You will lose loads of dV for every bump, over-sized tank, stack, sepratron, fin, engine, strut and whatever else you bolt on in effort to get the dV numbers up. That leads to the craft ballooning. Whereas the way to go is take stuff away. This 25t stock craft can lift 4 Kerbals in chairs inside the fairing to Eve orbit from sea level...

What's your payload i.e. exactly what is the craft trying to put into Eve orbit?

It might move up if you add it to the bug tracker

Yup. Now they appear in the SPH regardless of the setting.

No air-breathing engines on the craft?

This is something that businesses have been using for a long time to improve the performance of client-server applications i.e. those with a local PC app running the graphics side of things and a remote server handling the shared database. Their downside being that you need to maintain the client application on a 100s or 1000s of remote PCs and there needs to be a low-lag, high-bandwidth connection to handle the data passed between client and server. That's where software like Citrix comes in. You install your applications on high-spec PC servers physically close to the database servers. Each PC server runs several virtual PC machines. This makes it easy to control software installation, and the bandwidth between the PC servers and the database server can be virtually lag-free, typically being on the same fibre LAN. The user-end software is just a generic thin client app that is like a remote desktop or screen-scrape of the PC server. This client can be installed on a PC, Mac, browser, Android, etc i.e. you get user-end OS independence. The network requirements and lag-dependency are much lower for the thin client to PC server than for the PC server to database server. These systems have been really effective for businesses. They save huge client distribution and maintenance costs, drastically reduce network requirements and lag dependency, and generally speed up how apps run. Enter gaming. MMOs have all the same issues: A client has to be installed and run on a load of disparate machines, over a huge variety of network speeds. If instead the game's client is installed on some high spec and tightly maintained servers that are next to the game backend servers then lots of the installation, patching and performance issues disappear. The gamer just installs a generic thin client on just about any machine, with wet string for an internet connection, and they get very good performance from the game. It really is an excellent idea for games and has been a long time in coming. (PS: I imagine that the gamer would not be given access to the virtual machine's OS, only to the pre-installed game application. This means everyone gets the same game application to play (reducing cheating) but does mean that only approved (or no) mods would be available).

Not for me, and I suspect plenty of others. It might do for you because of your knowledge of the parts' internals. In my example above, I see the first engine with a nice clean transition to the tank, same with the last one, and I'd expect these to be low drag. The middle one looks mismatched and I'd expect it to be draggy. That also happens to be how non-variant parts work. So we now apparently have two different ways of figuring out if an engine/tank combo is going to be draggy: If its a non-variant part then we just match the part sizes. If it's a variant part then we apply some different esoteric rules.

Not sure I got all that but I'll take your word for it. Doesn't mean diddly-squat though for most folks assembling a craft. I mean, it seems nonsensical to have to go into the part config files to get some numbers and then turn on a debug option to get some more and then compare them just to get the same results we get by eye-balling the non-variant parts.

I've never heard of the penultimate and last parts behaving so as to reduce drag (unless size-matched). I thought there was one "rule" for all parts in a stack, except that the last part would be more draggy because of it's blunt rear end (unless its not an engine and you taper it). I could easily be wrong though - KSP's aero model is weird.

Yup, but KSP's simple aero model, which has no real aero occlusion, relies on matching same part sizes to determine whether adjacent parts have a low drag buff; a bigger forward part does not reduce the drag of a smaller rear attached part. So we need to know what parts are the same size drag-wise so we can match them. You could do this with all node-attached pre-1.4 parts but you can't now with the "variant" parts because there's no way in the VAB/SPH to tell just what size the variants are considered to be by KSP. Their visual appearance is misleading as I showed above and the variants' names are meaningless.

Nope. I just can't let it lie. Look at the two variants of the Skiff... That's a Shrouded variant (where's the shroud?) on the left and Bare variants in the centre and on the right. Now, if I was going to guess I'd say the drag would be low on the left and right engines when attached to those tanks because the sizes match, and the middle one will be more draggy because there's obviously a size mismatch, right? Wrong... The left one has a zero YP as anticipated but then so does the middle one, despite looking like a complete mismatch. The right one, that looks as though it's a good fit to it's tank, has a positive YP, so it doesn't really fit as well as it looks. Where's the logic?

OK. I've finally got it... It's just me, I'm weird and can see a problem that no one else does. Fine. Moving on...