NathanKell

Aerospikes don't gimbal.

Physicsless is a misnomer, yeah. Now it's "full physics" and "limited physics". In particular PhysicsSignificance=1 (limited physics) parts don't have rigidbodies so don't matter for wobbliness, and have drag and mass added to the parent, but drag is still calculated and mass still matters.

For wings that share the same plane (i.e. all are rotated at the same angle) total lift is proportional, absolutely linearly, to the sum of all the lift ratings. So yes.

What I meant was, can you resume from the backup? I neither have the experience with the contract system's persistence data, nor sadly the time, to try to perform surgery on your save myself. Ah, I see. Yeah, I'll check those out. Felgrrrr

Laie: That would be because KSP loads various files using relative not absolute paths.

They still don't gimbal, though. That's a fairly major issue.

First of all, you may be confusing this mod with the ullage simulation and limited ignitions in RealFuels itself. Second, I agree it's not for everyone, but it certainly does add to the realism factor, and this *is* Realism Overhaul, and Realistic Progression Zero. If it bugs you, though, uninstall it--it's that simple.

Warp11: Thanks! For the LES, replace your existing file with this one (click raw to download): https://github.com/KSP-RO/RealismOverhaul/blob/master/GameData/RealismOverhaul/RO_SuggestedMods/FASA/RO_FASA_Mercury_Pod.cfg For the contracts, I'm not really sure what you'd edit--some of the persistent variables that Contract Configurator reads/writes may be borked. Do you have any backups from earlier in the career? Lilienthal: Awesome! As to reports, they're only flavor text; experiments run fine (and generate science) whether there's local report text or not.

Awesome! Bumped the git issue. You should have gotten a ping.

The tech exists, it's just called Early Capsules. As for the contracts, that sounds like at some point your contracts got very messed up, then. You will probably have to hand-edit your SFS to fix things.

Huh, apparently it's only modifying any existing ones, and FASA no longer has one built in. Fixed.

If you're adding directly to part.skinTemperature, your changes will be overridden in analytic anyway, in 1.0.4. As to RO's changes--we lower conduction and convection values to things closer to real, but that's about it.

Check the existing part configs. some have heatConductivity = (some number) the default is 0.12 Just add that line in the config (or change it, if it exists).

RidingTheFlow: When? Right now. You can change conductivity as much as you like per part. Arugela: As of 1.0, solar radiative heating and convection with an atmosphere whose temperature is based on altitude, latitude, and time in the day/night cycle is modeled.

Fluxes except internal will go to zero in the display during analytic; that's not because they don't matter, but because they're applied differently (i.e. not via integration, and for the whole vessel not per part). Internal flux will still be displayed because the display is reused as the way to track it when modules add it. As to refrigeration: as explained in the dev note about the thermo overhaul, I added an interface to allow people to make them

Ah, I should add to that, that per the dev notes discussion of the overhaul I was making to my old thermo code, analytic will be *much* more configurable now. There's a bunch of interfaces and physics.cfg settings to play with.

Lilienthal is 100% right about the temperature delta (part internal temp - boiling point) being a multiplier to loss rate. If you're cruising at around 100 K above boiling point (about what it is for LOX in LEO) that's a factor of 100 to the stated loss rate. Warp11: They should come back soon. Give it a few days and they should respawn.

Yes, when NathanKell has time. ...sorry guys. :]

Stock engines have the Isp of closed cycle NTO/Aerozine, but about 4x to 6x the mass they should. Stock tanks have about 4-6x the dry mass they should too.

Great!

The glow-on-spawn is a stock bug that's fixed in 1.0.5. OpenGL mode actually saves an incredible amount of RAM. That's because the Unity D3D9 client (for Windows) has a bug where textures, once uploaded to the GPU, aren't actually released from system RAM. Switching to OpenGL client fixes that bug, so you can play with like 5 part packs at 2.5GB usage.

It's not a question of the cables breaking, it's a question of the chute shredding under stress.

So, the analytic model (used at high warp) does model radiation; in fact it's based on radiation quite heavily. At low warp, thermo uses a traditional Euler integrator. At high warp, that would break down badly, so we switch to analytically determining the resting temperature rather than integrating (hence the name). That means we sum up solar radiation, radiation incoming from a nearby planet/moon (reflected solar flux, i.e. via albedo, and then also blackbody radiation), and any internal heating or cooling. That gives us a number in watts that must, by definition, be balanced by outgoing radiation, and using the Stefan Boltzmann law we can then figure out the resting temperature that radiates at that flux. It's absolutely not the case that "tiny levels" of generation cause you to explode--I'd love to see the example config, because it'll mean there's a bug in my code I can fix, unless I've already fixed it for 1.0.5. It's only the case that when the sum total of flux in is greater than what you'd be radiating out at your max skin temperature...*then* things explode.

Yep, Realism Overhaul is being used in some academic work and industry presentations for a "first blush" approximation of things.

I suggest posting on the 64K thread. Sounds like they no longer include the patch to fix that issue.