NathanKell

That would be because there is a ModuleEngineIgnitor MODULE added, but the per-config settings don't work.

If you use this with 6.4x, you'll get lower shockwave temps as I mentioned (since orbital velocity is a fair bit lower). Whether that makes reentry too easy or not is up to your preference.

Citizen247: edited it for ya.

Um...I think you're thinking of RealFuels, which does all that. SolverEngines isn't a thing to be used alone.

Ven's right.

Um...you do realize that max/min drag numbers have not mattered since .90? That's why KSP doesn't display them ingame.

It's dependent on atmospheric density as well as velocity. 250m/s at sea level is fine, up higher faster is OK, and on Duna very fast indeed is ok. Risky will sometimes work, especially higher up in the atmosphere and/or with drogues.

Devilsgamer666: Nope. blacks: I've been able to reenter spaceplanes, though you have to fly them very carefully (high drag early, then high lift to keep periapsis >70km, keep skipping around the world). That seems only fair, though...they _are_ hard.

No, that means the shockwave temperature will be 6000K at 7.3km/sec. I've tested and reentered just fine with heat shields....

As it happens, there's a bug in the RF I just released where the ignitions isn't properly tech-level-ized if set with the new syntax. I'll fix that, but for now keep using ModuleEngineIgnitor nodes if you want that feature.

There's no toggle for making ignitions always unlimited though, other than a quick MM patch. But yeah, ullage can be toggled. Changelog: v10.4.4 Fix bug where tanks that had flow disabled in partactionmenu were not counted for pressure-fed checks. Fix bug where legacy EI configs were not being applied. Fix issues with fuel ratio for ullage. Show ignitions and pressure-fed-ness in Editor tooltips.

You'll probably want 1 and 1 for the machTemp settings. Also 4 for newtonianBase. Also, you might check out the latest changes in RO to AeroFX.

Changelog v10.1 Actually set atmospheric properties. Update FAR compatibility for atmospheres. Include physics patch on FIRST (will be overridden by anything else) to make reentries survivable etc. Also tunes down AeroFX so ascents don't look so flamey.

RF has the same issue. We'll get it sorted.

Thanks. I'll get it sorted.

Yes, once again I have managed to screw up a RF release. Fixed tho.

Starwaster: RealHeat kinda by definition will be fairly useless for small solar systems unless you modify the resultant shock temperatures somehow--it'll report a shock temperature of only about (velocity) K during Kerbin reentries, indeed somewhat lower until you hit 10km/sec. Later when RealHeat becomes more worthy of the name (by doing what BigFatStupidHead mentions, and by redoing convection in conjunction with FAR), well, that'd be different.

TeeGee: that's not quite right. As I said, RF _is_ backwards compatible with EngineIgnitor configurations done inside ModuleEngineConfig CONFIG nodes. Which RF Stockalike does do. It just has a persistent typo which means they've never worked as such. So no, RF Stockalike does not require an overhaul to make its ignitions and ullage compatible with RF 10.4+; it merely needs the typo corrected, and that typo has nothing to do with changes in RF. Svm420: Generally speaking, by role/era: 1. Early engines have one ignition. 2. Lifter engines have one ignition, unless they're meant to land returning stages (there's no technical reason these days they can't have multiple ignitions, it's cost/mass saying only one). 3. Upper stage engines used as second stages (not for final orbital insertion or BLEO operations) have one igniton. C.f. Titan LR91 or Proton's second stage. But see 2. 4. Upper stage engines used for orbital insertion these days have multiple ignitions. Merlin 1D Vac is an example, as is RL10 or the RD-58 on Blok D. This is because it's often more efficient to make multiple burns to orbit. These engines often also serve for BLEO orbital injection (GTO, trans-lunar, escape) where you want to have a parking orbit first. 5. Orbital maneuvering engines generally have lots of ignitions. By propellant type and cycle: Engines with hypergolic propellants don't have to worry about igniting their propellants in the combustion chamber. Pressure-fed engines don't have to worry about spinning up their turbopumps when there's no combustion going on, they just open the valves. For this reason, most orbital maneuvering engines are pressure-fed hypergolic engines, and pretty much all RCS is either that or pressure-fed monopropellant (needs at most catalyzing)--there's no real difference between, say, the Lunar Module's ascent engine and its RCS other than size and chamber pressure. Engines that don't have hypergolic propellants, even if they're pressure-fed, have to worry about ignition, either a limited supply of hypergolic ignition cartridges, or a spark plug. Engines that are pump-fed have to worry about somehow starting their pumps (which requires starting their generators/preburners) before fuel flow. That's possible, but it's much more complex than "open the valves." tl;dr lifter engines have 1 ignition except in rare cases; upper stages have 1-3 or so, or, if reused as orbital taxis, 3-15. Pressure-fed hypergolic orbital engines often have effectively unlimited ignitions. NOTE: All the above are subject to ullage. It is a myth that Just. Won't. Die. that pressure-fed engines don't have to worry about ullage. They do, except in the rare circumstances where their propellant tanks are small enough (and the need to have them work sans ullaging great enough), like RCS, that there's actually a membrane in the tank to separate the propellant and the pressurant. So yes, the Apollo SPS (and the LMDE and LMAE) were subject to ullage concerns, despite being pressure-fed hypergolics. Their RCS were fed from tanks with membranes, and that's why the RCS didn't have to worry about ullage, not because of pressurization. The differences are: Normal tanks (pressurized to around 2atm): needs ullaging, works only with pump-fed engines Highly-pressurized tanks for pressure-fed engines (much higher pressurization): needs ullaging. Membrane (or surface-tension, another method) tanks with highly-pressurized propellants: small, heavy, but don't have to worry about ullage.

I would think that the name would tell you it's styled after the He 111.... If you want to rescale it, though, you'll need to change scale = x, y, z in the MODEL node (or add that line, if not present). If it already exists, the final values will be x*desiredRescale_in_X, y*...etc. If it doesn't exist, just add scale = desiredRescale_in_X, desired_Rescale_in_Y, desiredRescale_in_Z Then you'll need to apply those desired rescale values in xyz to the first three values for each node_ line (which are x,y,z positions).

Nope! This can peacefully coexist with whatever Starwaster comes out with for KSP 1.0.4. However, this will give you real shock temperatures, which means things will not be very hot at all except in RSS or 10x (or 6.4x, where reentry will be 35% as hot, give or take, as real life). Svm420: this is broadly equivalent to setting machtempscalar to 1 and machtempexponent to 1, for Kerbin reentries. However, it also somewhat increases radiative heat from shockwaves, but not so much as to be noticeable on <10km/sec reentries. Note that this was calibrated using RSS and RO's physics parameters.

It's because stock uses ~Math~ to convert a 3km/sec reentry into the heat of a normal Earth reentry. So if you start making a 5-6km/sec reentry, well, recall that heat transfer scales with the cube of velocity.

Changelog: v10.4.3 Fix an NRE in ullage code in editor. Fix a bug with multFlow not being used correctly.

RealHeat At present a minimalist version of the long-awaited RealHeat by NathanKell and ferram4 This is a simple mod to correct some temperature-related things in KSP's thermal model. Later it will replace things wholesale, building on the work of goozeman and SRFirefox in addition to those above. Features Calculates a shock temperature based on atmospheric composition and velocity. Calculates gamma based on atmospheric composition and velocity. Recalculates background radiation temperature (and the density-based interpolation factor used there and in other things) based on the above. Installation Extract RealHeat folder and ModularFlightIntegrator folders to GameData. Note: Includes and requires ModularFlightIntegrator by sarbian, used under license. Download GitHub License: CC-BY-SA Changelog: v4.3 * Update to KSP 1.1.3 v4.2 * Lower convective coefficient at low density and velocity (we were overestimating convection then). v4.1 * Update for KSP 1.1.2. v4 * Update for KSP 1.1. * Use KSP 1.1 feature of changing convective coefficient rather than shock temp when varying convection behind attached and detached shocks. All these are stated in the cfg for tuning. v3 * Fix an issue with too-high background radiation temperature. This prevents blowups for low-temperature parts, but it may understate radiative heating during lunar-plus reentries. Pending 1.1 for a workaround KSP-side. v2 * Updated to KSP 1.0.5. * Removed AeroFX bits (done by stock now). v1.1 Supports changing aeroFX now. Defaults to making it intense down low, so you can set the normal aeroFX settings to much lower scaling to not have flames on ascent. Supports aeroFXdensityExponent1 (default = 2.0) and aeroFXdensityMult1 default = 90), and the final density passed to aeroFX will be (density^aeroFXdensityExponent1 * aeroFXdensityMult1 + density^PhysicsGlobals.aeroFXDensityExponent) instead of just density^PhysicsGlobals.aeroFXDensityExponent. v1.0 Initial Release

Blacks: No worries, help is always appreciated. Einkleinermensch: Make sure you have the right Kopernicus version for KSP 1.0.2, the current release is for 1.0.4. Also, sadly that's the wrong log file, player.log has more info. In the case of a Kopernicus issue, a zip of the Logs folder (where Kopernicus's logs are) would be good.

Best wishes to you and all.