NathanKell

The RD-180 is used on neither Soyuz (RD-107/108) nor Energia (RD-0120 on the core; the boosters use RD-170s, which are effectively double RD-180s--i.e. exactly the kind of sea level power you're talking about).

Quick note, for the triplets in a DRAG_CUBE, first is area (yep), second is unmodified Cd (yep), third is depth. I.e. looking from that angle, taking the bit of the part nearest you as 0m depth, what is the depth of the widest bit of the part? For a cone, looked at from the tip's side, depth is (height of the cone). Looked at from the base's side, height is 0. Looked at from a side, depth is (radius). Make sense now?

Yep, it's always better to have more...but it's a tradeoff, the ones with better suction have worse supersonic performance. 322997am: that limit is far, far above where your engines cut out, and is therefore not worth worrying about.

In particular, it checks the intake transform for intakes, and it checks that all engine transforms are above water, for engines.

And, in fact, I spent a good few days on that bug, but could not find why it existed, nor could I justify spending probably a week on that single issue. I am sorry you disagree with my prioritization choices.

If you have 'enough' intakes you won't get asymmetric flameouts, because the engines will flame out together due to the flow multiplier being too low, a good bit before the air intakes cease being able to shove enough units at you. If you don't have enough intakes you'll hit that problem above. However, my noting it publicly ought be taken as indication that I'm aware it's a problem.

Yes. Tell me the last time you saw a fighter jet going Mach 4.

Aerobraking at Eve is very possibly. Aerocapturing requires good heat shielding and a high drag-to-mass ratio.

That's not quite correct. Let's quickly review how KSP resources work, and indeed modules on parts. 1. Each frame, all parts are processed in tree order. 2. Each part processes its modules. 3. All resource requests (either pushing or pulling a resource) are first-come-first-served. Now, consider 2 air intakes 2 jet engines If the air intakes produce more air than is required by your two jets, and if there's enough buffer space (as of 1.0.5 there should be, so let's ignore that), then everything's fine. Both intakes add 1 air each, then each jet removes 1 air each, and you're all good. Now consider what happens if each jet still wants 1 air each, but your intakes are only intaking 0.5 air each. Air starts at 0 Intake 1 adds its 0.5 air. There's now 0.5 air. Intake 2 adds its 0.5 air. There's now 1.0 air. Jet 1 pulls its 1 air. There's now 0 air. Jet 2 tries to pull its 1 air, gets nothing. Oh dear. Say the intakes produce 0.75 air each. Jet 1 will fully pull its 1 air, but jet 2 will only get 50% of what it asked for. Now you can see why people mess with order. Let's try interleaving. Intake 1 produces 0.5 air. Jet 1 pulls 1 air but gets only 0.5. It runs at 50% thrust. Intake 2 produces 0.5 air. Jet 2 pulls 1 air but gets only 0.5. It runs at 50% thrust. Hopefully that clarifies the whole mythos of "intakes can only feed one engine" thing.

You understood correctly. Add disableUnderwater = True to all intake and jet MODULEs

Numbers are good Also GoSlash27, I think you'll find that the areas reported by the intakes are sane now, on the tooltips. If not, I must have screwed up a commit. (I.e. area is now actually in m^2, not just 'units')

instead of multFlow, I added separete atmCurveIsp and velCurveIsp curves. So you can model engine fuel flow with density (near linear if normally aspirated, nonlinear if super/turbo-charged) and with ram air on the atm and vel curves, and mach/advance ratio, and density, affect on prop thrust with atm and vel Isp curves. Incidentally you can also model jet Isp shifting with velocity change now (velCurveIsp) if you wish. KSP water has a 1.2x multiplier to buoyancy, so you may find normal-mass-for-their-volume parts a bit light. It's in Physics.cfg of course.

Same with using comma-delimited lists of node types, too.

Correction: Stick it under a PluginData folder and KSP ignores it.

Not sure how you figure 600 km x 6 = 6371 km

Heh, didn't know you did that too. The FXModuleAnimateThrottle has a lot of new modes and hooks though.

"only" 1200K is 1700 degrees Fahrenheit, FYI. Pretty high tolerance I'd say. Airbrake tolerance has been normalized with the other "airliner" wing parts.

Try using wings as hydroplanes. Look at how the Osprey does it.

It's worth noting that despite its looks, you really should think of the Vector as an RD-191 (or RD-253, more like, since Isp for KSP engines is based off storable propellant engines). This is because KSP doesn't really *have* high thrust engines; all its engines are low thrust, so boosted cores make sense. (Compare the thrust ratios of the Kickback to the Vector/Mammoth, when considering whether you're building SLS, or a boosted Mega-Proton.)

nightingale: I specifically warned the CKAN folks to not push that through immediately, because of how deep the code changes in 1.0.5 turned out to be. So blame me not them.

It's now a setting in Physics.cfg

I included pretty much the same workaround this uses.

An updated version is required, and has been released.

Exhaust damage now falls off by the inverse square of the distance. So stuff very near the engine will be cut through, whereas far-away stuff will survive.

Yes. 10char