Autochton

Strictly speaking, it's not. It would involve downloading the source code and recompiling it for Win64. If you can do that, you probably also know to not come crying when it breaks horribly on you. If that's too much work for you, well, too bad.

One thing I've thought a little on but which does not seem obvious to me: How does engine exhaust affect wave drag? IRL, I mean, though I wouldn't be surprised if FAR deals well with it. Here's my thought process: Wave drag is caused by air being displaced by the passage of the hull, and the more radically the air displacement takes place, the more drag it produces. Jet and rocket engines emit significant amounts of high-temperature expanding gas in the area behind them - and while that seems like it might not affect a vehicle when the exhaust is at the very rear of the hull, I would expect it to have at least some effect when e.g. engines are mid-hull mounted as you might see in the SKYLON design. I tend to like mounting engines on the sides(/tops/bottoms) of planes, as that brings them in closer to the center of mass, so it sparked a bit of curiosity, but I don't quite know where I'd begin to look for a relative layman's explanation. (I know a fair bit of physics - including thermodynamics - but I'm certainly no aerodynamicist.)

I do... But won't the hottest spot be in the throat of the engine? That's where the pressure and temperature ought to be highest, and where I'd expect the heat glow to be coming from.

In an ideal world, that would be the best solution. However, CKAN already does a truly admirable job managing nearly arbitrary archive formats and configurations, collating it into a form that is relatively uniform to use and making it installable. However, in order to do that, it needs metadata that will tell it how to digest a particular file into something it can install. It's only a computer program after all, it can't follow instructions the same way humans can. And you get a lot of mods that use entirely arbitrary conventions wrt. their download files and where they're installed, what is installed when and how to do it. A great strength of for example npm is that the packaging is relatively uniform - generally you adapt your library to npm,, not the other way around. Here, rather than trying to herd cats until modders can agree on a package format, the attempt was made to adapt to the myriad formats conventions adopted already. It works most of the time, which is nothing short of amazing.

That's fair and all. However, there have also been cases where third-parties have added CKAN manifests for mods, and this has been upsetting and/or disconcerting to the modder making it, or worse, has been done poorly so that the modder has had to field support requests because it did not install the mod correctly. It's one of those situations where it would be ideal if modders came on board of their own accord, but if they choose not to, there's going to be a risk of problems one way or another. Many package managers have faced this and still do - JavaScript development (my profession) has its share, especially given that there are multiple competing package managers of differing features and quality out there (npm, bower, etc.). It does not seem to have a good solution, other than telling people to be polite and to not step on toes.

It's the sort of thing where staying in scope (or even defining scope well) is a bloody trick and a half. I ended up with a document laying out how to refine everything from Martian permafrost and Europan sub-surface water to lunar regolith into everything from liquid hydrogen to bloody UDMH, solid fuel and rocket parts...

I threw around some thoughts about ISRU a while ago, which went nowhere and weren't very focused. However, the always-sharp regex has been working on something, I do believe.

Yes - but changing how? Can I squeeze it into a rounded-corner rectangle? A triangular shape like the one on the SR-71? Can I do this? Last I looked I only had circular cross-sections available.

Now we need a fuselage part mode that allows us to create custom, smooth shapes. Perhaps by setting cross-sections at certain points and interpolating between those. I keep considering what some actual smooth-shaping tools might work like, because even if you go back to WWII, the fuselages weren't straight cylinders. Makes me wish I could find enough time to mod KSP. I consistently can't even find time to develop the games I want to make on my own.

Which is why mixing them is a Thing That Should Never Be Done, yes. AFAIK, nobody has been quite off their rocker enough to try that out. Or maybe they have and the destruction was so total, all evidence of the event was lost.

You might argue that the intake has to be an actual part of the engine itself, given what it does. The length, shape and configuration are part of the 'magic' of it. If any of them diverge even a little from a particular recipe, you've got a non-functional engine.

Hydrolox is highly useful anywhere you have a higher premium on mass than on volume, and need as high an Isp as you can get. Upper stages are a prime example, as Starwaster points out. If you can cool down your tankage, boil-off also becomes a much smaller problem, meaning with precautions it is storable. My personal favorite oh-god-run-away fuel mixture would be pentaborane+FOOF...

Plus, git is a good way to keep your mod files in order and to define releases of it. Once you get used to using it, you'll never want to be without. (I used my first version control system in 2000 (CVS). Since then, being without version control for work more significant than a shopping list makes me feel unsafe. And git just is the best system out there today.)

I vote that you simmer down a bit while the issues get resolved. CKAN remains the one single reliable solution to managing your KSP mods. It is also as much in development as any mod or tool for this game has ever been. Your energy is much better spent helping pjf et al. debug it than on throwing out cranky unproductive comments like this one.

Turbofan engines typically operate in the lower 20 km of the atmosphere. As such, the need for nozzle expansion for altitude compensation is fairly low. Engines built to fly higher than that might well have such a system, however.

Regarding those engine animations, this quote from http://en.wikipedia.org/wiki/Propelling_nozzle may interest you: It seems counterintuitive, but you want the nozzle to contract as throttle increases...

Well, that's right around one of the hardest ways to actually get a thing in orbit, if we stick to those that are actually possible. There's a couple common problems people run up against: Changing center of mass as your fuel gets consumed will pull your thrust vector more and more off center. The real space shuttle solved this by having extreme gimbal range on the pitch axis, but that's hard to do in KSP. Aerodynamic lift etc. will tend to pull you off course, and may even turn the entire vehicle unstable. Getting your COL and COM placed right in comparison to each other is a huge bear, and not one I rightly know the solution for. I would honestly suggest, unless you're deliberately going for the challenge of launching a Space Shuttle like vehicle, that you use for example two or four boosters so that you can center-mount the vehicle.

Hmm. Strictly speaking there's no reason to rear-mount an OMS, other than to protect from the engine exhaust, or to mount a single engine. You just need them to be in line with the CoM on the roll axis, in order to ease maneuvering. So twin engines, mounted out- or inside the turboramjet nacelles, or quad engines over-and-under mounted on the TRJ pods would work well. Alternatively, given that the TRJs are for atmospheric flight, you can aerodynamically compensate for mounting those vertically off-center (esp. given that you need an angle of attack to generate lift), so if you mount the TRJs low and the OMS centerline, each engine should work for its intended regime.

Scramjets are effective from about Mach=5, at a bare minimum - probably more like 6 or 7. With its low TWR and high mass, you're probably better off with a standard or nuclear rocket plus some extra fuel instead of the huge mass a scramjet takes up, for just <2km/s. That also won't need to imply sorcery on the part of the materials tech and massive handwaving wrt. the engine simulation.

And this is precisely why I could change ckan.exe into a Linux executable by two commands: mv Downloads/ckan.exe .local/bin/ckan chmod a+x .local/bin/ckan And done, I now had a ckan executable for Linux. Mac will do exactly the same.

I renamed ckan.exe to ckan and have it in my .local/bin on Linux, doesn't actually cause any pain...

You probably want those closer to the COM than the very tail anyway. Side-mount them.

Ramjets are possible, and are reasonably well understood. Scramjets are primarily made with witchery and dark magics, and anyone who understands them is barred from talking about it by men in black suits with government IDs... As well, they seems to not be all that fantastic, and their operating regime means they'd be no use outside of a Kerbin rescale or RSS game - you'd be in orbit before your scramjets would start being effective.

I think, honestly, the K-cockpit could do with a different designation. Its cross section is decidedly not K, although it only has an adapter to K hulls. Adding an adapter from that cockpit to J hull is definitely a good idea, I think. I'd also like a 'smooth' K-to-J adapter, i.e. without the Mk.2 attachments on the side. And potentially another one with intakes integrated?

I'd suggest making a bicoupler of sorts instead, just a very short fuselage section of the same form factor, with one node on the front that connects to a Mk2.5 fuselage, and two 1.25m nodes behind. Open nodes can occasionally have side effects, in particular in FAR/NEAR where they cause drag.