Starwaster

Ok, you don't have the most recent version like I said earlier (I added that as an edit so maybe you didn't see it) https://github.com/Starwaster/DeadlyReentry/releases/latest

Make sure your KSP installation doesn't live in Program Files or Program Files (x86) Other than that, no, nobody has any idea why your MechJeb isn't loading and you should supply logs and any information that might be relevant.

Ok, back to the Eve issue, is that 2.5t landing mass? What are you putting down that is weighs so much? I think going with the larger heat shield is the way to go since it increases your drag and that's what you're going to need for something that large. The inflatable would be even better but you DEFINITELY will need a shallow reentry for that. If you have thermal debugging turned on then you will see that each part is given a heating rate/cm2. Keep the inflatable at 15-20W /cm2 If you have to have the ablative shield (is it career? inflatable not available yet?) then go with the 2.5m shield and make it steeper not shallower.

Well, that's pretty vague. Why don't you tell US why it can't dock? Give a more detailed explanation of the problem.

It's going to deviate anyway. The 'correction' only represents a small measure of additional accuracy and can put every planet and their moons out of phase with physical objects in space around them. Edit: And oh look! It also affects other mods/tools that we use So what's really gained here? It doesn't seem like anyone has compared that to what's being lost. You can't just think about our own reality, you have to consider the reality created within the game itself and by all the many different mods and tools interacting with each other.

As you say, it makes sense if they are moving around their common center of mass, which is not possible for them to do in KSP. All I can see this doing is creating a difference in physics between the planets and physical objects such as ships. It CAN be disabled though. Each body configuration has a finalizeOrbit field. Set it to false and they behave as in stock. It can even be done with a Module Manager patch

That's why I made the recommendation to include basemass = -1

I need the full log. Please zip it up and put it somewhere I can download it, such as Dropbox. (preferably Dropbox) Actually, first make sure to download the latest version as there is an update for which the first post has not been edited: https://github.com/Starwaster/DeadlyReentry/releases/latest

Append :FIRST @PART[somePartName]:HAS[some-has-stuff]:FIRST { <config stuff> } I think also that if you don't schedule the patch that it schedules it even further, in the LEGACY pass. Order of execution is: :LEGACY :FIRST (some-mod-name) :BEFORE[some-mod-name] :FOR[some-mod-name] :AFTER[some-mod-name] (some-mod-name finished its patches, rinse and repeat for the next mod being patched) :FINAL

I feel bad about this but I forgot about something when I was composing my post: My most commonly used heatshield is the one from the SDHI mod which by the author's design is supposed to be more resilient (given that he was modeling it after the PICA shields which are supposed to be reusable). I use the SDHI shield mainly because it fits the SDHI service module snugly. The stock one clips. So I did a quick run with the stock shield and at 20 pe, on a 2.5m pod I end up with 168 ablator left. I don't find the orbit I'm returning form to have much impact because coming in faster means generating more drag. The temperature is higher but so is the drag (velocity squared). The Minmus reentry left me with 140 ablator left. I'l comment on Eve later About spaceplanes: essentially correct. DRE remodels spaceplanes to mimic shuttle tiles as best as I could. The skin of each spaceplane part is configured to hold very little heat, and very low conductivity to the interior of the part. They have high emission to help them re-radiate the heat that they absorb. (this is in contrast to the stock parts which increase thermal mass so they store more heat). The skin-skin conductivity is INCREASED to try to evenly distribute the heat to adjacent parts. The shuttle came in at a high pitch to maximize drag, which also served to reduce heating due to the blunt body principle.

Some of them are still twitching!

I think you can move a little beyond suspicion on that. Vessels only use their reference body to determine their orbits and gravitational influence. The question is, is it really worth it to use a method like that when vessels still are affected by stock?

Not every file is going to change in every release. The release page on the Github repository has the changes enumerated in a fair amount of detail.

so that's a ~4 hour difference in orbital periods... maybe a rounding issue or floats vs doubles issue? Vessels usually handle velocity as a double.... maybe we need to check what orbits are using in RSS Clarification: What I mean is that if something is being cast to a float somewhere between the orbital configuration and the actual orbits being determined in the game then that could throw things off. I don't know if it would amount to a four hour difference or not...

My memory is a bit hazy on this, but aren't there some circumstances where if there's a problem with the hatch transform it places EVA Kerbals somewhere else?

@Sippitous Let me also add: I maintain a list of tweaks to the game in a 'zzzMyTweaks' folder. I copy it to every new installation when the game is updated. So my changes always follow me and I don't have to remember what changes I have to re-create. The tweaks are a collection of Module Manager patches Edit: Prepending zzz is a recent change. Some modders make use of the keyword :FINAL in MM patches which usually should only be done by the player as that is the only way they can ensure that their changes come last and are not overridden. So that helps me ensure my folder is processed last.

Never rename a folder unless you created it or know what the effects are. The configs in that folder may contain references to the folder by name. e.g. MODEL { model = Squad/Parts/Engine/miniJet/SmallJet } That tells the part config where to find the model(s) for that part. That will prevent the part from compiling and it will no longer be listed in the parts list. And Galileo's advice (as you noted) is correct.

The temperature of the reentry shockwave is based on velocity cubed. How much of that heat is transferred to your craft is a function of atmospheric density. Assuming a simple craft like a pod + heat shield, the optimal periapsis is 20km. As to shallow vs steep, there's a bit of a corridor where it's possible to go either too shallow or too steep. Too steep can have one of two effects: Either parts of your craft (or the whole craft) burn up because you didn't slow down enough before hitting the denser parts of the atmosphere where you're getting maximal amounts of heat and your shield is overwhelmed. OR you suffer enough g-forces to render your crew unconscious or kill them outright. (crew blackout is handled by stock, not DRE. g-force related death is DRE, not stock). If you go too shallow, it is possible to cook off too much of your shield so you wont have any shielding when you descend at high speed into the lower part of the atmosphere. Or you can be so shallow that you don't brake enough and fly back out of the atmosphere or fail to capture on an aerocapture. Stock radiators are not effective in reentry as they will not cool any part unless that part is hotter than the external temperature. Ablative heat shields start ablating at 500k. The ablated material removes heat from the shield. The faster it ablates, the faster heat is removed. Contrary to what some people believe, heat shields do have limits even in real life though the mechanism of failure differs from real life. In Deadly Reentry, heat shields that run out of ablator have a reduced maxTemp, which is probably why your shield is exploding as soon as its ablator is depleted. Spaceplanes: You didn't say what your altitude was nor did you say if you were cruising or reentering and it matters. It would be highly unrealistic to be able to fly a plane much faster than Mach 3.5. Only the SR71 has ever flown that fast and that's faster than its operational speed of Mach 3.2. They were allowed to push it higher and its official max speed was 3.3 though 3.5 is its record. The shuttle on the other hand came in at Mach 25 but that was a shallow reentry. With stock Kerbin you will be coming in MUCH slower than Mach 25. I don't personally do spaceplanes that much but IIRC, the right periapsis was something like 40-50 km. You will want a pitch angle of about 35-40 degrees. (I will also mention here that with stock Mk3 parts I have survived RSS reentries. i.e. a full Mach 25 reentry so it is possible, at least with the RO physics configs to scale convection heating down to Earth reentries) Eve: For capsules, I think I used 40-60. I don't remember the exact periapsis/angle I used but it's not hard at all. Make that dense atmosphere work FOR you not AGAINST you. Do as much braking in the upper atmosphere as possible. If you use the inflatable shield, you want your altitude even higher as is basically heat resistant cloth. The point of the inflatable is to increase your surface area which means more drag which means more braking higher up. Remember, I'm the current developer of DRE. I use the same DRE you guys have . My thermal settings are pretty typical for stock except that I often lower my conduction to RO levels so I can test Real Fuels boiloff. The effect that has on reentries actually makes them hotter and I still survive just fine. (makes them hotter because the skin can't conduct its heat as quickly into the interior) One last thing about you running out of ablator. Sounds like TOO shallow and baking it off. I said that earlier but just to revisit that, a typical reentry should only use about 25-35%. (maybe less on a suborbital. Mun or Minmus would use more but you should still have plenty. And I NEVER turn the difficulty slider below %100. I might raise it but never lower it.

You don't say HOW you made those changes (i.e. direct editing, which is a no-no or Module Manager patch) but it sounds like your changes were not syntactically correct and corrupted the configs such that they wouldn't compile properly Without logs from you and a ModuleManager.ConfigCache file, that's only speculation on my part. (a missing ModuleManager.ConfigCache is a dead giveaway that any patches you attempted corrupted the configs, preventing MM from patching) (and, if we are talking about Module Manager patches then you should take that discussion to the MM thread)

You will not regret it.

Real Fuel's boiloff works with the stock thermal system so you can adjust it using the stock thermal physics sliders. Between adjusting radiation and conductivity you can do whatever you want to it. I don't use the 3rd party parts (graphene radiators or 3rd party tanks) that you mention and have no idea how they are configured. To reduce or eliminate boiloff in Real Fuels requires both passive (tanks properly configured to insulate) and active (either stock radiators or the mod Heat Pumps which was designed specifically for Real Fuels) The CryoTanks mod might SAY they are insulated and designed for cryogenic fuels but that means nothing if they are not properly configured for Real Fuels cryogenic tank support. Simple Boiloff uses entirely arbitrary rates and is not governed by temperature or heat flux or any realistic physics. It has nothing to do with anything that happens in Real Fuels.

Also constant crossposting in multiple threads isn't helpful, it only confuses the issue. Bringing up multiple different issues also muddles the current issue. You have to focus on one thing at a time and not jump around. I don't even remember what thing is really giving you trouble anymore.

I was very specific as to WHY I told you that you should remove simple boiloff and it was because it duplicated (poorly) functionality that Real Fuels already has and there's no reason for you to keep it around adding another source of boiloff. It wasn't a troubleshooting step.

Did you install Procedural Parts?