Starwaster

@EatVacuum @Dux Aquila Without logs and ModuleManager.ConfigCache files, there's nothing to be done except speculate. Regarding RF Stockalike that doesn't necessarily prove it was the cause as what it does is use MM to patch the engine files to use ModuleEnginesRF and ModuleEngineConfigs ---- there's nothing really to update in it unless Module Manager introduced new limitations or started enforcing older ones as it did when multiple ordering phases were disallowed.

If you're just talking about a rocket then it's very straightforward. No trial and error involved. First look at how other engines are done, especially for Realism Overhaul. https://github.com/KSP-RO/RealismOverhaul/tree/master/GameData/RealismOverhaul/Engine_Configs Set the engine's maxThrust to thrust in kilonewtons. minThrust should be set if you want to restrict the rocket's throttleability. Most rockets historically were not able to be throttled. When Saturn V first and second stage needed to be 'throttled down' they did so by shutting down the center engine. Lunar Module had an engine that could be throttled down to 10% SpaceX Merlin engine are also said to be able to throttle down to 40% of their max rated thrust (you very nearly always want to set thrust to the RL counterpart's vacuum thrust though some documents list an engine's SL thrust if it was a first stage engine) propellant ratios are in volume never mass (unlike real life) atmosphere curve is where you define the engine's isp rating for vacuum to sea level (or denser). The engine will have its max thrust at vacuum isp and calculate backwards for its isp (and therefore thrust) deeper into the atmosphere. Those are some of the most important areas for setting the rocket's abilities. Other areas can wait until you're more familiar with the engine configs.

logs and ModuleManager.ConfigCache file

Not sure why it wouldn't be straightforward as it's three lines of code but as you say it's of no use to SSTU so I understand your position. As to the suggested code, the second one could work as the module's saved ConfigNode could be retrieved easily enough... that's basically the only reliable information that's available at the time the code would have to be run since the vessel in question wouldn't have properly loaded PartModules.

Set it in the MEC config On another note, can you/would you expose the number of engines in a cluster, preferably as a persistent field in its config in order to allow other mods to pick up on the fact that it represents multiple engines? Stage Recovery can't really see it as anything other than a single engine. It would help with a pull I'd like to make to SR to fix the issue (SR can't really see the engine properly since it only sees it when it's off rails and off screen so it's either look at it's prefab or look at the config for the module)

@magico13 re the player using AJ10 for powered Reentry: there's another problem in that the code checks that TWR >= 1 While obviously important for the landing phase it is less important for deceleration during Reentry phase. (Though if it didn't have enough during the first burn then it may not have enough for landing. It all depends on if it burns enough mass to raise its twr for landing) not mentioned is whether or not those were sstu cluster engines. Those would appear to SR as one single engine. A fix for that would require either changes to sstu to expose the field holding the number of engines or some heavy duty parsing of the engine module config (by SR)

Set origMass to -1 (or even delete it outright since it defaults to that anyway) and it won't touch mass. As do I; no problems here.

You don't have to use RO in order for RF to be beneficial In fact RF predates RO by years. It even predates Real Solar System. But also note that he said he was using a scaled up star system. Isn't that enough of a reason to use RF?

I see no direct evidence that Heat Pump itself is the cause of your crash. The most likely cause is the fact that you are using the wrong version of multiple plugins including Module Manager and Fusebox Continued. Module Manager has multiple versions in your GameData folder. Delete all of them except for 3.0.4. That is the latest one for KSP 1.3.1; everything after is for 1.4.* Fusebox is also using a version that is for 1.4.1. This is of particular interest because it incorporates a replacement for the Part class and there are several method calls going through that replacement from PartLoader during part compilation which is when your game crashed. I can't go through your entire log comparing version numbers; that's your responsibility. Please go through your KSP mod installations AND VERIFY EVERYTHING. Make sure you have mod versions that are confirmed by their authors and maintainers to be compatible with KSP 1.3.1 OR YOU WILL SERIOUSLY SCREW THINGS UP AND MAKE ME ANGRY ENOUGH TO USE COMIC SANS IN UNDERLINED BOLD PRINT ITALICS!!!! And trust me, nobody wants THAT!

I accidentally deflated one after my engineer had left the station. Ooooopsie...

So, in other news there will likely be one more update of Heat Pumps for both KSP 1.3.1 and KSP 1.4.* After that there will be a new mod replacing it which extends the stock radiators and that fixes a few of the problems with them and has special handling for cryogenic temperatures, specifically a variable cooling rate based on Carnot efficiency multiplied by a cryocooler efficiency (which would be configurable and thus could be the subject of upgrade nodes) The same system will be incorporated into the Heat Pumps update mentioned on line 1 (so instead of the variable electrical cost I mentioned a few posts back it would be a constant electrical input with the actual cooling rate determined by part temperature and radiator skin temperature) The new mod is actually ready to go but it doesn't make sense to release it until Real Fuels is updated with the new insulation code. (active cooling for zero boiloff is only really effective when combined with passive cooling)

I don't know, SHOULD you send a crash report thingy? I don't have a lot of information to go by otherwise

When ullage simulation is enabled for RF, boiled off propellant is assumed to be vented in a manner that provides a small amount of propulsion to settle the propellants. (Saturn V third stage SIVB did this with its hydrogen tank) However, if you are collecting that gas then by definition you are not venting it. So any gas that you collected is not counted for propulsive venting.

The changes have to be made to the TANK nodes inside the TANK_DEFINITION nodes. Each tank that you want to do this must have the line boiloffProduct = (whatever you want to be produced). For example if you look at ServiceModule TANK_DEFINITION you will see that the LqdOxygen TANK has the line boiloffProduct = Oxygen. This is currently only possible with Oxygen, Hydrogen, Ammonia and Methane because those are the only ones that have heat of vaporization assigned to their liquid counterparts. (vsp) If there's no vsp for the resource then it falls back to the old pre KSP 1.0 code (which doesn't handle boiloff product) but that's probably not a problem because the affected resource are less common types that you'll run into in Realism Overhaul and are probably pretty obscure. Also be warned that boiloff product collected cannot be used for propulsive venting and won't be counted for ullage control.

Instructions unclear. Spent rest of life in pain amplifier...

ugh doesn't look like it.... unless MakingHistory has a dll plugin in there somewhere. You could do NEEDS check for the plugin if it has one. But I think this is going to have to be addressed in a future patch.

No but I did try to use them to make a quad drone.... it was a disaster..... totally uncontrollable. Was pretty basic, just a 2.5m probe core with radially attached hover engines. I may try again eventually

Actually I think this touches on the heart of the matter. There's all manner of spectres and fiends and cursed beings lurking in KSP haunting the code and causing lag and physics mishaps. And not a witcher in sight to save us...

It's not an issue of resource compatibility, it's an issue of having two different mods that want to manage those resources. I.e. want to edit the tank contents of a part. Interstellar comes with Interstellar Fuel Switch. I do not use that mod and I have no idea what will happen if it is installed at the same time as Real Fuels and you don't want to have to find out the hard way. Ask @FreeThinker if it's safe to use the two together. But, speaking as an RF developer, I would pick one or the other and then stick with it because past experience has taught me that multiple resource management systems don't work well together and trying to make them compatible is more trouble than it's worth. FT might have another answer though.

IIRC Interstellar has its own resource management system; you should only ever have one such active on a given part at one time. Or there will be conflict. Resource management as in being able to edit what kind of and how much of a resource a part has.

not yet

That's an RF thing and to my knowledge no RP0 patch has ever touched boiloffProduct. I only enabled it on the ServiceModule tank type and only for LOX, LH2 and CH4. The reason is that that boiloff mass is also used for ullage control (via propulsive venting) and any boiloff gas collected can't be used for that. It could be argued though that very large tanks with minimal insulation are going to have more boiloff than is likely to be collected so the impact on other tank types probably would have been negligible. In any case, ServiceModule still has boiloff gas generation set up for those three resources. Also, I wasn't sure it would work but stock radiators DO function in analytic in a manner that Real Fuels can utilize for cooling. Their main issue still being unrealistic energy costs for said cooling Edit: Oh and they probably won't do anything when returning to a craft after a long period of time where analytic kicks in for the long time delta... (like hours/days/weeks/etc etc) - or they might. Have to test that out.

Yes, but the magic words 'can you update' (or 'will you update') will miraculously cause the modder to appear and update the mod. (ok sorry was that too salty?)

Yes. Especially with insulation. When MLI is present it actually changes how quickly the tank part changes temperature in analytic. Actually, if anything it's too slow ATM because the rate needs tweaking. But that will probably work in the player's favor if they have their tank properly cooled before timewarping. If not and the tank is too hot then it won't cool down as fast as it should. The rate can be tweaked in the RFSettings file so the plugin doesn't have to be recompiled. Also, if Heat Pumps parts are present and cooling then RF will detect that even during analytic mode and and keep the tank cooled as appropriate by overriding analytic temperature and saying 'hey this is how hot we REALLY are'. (see, ordinarily, applying flux to a part in analytic mode has no effect on that part. Instead it applies to the entire vehicle's homogenized temperature)

FYI, the insulation update hasn't been pushed out yet. Blowfish is going to be handling that soon. An update to Heat Pumps will follow that as soon as I work some of the bugs out of my current build. Also, loss_rate is only used by the old legacy system. It's currently only used for resources that lack an entry for vsp (latent heat of vaporization). There are some TANK nodes that still use it but only for resources lacking vsp data. The code is set up to only look for loss_rate if vsp is absent. i.e. as a fallback system for things like diborane, ethane, ethylene and others. The more common resources such ls O2, LH2, CH4 and NH3 would be unaffected even if loss_rate = 0 were set for their tanks.