Starwaster

lossExp -6000 shouldn't be in any Deadly Reentry config file. I used that a few times in the spreadsheet because I was testing different values there. But not in the actual config files in the release.

Yes, it's calibrated for x10 You're probably just better off with that patch I provided. Or at least that would be easiest. The formula that uses those fields is a little convoluted to use. I used a spreadsheet as an aid. I opened it up to viewing and copying: https://docs.google.com/spreadsheets/d/1_1LCCm7O5Yp8sdgU-GxlKre-iSjHs_B0AiO5bcy0gwA/edit?usp=sharing (stay in the M column for starters) Basically though, the formula is loss = lossConst * EXP(lossExp / skinTemperature) That's how much shield is consumed per second at skinTemperature. (in the VAB, infoTemp is used instead which is 2400 by default. It should be set to a typical reentry temperature for your system's scale. Assume temp Kelvin = velocity in meters per second, so set infoTemp to that value for what gets displayed in the VAB. It won't affect flight scene at all) So, the game uses that loss to determine how much flux to remove from the shield flux = loss * density * pyrolysisLossFactor * specific heat of ablator This is all from the stock ModuleAblator which is the parent of ModuleHeatShield. maxAmount of the ablator resource factors in there but I forget how. Understand that I'm largely going by memory. The spreadsheet is accurate though in how the formula is used. Ignore that loss is used as a label 3x, that was just to get loss to something I could use to calculate flux.

Same issue as above. MechJeb might be mentioned but it's not the mod that is logging that. [PR] would be Persistent Rotation, logging about its MechJeb wrappers. (wrapper functions so that it can call MJ functions) So, there's nothing in your log file that really implicates MJ. Might not even be Persistent Rotation. The log spam is a bit excessive and should be toned down, but it's not an error. If you look in %localappdata%low\Squad\Kerbal Space Program, you'll find logs relating specifically to your crashes. They should have some more information extending past the ksp.log files as well as information about the crash itself. It might help or it might not if the crash is some generic error. (just paste %localappdata%low\Squad\Kerbal Space Program into your Explorer URL bar) (you should post THAT log in the thread you referenced, not here. There's really no indication in your log of MJ being at fault)

Unfortunately, what's probably needed here is a config that dynamically adjusts to rescaled systems, instead of a one size fits all solution. It's something that I've wanted to do for awhile but have never gotten around to it. (basically check what the home planet has been rescaled to and do a little math and figure out how much to adjust the heat shield based on the difference between stock Kerbin and the rescaled Kerbin) So, what's happening is this: An assumption is being made that your system is being rescaled bigger than it really is. ALSO, a realism factor is being applied to the ablation rate because in real life, a heat shield ablates a mere fraction of its total amount than would happen in stock KSP. In stock KSP, I'm still trying to capture the basic essence of your ablator being sucked nearly dry. But IRL, an Apollo heat shield only ablated (IIRC) only 10%-ish of its total amount. (Because, overengineering) The greatest heat loading ever experienced by a heat shield was by the Galileo Jupiter Atmospheric Probe which ablated something like 50% of its heatshield. (might have been more/less, going by memory) The easiest solution for you here is to use the Deadly Reentry menu to crank up reentry heating. (there's one in the stock KSP menus but it's clamped to 200%. The DR one overrides the KSP one and goes a lot higher) That solution, while being easiest to execute will affect everything even supersonic aircraft, so you could instead use an MM config to make the ablation rate faster. The following will double all heatshield consumption rates: (adjust lossConst to suit your desires) @PART[]:HAS[@MODULE[ModuleHeatShield]]:LAST { @MODULE[ModuleHeatShield] { @lossConst *= 2 } }

@Ultim32 If you check the log file, it should tell you more precisely where and why it's having trouble.

@Overlocker96 @sarbian It's Persistent Rotation.

Okay so brake DOES do a de-orbit burn then?

I'm not aware of any specific issues with Kerbalism. I don't use Kerbalism myself though and have not tested it with Deadly Reentry.

It needs to be on a collision course with terrain already, or at least it did the last time I tried it. (which was a while ago) In other words, it doesn't do a deorbit burn. You have to do that yourself.

So you still don't understand that he is confused by the mix ratios that he is encountering in the engine configs and that I am explaining to him why they don't match his expectations? You're not helping here at all. None of what you are saying to him is helping nor is it relevant to interpreting or writing engine configs.

@jeffreymelton24 I can't comment on the variance and residuals part but regarding the ullage section of the configs, I wouldn't change it from the provided settings. They're mostly empirically established over years of the mod's lifetime. Most of them control how quickly ullage becomes unstable over time or in response to a tank part's motion. Venting refers to the use of propulsive venting using boiloff mass to offset ullage instability. limitedIgnitions and simulateUllage should be self-explanatory. Setting them false would disable the respective features entirely. (explodeEngineWhenTooUnstable - I don't think that was ever implemented)

Your statement itself is irrelevant. IRL mix ratios ARE by mass. KSP mix ratios ARE by volume. Therefore, if you look at the mix ratios used in the game and try to compare them to real life values you have to take into account those facts. What I told you is the correct answer. Let's try this again: REAL LIFE mix ratios are by mass KSP (including RO/Real Fuels) mix ratios are by volume. You MUST convert mass to volume when configuring engines.

Then the RCS will stop working on parts that have them defined. (I didn't see any engines mentioned, just RCS) This is why I said YOU HAD BETTER KNOW WHAT YOU ARE DOING. Using partial configs is fine, I do it myself. I don't have RO installed either (I do use Real Fuels) . I do draw from some part configs but I know what I'm doing and what the consequences are if I screw something up.

It's unlikely. As far as I know (someone correct me if I'm wrong) the KSP1 model files (.mu) don't work with KSP2. Brand new format. Which means that unless we have the original model files on hand (used to export from Unity to KSP) then it's not happening at all.

IRL, rocket mix ratios are by mass. KSP (and Real Fuels) engine consumption are by volume (kiloliters). let's say 23.69 kl LOX + 76.31 kl LH2 27.03029 mt LOX 5.410379 mt LH2 ratio of 4.9960 / 1 (rounded to 4 places)

Put it in your Data folder and it'll be executed when you start the game. As I said though, it assumes FAR and Real Fuels are installed. If FAR isn't installed then the SOCK parts will not have any lift. (and control surfaces will likewise not work at all)

I'm assuming when you said uncontrollable that you were referring to aerodynamic issues. Is that right? If it's a control authority issue, is it happening going into Max Q or before that, in the upper atmosphere where drag is still low but enough to overcome RCS? Maybe it's an issue with troubleshooting the craft design.

These are the RO configs for that mod. From the looks of it, it rescales everything and makes other extensive changes that assume certain other mods are installed. Be VERY sure you know what you're doing if you want to use those configs without having RO installed. https://github.com/KSP-RO/RealismOverhaul/blob/master/GameData/RealismOverhaul/RO_SuggestedMods/SOCK/RO_ShuttleOV.cfg If you are not using FAR, then don't use those configs because they will remove the stock control surface configs. It will make those changes even if you are not using FAR. Also, because they use FOR[RealismOverhaul], any mod config you have that is contingent on RO being installed will be applied. (that is, it will be assumed by Module Manager as if RO is fully installed even though it isn't) Other changes assume Real Fuels (and Community Resource Pack by extension) is installed. TL;DR don't bother with those configs unless you have FAR and Real Fuels installed. You'd better know what you're doing!

Actually, Deadly Reentry also does g-force damage to parts as well as Kerbals. I would not recommend installing both this mod and Deadly Reentry. They won't be complementary.

I'd like to be able to bind zoom and translating the camera up and down in the VAB. Specifically I want to be able to bind the latter to the mouse wheel the way it was in KSP1. (not asking for the current setup to change, just for the ability for the player to be able to change it)

Looking at your attached image: Did you try clicking that little white arrow next to Real Fuels? That indicates grouping. When it points to the right like that, the Real Fuels menu items are hidden. Click it and they will be revealed. (notice how the arrows point down for kOS and Procedural Parts and their menu items are shown)

Including the end cap at the front?

Seeing some tri-hex style trusses in the first picture. Are those from this mod or another?

You should probably also join the RO Discord channel and ask in there. You'll probably get more help there than on the forums.

Let us worry about whether or not there's enough deltaV to make the maneuver! Just putting up a warning is good enough. We'll worry about the rest.