Starwaster

Atmospheric boundary is at 130km Don't dip below that.

Oooo I didn't realize that was still around. Question though, in the case of RSS, does Real Chute (the KSP plugin) handle non-legacy atmospheres? (I.e. ones with useLegacyAtmosphere = false + pressureCurve data)

chute diameter controls drag. Set up up a chute the way you want using one of the stock real chutes with an eye towards how much mass you want it to put down and how slow you want it at touchdown. (Set up an example craft you want it to be able to handle) when that is set up, copy appropriate parameters to your MOLE chute

Well that does explain how they're able to do their rocket program on the cheap and also why they leave no bodies when they die. (*POOF!*)

That definitely would be a cool addition. And yeah, the thing about orbital mechanics is that it's pretty much guaranteed that you constantly have to have station keeping performed once in awhile. If two objects occupy different spatial positions then their orbits can't be the same so they will drift eventually.

@MonkeyLunch: It should be shielded in there but Deadly Reentry is dependent on FAR (or NEAR) to determine that. DRE's default system relies on raycasting and it's quite possible for the ray to slip between the seams of the fairings. That shouldn't matter with NEAR installed though. Do another reentry with that, then quit the game and find your log file. Put your log file up somewhere that I can download it (dropbox is an easy solution for that if you don't already use it) and post the link. If you're not sure where to find the logs: http://forum.kerbalspaceprogram.com/threads/92229 Edit: Can you post the craft file itself? And the shield itself is Procedural Parts? Edit #2 Also, just to make sure what I said before was clear (which re-reading it when I'm fully awake it might not be). Given that FAR checks are one of the first to be made, anything in the fairing should be shielded regardless of whether DRE thinks it is. If the FAR check fails then DRE falls back onto its default. Edit #3 There's a 10 degree pitch there. I can see you have it set to retrograde orientation but it's having trouble holding that. I'd bet money (if I had any) that the pitch difference is enough that the sides are exposed. If NEAR is not fully shielding the enclosed parts then it falls back to raycasting and it's probably slipping right between the cracks... not much I can do about that except maybe write my own fairing shielding code and using a capsule cast instead of the bounding box. Suggestion: Try that reentry again but with a 45 degree roll angle so that the side of the fairing is definitely between the shockwave and the enclosed parts. (or if that's a 2 piece fairing then make it 90 degrees)

The only downside to them is that they have no builtin fairing, but if you also use use Procedural Fairings then you can use the interstage for that.

Sorry, but no fix will be possible in the foreseeable future as I don't have the original files. All I can offer is a workaround, which is to edit the craft and replace the shield with a fresh one. (don't forget to re-do any Action Group assignments you might have made for the shield) The problem is triggered by inflating the shield in the VAB, afterwhich the animation module gets confused as to its state after it is deflated. Not sure why, I can only speculate that maybe the animation doesn't properly finish. I don't know though. So the original model files have to be edited to fix the problem. A better solution would be to not use it. Use the ADEPT or other inflatables. None of the others that I've seen have this problem.

I dunno, that looks more like 'done deal' than 'may be' To which I can only say It's about freaking time! Thanks Squad. Thanks Max Love you.

Yes, setting minThrust still allows for the engine to be shut off. As long as throttleLocked is not present and True then the rocket can be throttled within its min/max range and shut off. If throttleLocked is present and True then it fires at maximum thrust until fuel is depleted. (throttleLocked + allowShutdown is how SRBs are implemented via the configs)

Bringing zzz's radiator over to Real Fuels is something I've wanted to do for a long time; the configs I created for it have existed for months and have even been posted here and elsewhere several times. Don't think you had anything to do with that. And the deliberate mangling of my own handle is something you've been doing for months so you don't get to complain about 'Northrats'. That was done once as a reminder to you that I might not appreciate it being done to myself and I owe you a metric ton of Northrats for it.

And, sadly, that's part of why I don't consider it to be worth it to pursue the matter. You'd have to devote a good chunk of time vetting the proposal as presented because it can no longer be taken at face value after the fuel tank debacle. (the original principle behind it isn't entirely unsound but the derived application as presented needs serious examination)

This is how the system works. You're at atmospheric pressure 0.5 and you want to know your Isp. The code looks at the atmosphereCurve and finds a key (the pressure) and takes the Isp from that. atmosphereCurve { key = 0 319 key = 1 262 } In this case we have only two keys so it interpolates between 0 and 1 and grabs a value halfway in between. (each entry can take an additonal two parameters besides key/value to control the curve) The code looks something like this: Isp = atmosphereCurve.Evaluate(pressure); You want to control Isp (and therefore thrust)? Then produce configs whose keys go past 1. You can fix this entirely via configs rather than going into the plugin code. If I ignore you, it's because you constantly argue things you know only a little about ("a little knowledge is a dangerous thing") and your arguments consists more of walls of text as though you're trying to drown out the other side. You're also insulting and denigrating and it's not worth it to have to deal with that constantly.

It's not a coding issue. It's an engine configuration issue. Engines cap at 1 atmosphere because they are configured to do so in their engine configurations. Not because there's a coded formula somewhere that needs fixing. The amount of work does not justify the gains Do you have Tweak Scale installed with RF? That's where I think that's coming from.

It's part of the DeadlyReentry.cfg which you don't want to delete the whole thing. Edit it and go all the way to the bottom. It says :NEEDS[RealSolarSystem] I think Edit: @REENTRY_EFFECTS [*]:FOR[DeadlyReentry]:NEEDS[RealSolarSystem] { //@ablationMetric = 0.0016666666666667 @ablationMetric = 0.0015 } So, those who use RealSolarSystem but have configurations that give them smaller than Earth sized kerbin would want to delete it. I'm still working on something that would self scale it so that sizes between Kerbin and Earth would be covered and not require tweaking of or removal of this section. Kerbin / Earth would just be the baseline. One thought I had was to increase the maximum value of ablative and it would be tweakable so that if a player thought they needed more, they could purchase more.

Not that I'm aware of; the large child / small parent issue (really rigidbody mass) is something that I don't think Squad or KJR addressed. I think I even mentioned it once to Ferram because I thought he had fixed it but he indicated that KJR wasn't doing anything about that.... so I don't know. If I'm wrong though I'd love to know about it, or rather I'd love to BE wrong about it. Actually I think I have a rocket that had that same wobble problem with a monstrous first stage.... I could fly it on manual and see for myself if it's more or less wobbly with the larger stage as the root. (or just the same bit of wobbliness)

Something that just occurred to me about changing the root is that aside from the reasons cited by Felger, there's also a long standing Unity bug that it would help. Namely a bug affecting parent / child relations where the child is more massive than the parent results in floppier connections.... I had totally forgotten about that when I watched that video.

The most likely cause of such a problem is design so you should post a screenshot of the craft during reentry from several angles. The issue of reentry effects is not something that can be controlled on a per part basis. KSP handles that entirely and generally if part of the craft has reentry effects then all of it does. (the only exception I've ever seen is if something detached from the ship is occluding it) It doesn't matter because whether a part has reentry effects does not control whether it is taking reentry heating. What controls whether a part is protected is whether or not it can trace a line from its center (actually from its transform) along its velocity vector and be able to hit something within 10 meters. (10 meters is actually horribly generous btw). It doesn't matter if the part that is occluding the first part is part of same ship or not. If it can trace a 10 meter line down its velocity vector and hit something then it is shielded. It doesn't even matter if the occluding part is itself a heat shield, it still protects other parts from reentry heating. (though if it is itself exposed then it will obviously suffer heating) There are two other ways that parts can be considered shielded. You have FAR / NEAR installed and the part has been determined by FAR or NEAR to be shielded by a fairing or cargo bay. So if FAR / NEAR thinks the part is shielded then Deadly Reentry thinks it is shielded. If KSP thinks that a part is shielded from the airstream (literally part.ShieldedFromAirstream) then Deadly Reentry will also treat it as shielded. This is not currently being used by KSP but I included the check in preparation for the future. (my own drag solution, Stock Drag Fix will in the future make use of this property so that cargo bays of space planes where SDF is used will also provide protection)

Then the heat shield will have the wrong metric. Ultimately I need a better system to establish a baseline. Still working on that but the past few days have had me too busy to focus on it.

Ratio in this context is volume. So you need to convert mass ratio of F/O to volume. (Liters in RF /RO) and be yes mass flow will work itself out mostly if you get the right Isp in there. Thrust in the config is vacuum thrust so when working out real world conversions make sure the thrust rating isn't SL. Which for first stage lifters it may well be. (Ie F1 at 33,000 kN being SL)

Oh please, do you think I fell off the turnip truck yesterday? Of COURSE it's because you don't believe me! Felger knows more about it than I do and he has a cool nifty video demonstrating the problem and the effect changing the root has on it. http://forum.kerbalspaceprogram.com/threads/99966-0-90-Realism-Overhaul-7-0-7-2015-032?p=1721842&viewfull=1#post1721842 Ooooo videos! Aaaaahhhh

With very large rockets you get a wobbling that can be eliminated by making the root a part that is closer to your center of mass. Itself a bug that affects both stock SAS and MJ. (the wobbling is caused by excess overcorrection)

Put it up on Dropbox then post the link

No promises, but I think it should be possible to accomplish. I'll look into it. Edit: Ok, good news is that I know exactly what the problem is with the solar panel and it's incredibly easy to fix. The easiest and best fix is to edit the model and flip the sunCatcher transform 180 degrees because BobCat put it in upside down. You could probably even do it by editing the Unity file itself if it were available. (the file you import the model or mesh into and set it up for export to KSP) The bad news is that neither the original model or the unity files containing the transform are available to us and BobCat isn't exactly known for fixing old stuff that he's abandoned. (or even fixing it before abandoning it. Sorry BobCat fans, not trying to be mean but that's how it is) The other good news is that you can replace the mesh = line with a two MODEL nodes; one for the DEMV model and one for a brand new solar panel transform that is right side up. I've tried that and it works just fine. The bad news there is that CleverBobCat plugin stops working, at least the ModuleCleverWheeledVehicle module stops working. And that's the most important part because the DEMV Mk5 is heavily dependent on that file plugin. So the solar panel works but then you can't drive the rover around, and in fact its wheels stick into the terrain and they don't drive or steer or do other rovery things. The only thing I can think of is that ModuleCleverWheeledVehicle has some kind of hard coded dependency on the model / mesh being a certain way. and maybe it can't find it when you do it with MODEL nodes.

You're welcome, but come KSP 1.0 (if they're really going that route next update) you're going find it tougher to go 64 lol