NathanKell

@danfarnsy et al, if you see a problematic post, report it. The forums are too large to expect moderators to read every post, that's where users come in. In other news, congrats on the release, and many thanks!

Updated to 1.1.3.

ModuleEnginesRF requires an EFFECTS node. You can't use legacy FX with it. Changelog: v11.3.0 Tweak to boiloff and to how conduction is compensated. Slight optimization in the ullage VesselModule. Attempting to add back tweakscale support for ModuleEngineConfigs. Update to KSP 1.1.3.

Updated to KSP 1.1.3.

Updated to 1.1.3.

Yes. And you get said panels at the point you get the Ranger Block I core, so why on earth would you be using an Able guidance ring of all things for a probe? :] (At least use a Delta ring or better yet Agena).

Yep, we either need code to figure out what those state vectors need to be, or we need someone to precompute them (and have a historically-high chance of missing the moon). That's where this whole thing started.

On the contrary, that is 12.6x the requirements of the Early Controllable Core, and even more-x the requirements of the Ranger Block I core. If you try sending things not meant to be probes, you're gonna have a bad time--that's not because the parts are worthless.

@intervenience yes there is a typo in their part.cfg for it, it has path RD0180 and it should be RD180. We will correct that on our side in the next release. @TheEpic presumably you sent an Able avionics unit to the moon. It drains 0.15 EC/sec as its tooltip (in the part list in the VAB) says--150 watts. It is a guidance ring for upper stages, and is not suited for days-long probe missions.

Yes, as the title of the RSS thread says.

@Dman979 yes, PEG is a fine algorithm for achieving a desired first-burn apogee and perigee. However, it does not cover the use of unguided kick stages, it does not handle (AFAIK) coasts to defined points then kicks to finalize orbits, and it _certainly_ does not, AFAIK, cover using that kick to perform a lunar transfer. I mean, the whole point of it is managing things by varying pitch.

Yep, that's messed up...

Hmm, I'm not sure the descriptions say. Good point.

@FullMetalMachinist yup! I did do a bit of replacement in krakensbane and floatingorigin as well to preserve doubles, so drift should be marginally better than it was even without the drift compensation. But yeah, the fact that you couldn't even read what the meters/tens/hundreds places were on orbits masked the drift often enough.

Sounds like your perigee is too high. Try something like -100 for your perigee. -400 will have too high peak heating, but >40km will probably leave you in the upper atmosphere too long soaking up heat without slowing down much. Safe range is probably -150 to 40km for perigee there, and 40km is pushing it.

Sadly RealHeat is Not That Good Yet (tm). RealHeat just changes the shock heat temperature, it otherwise uses stock for computing convection. The shock temperature is calculated by @ferram4's atmospheric modeling (i.e. computing disassociation energies etc, IIRC).

@MatBailie it is a bug in Proc Parts (or RF?) that you are being offered that option at all. Cryo and BalloonCryo unlock with Advanced Construction. If you want low-boiloff tanks until then, use ServiceModule.

@Raptor831 ohhhh right. Weird interpolation. Yeah, that lead to a negative atmospheric pressure in KSP at one point

No, no one said anything about 100km orbits in this regard. What I have said is that when the drift compensation would make things worse rather than better, it automatically disables. Because, and let me repeat this one more time, there are basic, unavoidable limitations in using the integration method PhysX uses, and the floats PhysX uses. We have band-aided it as much as we can, but I dare say if you have survived three years of KSP where this issue was worse, you can survive it when it's better. Since when the drift compensation is off, the application of the force of gravity is exactly the same as it always was.

Now that the 1.1.3 rush (and various setup things on the next round) have passed, time to get this rolling again. The next major things for us to try are desired-orbit satellite launches leading up to, eventually, a moon shot. This requires a fair amount of guidance work, since we will need closed-loop rather than open-loop guidance, and for the moon shot either heavy precalculation (the historic route) or on-the-fly maneuver determination for the injection burn.

@Raptor831 if your thrust curve thrust multiplier goes above 1, you'll need to manually specify the nominal and max chamber temperatures. They are autocalculated by default on the assumption that the engine will never go above 100% flow rate, so if it goes well beyond that, it will overtemp. See https://github.com/KSP-RO/RealismOverhaul/blob/master/GameData/RealismOverhaul/Engine_Configs/Altair_Config.cfg#L33-L35

Even that Bastion of Pedantic Realism, RO, lets you use the thrust limiter on solids.

Work is work. Be proud of yourself.

Yep, broken install. Make sure you're on 1.1.2 and you don't have Tweakscale installed.

It's the wheels. I suggest using the small retractable landing gear, they'll work better, and designing a fair bit more "plane" - you have a very, very minimal plane there and I'm betting it will have a very high takeoff speed. RP-0 recommends B9 Proc Wings (CrzyRndm's fork). Here's some example aircraft you might want to try replicating? They all handle fine. http://imgur.com/a/G6aOo