NathanKell

Step 1: Logs. Can't do nuthin without logs. See: http://forum.kerbalspaceprogram.com/index.php?/topic/83212-how-to-get-support-read-first/

? I was asking if you wanted to help fix it. So far no one has had a chance to.

Nnimrod: Yes, RO itself only has real engines (it's Realism Overhaul after all ) However, feel free to make a small "Speculative Engines" config pack! As to being modeled accurately--uh, kerosene is ~0.82kg/L and LOX is 1.141kg/L. Where/when have you ever seen them have the same density? One liter of anything is one liter of volume, of course, but density determines how much mass of propellant is in one liter. Config help is always needed and always gratefully recieved! rgargente: We're currently waiting on Deadly Reentry to be released before RP-0 for 1.0.5 can come out. Otherwise it's basically ready. If you don't want to wait and/or try preview versions, then yeah, best to go back to 1.0.4. And thanks so much! FélixBachiller: Yes, that's what I mean: KSP supports doing it now, but we have to take advantage of it. We need to make MM patches for the various internals that rescale them at the same level as the external model they're used for (so, for example, 1.6x to the Mk1 Pod IVA). henryasia: Can you post on the CKAN thread or the CKAN repo? That sounds like a weird CKAN issue... oguz: RCS can use one of many different propellant mixtures, just like engines. Once you've placed your RCS part, go to Action Groups Editor mode and select it, then select the mixture you want. Next find (or add) a tank that has a valid crossfeed to the RCS part, and finally fill that tank with the mixture the RCS thruster is set to.

Answered in the RO thread. Please post RO questions in the RO thread, not here.

Yep, if you try a reentry with only 40% of the drag you should have...you're gonna have a bad time. +1 rescaling mafia

Uh...it's just cfg work. Modify a number, start KSP to check, quit, modify again. Simpler even than BBCode, that stuff's complicated! EDIT: Open Real Solar System's launchsites file. Then find your launch site. Then use this handy guide to tell you what things do what. https://github.com/NathanKell/RealSolarSystem/wiki/PQSCity-and-PQSMod_MapDecalTangent

But muh ETHICAL MODDING. Good luck with the crazy times, Chris.

Yeah, I was going by the first method. Mach is indeed calculated that way, each planet has its own molar mass and gamma, and density comes from that and temperature.

Yep, just add gimbalLock = True to the MODULE.

This kinda works: you may have to do a bit of surgery on the node definitions before/after though.

Uh....90 is what introduced "jets draw from all tanks". What's changed in 1.0.5 is that now crossfeed is actually respected, whereas before they drew from literally all tanks. Now you can at least turn crossfeed off for docking ports/decouplers/whatever. Also what changed is that they draw an equal percentage from each tank, rather than an equal amount. In most cases that will lead to balance being preserved, whereas before your CoM could shift a lot before returning to DCoM.

While KSP--like most games--will not support plugging and unplugging devices during gameplay, the bugs regarding starting KSP with/without joysticks plugged in leading to reset settings should be fixed in 1.0.5.

Dynamic pressure doesn't take compressibility effects into account. As to the main issue: It is indeed unintended behavior that parachutes have such a low tolerance on Duna. As mentioned in the dev notes, I'm fixing that for 1.1 (the extra stress from transonic/supersonic should fade out with density, but right now it doesn't). The problem here is that 1.0.5 corrected a different bug (one which allowed chutes to survive when they shouldn't) and that made chute deployment on Duna much nastier.

Well, the spike has a way higher vacuum Isp than the RAPIER, and by 20km you're effectively in vacuum as far as Isp is concerned...

It's in m/s when testing ground and water collisions. The formula is exactly as I stated, since I wrote it. And yes I agree that wakes would be good, and better fx.

Yep, you can do that, or use MM to add a water offset changing module to all parts (will catch all but EVA kerbals). Note only parts with full physics significance will have partbuoyancy (well, will have _working_ partbuoyancy, if it detects no RB on the part it returns, but it may still get added...)

FélixBachiller: Known issue. Before 1.0.5, KSP didn't natively support rescaling IVAs. So the external model got resized, but the IVA did not--so they no longer match up. Now it does, so IVAs can be rescaled. Wanna help?

KSC Switcher is up to date, AFAIK. The launch sites, however, are not. Wanna help fix? (They're far from up to date--the issues with them predate 1.0, probably).

Yes, each PartBuoyancy monobehavior has public double waterLevel which is an offset that that behavior uses when calculating depth. (Note: I never set that value, only read it. But it doesn't pull from anywhere, so you have to set it for each behavior as it comes into being.) As to the pics: amazing work as always, of course.

You probably have to wait a few frames into flight before checking that. IIRC it's set in a coroutine that MTS triggers on its own start.

Interestingly, reentry heating was actually not turned up. What changed was skin->internal conduction, which got turned down, which means you can't soak heat like you used to.

A part breaks when: 1. It is transiting from no water contact at all to some water contact, and 2. speed * Max(dot product of velocity * down axis, 0.1) > crash tolerance * 1.2 Note that both constants are configurable in Physics.cfg. tl;dr max impact speed varies between 1.2 x crash tolerance and 12 x crash tolerance, depending on angle.

Huh. That looks like a bug then.

Just...don't fill the tank all the way with lead?

If the part is stageable, it's even easier, just call OnActive for the module, it's virtual so no reflection needed.