Starwaster

@Jen X-1 I don't have a solution but I do have a workaround. Quicksave and then quickload. That will fix the immediate terrain issue. This has been a problem on and off for a few years, even as far back as the original Real Solar System. But I don't recall what the actual cause was or what the solution is. If I figure out a real solution, I'll let you know.

How shallow/steep is your descent? At the point you start your burn, are you doing a straight vertical descent or do you still have a lot of horizontal velocity to kill?

Depends on where the parts originally unlocked. If they unlock in Hypersonic they're already configured as having tiles. Certain other spaceplane/shuttle parts from 3rd party mods get the tile treatment as soon as they unlock. (Mk4, KSO, OPT, etc)

It’s got nothing to do with atmospheric pressure. It’s what I said earlier, it’s the external temperature that’s in play in the scenario you’re describing. The radiator module code simply will not move heat out of a part if that part’s temperature is lower than the external temperature. And above supersonic, external temperature (kelvin) is roughly equivalent to velocity in meters per second. (That’s a rough estimate and in stock, convective heating is boosted to make reentry more challenging) the reason why the radiator suddenly starts working when you cross into space is external temperature changed to 4K so now the part temps are higher than external and the radiator will cool them. again, I have a mod that fixes that behavior and introduces realistic power consumption when heat has to be moved from a part cooler than the radiator.

No, you just go into settings while you have a sandbox game loaded up and change the option for upgrades in sandbox. I forget its exact wording but it's easily done without having to edit any files. Doesn't matter though: Irrelevant because he's using career mode. As for the radiator... not sure what you're talking about with thin atmospheres. Although any radiator whether in KSP or IRL will be less effective when you lose convection as a means of cooling the radiator. That's normal and to be expected. But that's not what's going on with KSP radiators. ModuleActiveRadiator only cools a part when that part's temperature is higher than the external temperature. So no matter how hot the part is, it cannot move heat into the radiator until it gets hotter than the reentry shockwave. (totally unrealistic solution to radiators originally being overpowered during reentries. Fixed in my mod Real Active Radiators) It's under Hypersonic flight, it's named Ceramic Tile

Sorry, there isn’t a guide. Are you sure you have the upgrade for spaceplanes? (If in sandbox, you also have to enable the option to apply upgrades since there is no research of tech)

Try to avoid generalizing. I was precise and specific and I expect the same if you’re going to reply back. Also that comes off as snarky and condescending.

You can turn autostrutting OFF if you don't want it in KSP1. So turn it off and don't try to deny it to people who want it.

@AnFa Your rocket may not have the control authority to fly the path that MJ is trying to fly. In fact, the Classic Ascent is basically defining a static flight path based on the settings in the Ascent Path Editor. A rocket with sufficient thrust AND control authority will get to orbit over Kerbin with the default settings. You say you can get it there manually. If that's so then adjust the shape of the curve in the editor to match your manually flown path. But understand that the classic ascent guidance doesn't do anything more than follow a statically defined curve. It's on you to either build a rocket that can fly within those parameters or to change the parameters to something your rocket can fly.

I'll take a look and see if I can contribute something useful.

I wrote something for MJ2 that I never committed that tapped into the suicide burn timer and pitch up enough to spread the necessary burn over the entire estimated time to impact/landing. (player can input a margin to add to the timer if the lander doesn't seem to be pitching up enough). It relied on calculations already being performed by MJ. Could something similar be useful here? Can't wait to try it!

I managed to reproduce this when I had speed limit at 0.1. Changing the limit to 1 immediately caused it to finish the docking. I'm not sure to what extent speed limit was a factor or not as in your previous screenshots, you always had your limit set at 1m. I'll take a look at the code since I was the last one to make major changes to the docking code. (some minor change by someone else but I don't think that's a factor, I managed to repro with an older branch predating that change) One thing that might be a factor is the undocking and redocking to a different port. If you're initiating docking to another port from within the bounding box then the docking AP could get confused somewhere along the way because it has to first back out of the box in a safe manner, move around the station and then re-enter the box from a new angle. That's alone involves some complex maneuvering by the AP to get out, go around and then back in. Before I did some revamping of the docking code, it had a nasty tendency to try to fly through the station to get to the new docking port. I think it might be getting hung up on the corner of the bounding box. It would be trying to maintain the safe distance while simultaneously moving laterally to the docking axis and that could produce contradictory velocity changes.

A more likely configuration would be a compressor fan with bypass doors that close as the engine transitions to supersonic / ramjet speeds. Then later transitions to scramjet and then rocket. There are research documents proposing this. Having it also be a rocket engine might not be realistic or feasible, but I wrote up a config that does turn one of the OPT parts into a hybrid scramjet / rocket engine using the data from the research document for the Mach curve data. I'll post it later today. Edit: Ooops, I kind of skimmed over parts of your question because it was early and I had to go make breakfast, so I'm looking at it now and I'm not really sure what you were asking here... I could still post my config but I'm not sure it's what you're looking for?

Pro tip for anyone using Dropbox to distribute files: If you set the &dl=0 to &dl=1 then it will be a 1 click download. No opening a new page. Edit: Also, although the file says 'logs' in it, there's no KSP log or Unity player.log Those could be more helpful than the dxdiag that was in there. Probably a lot of exceptions in there . Just a hunch.

@cfloutier When braking for landing, does it give separate consideration to vertical velocity from horizontal velocity or is it just trying to null out the velocity vector as a whole? (A use case would be an Apollo style lunar module 'shallow' descent where maybe 90% of the thrust is cancelling horizontal velocity and the remainder used to manage descent velocity)

@garwel How would a 3rd party mod tie into this? For instance, a life support mod, or Deadly Reentry? (DR actually has a mechanic for damaging Kerbals that overheat outside of a craft)

Because they look at engines, not generators or converters (which is what the fuel cells are configured to be)

They're taken in alphabetical order, including the folder/subfolders they are in. So, within a given phase (FIRST, BEFORE, FOR, AFTER, FINAL), things will go from 0-1,a-z.

@Astra Infinitum alt-F11 reload database is the way to do it, IIRC. Except that there was an issue where it messed up R&D configs. And even some part's might not re-initialize properly. It was enough of an issue that personally I just restarted my game. It's been quite awhile though so maybe the issues were resolved. (they were stock issues, not MM issues)

What it looks like is this: A lower level of boiloff at the start of the mission ramping up to excessively higher boiloff over time. Time warps high enough to trigger analytical heat will make it happen a lot faster. Lower/higher being relative to before the changes were made (March 2022 IIRC). What happens is that the part has more thermal inertia than it should have and the cooling effect of boiloff is diminished. You're basically having to cool down not just the tank part, but the cryogens inside. Imagine that your LH2/LOX are being heated to around 172+ Kelvin. IRL that can't happen because they never go above their boiling temperature until after they've changed state into a gas. @RESOURCE_DEFINITION[*]:HAS[#vsp[*],#hsp[*]]:FINAL { @hsp = 0 } That will patch every resource to set specific heat to 0 if both specific heat and latent heat are present. (latent heat of vaporization should only be present for cryogenic resources)

It lacks certain changes that were made in the official branch. Some of it is just general: I feel that RF has become more and more bloated with features that were made to serve Realism Overhaul, which RF predates. RF used to be a much simpler mod introducing a variety of real resources + boiloff for cryogenic resources + normalizing real world volume units. But also, there have been specific changes that I have problems with such as to the Unmanaged Resources feature. The changes made break that feature as it was originally designed. (and I should know since I designed it) Another such change is adding specific heat (hsp) back into cryogenic resources. (I removed specific heat from cryo quite a few years back). Without going into too much detail, the net impact is that cryo resources will over time absorb more thermal energy than is realistically possible. That means more heat energy that needs to be removed by radiators/cryocoolers and it's energy that shouldn't be present. The full answer is a good deal more complex than that and more complex than I feel like dealing with here right now. (I will say this though: In terms of heat, there's sensible heat and latent heat and you should never be dealing with both at the same time. Cryo should only ever be dealing with latent heat. Never sensible because it is assumed to be at its boiloff temperature at all times.) That second item is something you will probably never notice if you only deal with cryogenic resources for launch and not long term storage, such as ISRU or cryo depots. If you play with either of those then you may have noticed that over time you built up more heat than you could easily get rid of.

@SpacedInvader I'll take a poke at it and see if I can find out what's happening, but I have to warn you, I'm not involved with Real Fuels development anymore and only use my own branch for gameplay. I'll have to install the current official branch and the other mods you mentioned. I can do that, but you might have better luck going into the Realism Overhaul discord channel and bugging them about it directly. I don't know if they even monitor these forums anymore. You could try making an issue on the github repository page but I don't think they really look at those anymore either. They definitely don't care about the last issue I raised.

I hope if they include resources in the thermodynamics system that they don't do it the way they did in KSP 1 and just merge it to part thermo as one monolithic thermal mass. Part + resource thermo needs to be separate.

When useRealisticMass is set to false, engines are scaled 4x and tanks are scaled 4.8x. If set to true then the part's configured mass is used as is. There is an implicit assumption there that engines are scaled realistically already and if useRealisticMass = true then don't touch engine/tank masses. It also assumes that they are set to 1/4th of what they would be in stock, so the simple answer to your question would be that if you're using a stock Kerbol star system then the setting should be set to false. A realistically scaled star system (Real Solar System, Kerbin 10x, JNSQ) should have the setting at true. BUT. (caveat time) This mod, while having scaled down engine masses, does not necessarily have engine masses at 1/4th of their stock sizes. For instance, MassiveBooster (I think that's the shuttle SRB styled one...) has a stock mass of 4. But this mod sets it to to 2.4. If you set useRealisticMass = false then you're going to end up with a booster that is 9.6 tons. YOU DO NOT WANT THAT. That's more than double the stock mass for that part. I'm not sure of the relevant config file's history, maybe the ratio between mod and stock used to be different. But I would set useReaiisticMass = true to avoid unnecessary headaches.

Yes absolutely. You could even do it like The Little Prince if you wanted.