Starwaster

Not possible. If anything, at 400% I'm clearly underestimating you. This is what I suggest to you (because I can safely say that your proposal is NEVER going to be adopted into Real Fuel. It is not sane or realistic) @TANK_DEFINITION [*]:FINAL { @TANK[LqdHydrogen] { %utilization = 4 } } Put that in a .cfg file anywhere in GameData that you like. That should do what you want. Rinse and repeat with other fuel types for TANK

They're procedural fuselage parts. Even if it says fairing in it, it's still just fuselage. You use them if you want to create a plane fuselage that you can cram other parts inside of.

I have had docks working that utilized NODE, but I ended up reverting them to the old attach_node_* system. I forget why.... I think maybe because I needed them to be rescalable and they weren't. (needed 4 different sizes of the same thing) On the subject the control transform, it is optional IF your control vector is the same as the part's transform. (in fact, if controlTransformName is omitted then it defaults to the part's transform). You only have to have a separate control transform if the dock points in a different direction than the part's Y axis.

Timberwind was a very different technology. Particle bed instead of solid core. It also lacked the testing that previous nuclear rocket designs had being a theoretical design. No actual models existed. There is for instance no Timberwind equivalent even of Kiwi. You can't really refer to Timberwind as being a 'later generation NTR' since it existed primarily on paper. I concentrated primarily on translating something into the game that had actual hardware behind it even if we're still lacking actual flight capable product.

I kept clicking 'close' button on the 'screen' in Kujuman's screenshot and it took me a few seconds to realize why it wasn't closing... derrrr

I've even seen it do it later than a minute. I'm not sure but I think it depends on how active you've been. I've had it happen to me even after an hour when I really REALLY wanted the post to stand alone. (it was an important update status for one of my mods)

I think that part of the problem is that prior to DRE destroying chutes, players were not penalized in any way by either stock chutes or Real Chute and could deploy at will even under circumstances that would either melt, burn or shred a real life chute. Most don't understand the limitations involved in slowing something down from supersonic or even hypersonic speeds. DRE really only looks at the temperature side of it, which coincidentally (or not so coincidentally; real life just works that way) happens to come into play when a craft is going subsonic. Other factors that DRE doesn't look at are chute size and material vs load stress. Stupid_Chris has in the past mentioned possibly implementing that in Real Chute. Heaven help people if he does (personally I'd welcome it....)

No idea who this 'Starwasher' person is that people keep seeing. (must be some kind of mass hallucination. Poor devils ) Honestly, I'm not sure right now how to achieve what you're after because there's a certain problem to overcome concerning wings placed in symmetry mode. Is that how your wings are placed? If so, problem: Wings are rotated and not mirrored in symmetry mode. The y vector points up on one side and down on the other. That's why, historically, we deal with wings by giving them 360 degree coverage. (except for certain parts packs where each side is represented by a separate discrete wing part) For those who don't want to get used to how chutes work in real life (i.e. destroyed because they got opened at excessive velocities) there is always the option of opening the DRE settings and then from there accessing the debug menu. Increase the parachute part multiplier. Keep increasing it until it lets you open the chute at a velocity that makes you happy.

I have no such problem with Ascent Guidance. What are your Ascent Autopilot settings at? Maybe you should post a screenshot of it with the ascent path editor open so we can see your settings at a glance. And no, MJ doesn't do anything like that with delta-v

I accidentally managed to repro your problem once. I was manually time-warping while the autopilot was engaged for a rendezvous countdown. Autowarp was off. Next thing there was a bang and the clamps were gone. There's something about it that makes me think they are still there somewhere, maybe as debris in the world. Somewhere. (the planet rotates pretty fast so if they somehow got dephysicalized and unstuck, they could be anywhere...)

If you can repro it, what you can try next is edit Hammaguir's PQSCity entry in LaunchSites.cfg PQSCity { KEYname = KSC latitude = 30.77824 longitude = -3.05377 repositionRadiusOffset = 797 repositionToSphereSurface = false lodvisibleRangeMult = 6 } Increase the value of repositionRadiusOffset until the problem goes away. You could also then do a pull request for the edited file on RSS's github repository. That way the fix could make it into the next update.

On the subject of LES, when I use a tower that has a steering rocket that sends it tumbling, I offset the offset thrust with the small KWR ullage rocket. Start with its nozzle pointing down then angle the top in by two key taps. Works very nicely (as an aside, every LES that I've tried that had a 'steering jet' was doing it wrong. If they put a steering rocket transform in then it has just as much thrust as the other transforms on the part)

0.3 pascals starting at the surface. It has a scale height of 19km. Its atmosphere is more like the tail of a comet and so stretches out away from it, blown by the solar wind. I'd say its atmosphere can't be treated like an ordinary planet except the side facing the sun or out to the sides somewhat. Taken like that, the pressure would fall off considerably, having a pressure of 0.000000000000001 atm ( 1.01325e-10 pascals) at an altitude of 418 km. I don't think you're going to do any aerobraking there. The tail is another matter and falls off less gradually. The tail has higher pressures at higher altitudes than the rest of Pluto. Maybe you could do something with the tail, but I still doubt it. On the subject of aerobraking, hypothetically one would assume that you had a craft there that was designed for it (New Horizons is not, and will be steering clear of any potential hazards if it can) It would be something small like Stardust or Galileo both of which had to withstand enormous g-forces. So, assuming you could find an opportunity for aerobraking at Pluto, it would still be within survivable limits of what we can send.

RSS doesn't look for PQSMod_MapDecal that wasn't in the original planet configuration. It does look for PQSMod_MapDecalTangent..... not sure what the difference is.

What you're not comprehending is that SDF works by adjusting stock drag parameters. MechJeb already knows how much drag the vehicle will undergo because it's the same properties that MechJeb was using before and it's still stock drag. If you're using MechJeb, it already can display drag force. If you don't already have a MJ window that says 'Atmosphere Info' then use the custom window editor (built into MJ) to create one.

What do you expect me to do about it? Why are you posting about MechJeb problems here?

It goes inside a file named OPT_FAR.cfg It's inside the mod's folder. Clarification: Pretty sure he means you to replace the entire contents with his config.

It's based on the part's crashTolerance * (random multiplier based on engine / non-engine) raised to pow of 0.5. The result is added as damage if it's less than the current g-forces experienced. If damage goes over 1 then the part is destroyed. Not entirely realistic but it works. Except that IMO, smaller parts should get a bonus on their g-force tolerance. I don't think something like Stardust would work in KSP. (Stardust experienced peak forces of 34g and was designed to withstand up to 40g)

Now see, that's just not true. I've seen the Exede commercials. Internet from Space is fast! Brian won't let us down.

Did he look like Peter Stormare?

It's not particularly complex and it would less of a dependency than whatever current fuel switching system you have now: Behold! @PART[j_4m_tanks]:NEEDS[ModularFuelTanks] { MODULE { name = ModuleFuelTank volume = 2160 type = default } } Doesn't do anything unless ModularFuelTanks is installed. For Real Fuels it would be @PART[j_4m_tanks]:NEEDS[RealFuels] { MODULE { name = ModuleFuelTank volume = 10800 type = default } } Done. Want to add configs for other parts? Just do it as above with the part name in the brackets. Volume is stock volume unless it's for Real Fuels in which case it's stock volume * 5 Done.

It's more unusual that the quads aren't burning up. None of those RCS ports are shielded. If they are exposed to the airstream then they can burn up. Same for the hullcams I suppose, but I'm not familiar with those parts. But DRE doesn't do anything in particular with them. What Taniwha said, but also, the inflatable isn't just a high drag part, it's also very lightweight. Changes have been made to it over the past year, but the last few KSP updates seem to have made it harder to keep stable. I notice that you are not running the latest version of DRE. Even if you don't want to update, you should still grab the part config file for the inflatable. It might help a little. (I moved its CoM back a bit, which should move its Unity rigidbody back as well.. That in turn moves the drag point closer to the rest of the vehicle. Not that will help that particular design though) In fact, grab these three files: (the second two take the place of the existing DeadlyReentry.cfg file) inflatable heat shield part.cfg (replaces DeadlyReentry/Parts/deadlyReentry_6.25Heatshield/part.cfg) DeadlyReentry.cfg (replaces DeadlyReentry/DeadlyReentry.cfg) DefaultSettings.cfg (goes in DeadlyReentry) So, the result of that will be to add lead ballast to the inflatable shield. By default it will have 0 ballast. Try adding some and see if that stabilizes things a little. No guarantees; it's experimental. The inflatable has long been a thorn in my side and probably will still be one for awhile to come

This calls for that crown meme thing... KEEP CALM AND BACON!!!

The panels rely on raycasting to see if they have a clear path to the sun or not. Historically, for reasons that are still not entirely clear to me, raycasting to detect the fairings frequently meets with failure. Deadly Reentry has this problem a lot. The frontal curved part of the fairing is least likely to be detected by a raycast. Probably an issue with the colliders, which AFAIK are what actually get detected. AFAIK. Raycasting will also fail if the ray passes between the seam where two fairings meet. That's pretty much inevitable as the ray has no width. I wonder if layers could be an issue too... e-dog, if you see this, what layer are the fairings set to? Anything non-standard for a physicalized object?

Sorry, you're right: I don't agree that making that change is for the best. That solution would force everyone to have to use the offset tool to move the shield back into position regardless of whether they themselves were having trouble with it.