Starwaster

If internal temp is at 19K then it's not possible that RF is applying boiloff. I had to go refresh my memory as to how things were working and basically, mounting a Heat Pump part on a tank part forces it to use the internal temp if it wasn't already doing so before. The only other way that I can see this happening is through analytic mode (high time warp, i.e. over 100x) which you didn't say was when this was happening, but it would still only be possible for RF to apply boiloff if internal temp were higher than 20.15K. So, analytic mode or not, if it's at 19K then RF can't apply boiloff. (or in the case of LOX, 90K)

It can use either depending on whether the RF tank is a cryogenic type or not. Default tanks use the skin and Cryogenic tanks use the internal. Using the internal temperature allows for the simulation of multiple conduction zones, with the skin then becoming the MLI layers and the internal being the tank or spray on insulation layers. Cooling then gets applied in between those layers. The actual deciding factor is whether or not the tank part has a different skin-internal conduction factor from the default values with the boiloff equations and cooling equations using either skin or internal as appropriate. If you're still getting boiloff then you probably have some third party mod applying its own boiloff. There are at least two other mods that have their own proprietary boiloff schemes and neither of them look at the actual temperature of the part so neither of them would benefit from Heat Pump (or even stock radiator) and have their own 'cooling' scheme to negate boiloff. If you have RF installed then you should disable any third party boiloff since there's nothing I can do to mitigate that. I will leave open the possibility that Heat Pump isn't properly compensating for parts using the skin temperature and investigate that to make sure it's working as it should. AFAIK though that part does work properly on HP side

The gimbal issue has been discussed before; not sure if in this thread or not. This thread is pretty defunct as developer is absent. I've taken responsibility for maintenance and bug fixes for which I created a thread (below) and I have done some work on the gimbal issue. (deleted previous quick fix) As a temporary measure, download this: (right click the link and select save link as) https://raw.githubusercontent.com/Starwaster/ProceduralParts/master/GameData/ProceduralParts/Parts/ZOtherMods/RFSRB.cfg And copy it over the existing file in GameData/ProceduralParts/Parts/ZOtherMods/RFSRB.cfg That will patch all Procedural SRB parts both RF and non-RF versions.

Yeah probably, and I've done some preliminary changes that would help facilitate such a thing. Basically it would be the base or root of the nozzle. Currently nozzles/bells are single meshes and for reasons that I am *still* not entirely clear on are the source of the current issue where gimbals don't properly work on both axes. What I've found is that if the hierarchy is changed to some sort of root->gimbal->bell->thrust transform then it works. (currently it's just bell->thrust transform with the bell also doubling as the gimbal) So if I change things to a multi mesh/transform model then it works properly and the root could actually be some sort of skirt mesh. The downside is that it requires some code changes so that things scale/translate properly. (there is a cheaper easier way out which was to use the thrust transform as the gimbal so I've been waffling as to whether to go through with the other changes)

@Jim DiGriz Would you be willing to share a scan of that document?

Yes but you can't copy and paste them onto an adjacent computer / tablet.... (I should know, I tried once in a moment of stupefaction wherein it seemed logical to me that I should have been able to do so... I sat there for several seconds looking from one to the other wondering why it wasn't possible yet)

You can use a ? in place of the space. That will let you run MM patches against it but doesn't guarantee that there won't be a problem internally with KSP. The proper solution to spaces is for people not to use them. @Sigma88 Spaces are a problem for Unity URLs; when parsing them, nothing after the space is seen and they require special handling to deal with. Underscores can also be problematic internally and KSP replaces those with a dot. Module Manager can still parse those however.

It's the heat shield configs that are most problematic. The physics globals should already be balanced properly You can do that already by installing the latest version for KSP 1.2.2 and then get the unofficial dll for KSP 1.3.0 on the release page

Yeaaaaaah works great when it's installed correctly

The volume of the module needs increasing. You could patch it yourself but really whatever patch added the resources probably needs fixing. I also have an idea I'd been planning on implementing that would make it easier to patch in life support resources that would prevent MFT from trampling all over them but I'd held off because feedback was practically nonexistent. But what you can do is @PART[partname] { @MODULE[ModuleFuelTanks] { @volume += (whatever extra vol in liters you need) } }

Sounds like a PID issue in the rover controller. PID isn't a one size fits all and sometimes you have to tweak the settings.

@DrScarlett It happens for parts that are either lacking an IVA (you will not see any portraits) or if the IVA doesn't have enough seats for all the crew. In that case, excess crew will not have a portrait and not show up in the IVA. You can still move them out of the part by clicking the hatch or using the Transfer Crew in the part context menu.

Now that's exaggerating quite a bit. The 'souposphere' epithet needs to die. Stock aerodynamics has advanced enough that launching and flying even in an RSS environment is quite acceptable even without FAR.

@Gordon Dry before you can contribute to the project you need a better understanding of what the individual configs do and what the ramifications of your changes would be. Do you really think we've been using an incorrect density for water for all these years? And that's how long some of us have been doing this for. You can't just go around making config changes willy nilly and then tell us they're more realistic when you don't understand what you're changing. You need (please) to research thoroughly what you're doing before submitting contributions. That having been said: Yes, the mass system for tanks that RF uses does have issues but those issues stem from an abstracted system and not from incorrect values in the tank config files. As a result of that abstraction, tank masses will be too low for some tank sizes but increasing the tank mass values will penalize the most commonly used tank sizes. (rocket sized tanks as opposed to scuba tank)

@terminalmonky Correct. Also, volume, amount/maxAmount are in liters, mass is how much mass per volume unit is added and utilization should be left at 1 unless it's a compressible resource like a gas. notes are optional and will appear in the tank listing when the part is viewed in the VAB

Look at RealFuels/Resources/RealTankTypes.cfg Then look for the TANK_DEFINITION ServiceModule and then at the TANK nodes contained therein. Food, Water and Oxygen are present in there so look at how they are put together. But, with the example I've just given you I'm not actually sure why you need to do anything else. ServiceModule also covers things like command modules so you can already add life support resources to those parts.

Probably, that's actually about right for aluminum, so assuming an aluminum tank, yeah. Assuming it can withstand a launch I *would* say the ones for 10xKerbol except that I'm thinking of nerfing that configuration because it's a little overpowered.

Or, the player just needs to realize that there's reasons these things are prevented unless you override the system and that if you do override the system, Bad Things May Happen! tm

LH2 is not a resource defined by Procedural Parts. So technically it's a third party resource and the attributes of that resource as well as any support for Procedural Parts are third party. They determine how much of the resource can be added. Whether I agree with their implementation or not, it's their prerogative as to how to set up PP support for their resources. And while it may seem odd, keep in mind that the resource amounts defined in any KSP container are generally held to be generic volume units. Long ago the stock volume unit was designated by modders as the 'Kerbo' and empirically determined to be the equivalent of between 5-6.25 liters (Real Fuels and associated mods eventually settled on 1 KSP unit = 5 liters except where compressed gasses are concerned). So if you are able to put more of a given non-stock resource into a container then it's because the modder responsible is using a different unit of measurement than stock is.

@Rafael acevedo interesting but I wouldn't use it for anything like moving nuclear waste or fighting off alien attackers ...

When patching just be careful you don't remove any resources that aren't going to be managed by RF

First hook into the game events, say in OnStart or Start (if the code isn't in a PartModule then you will need to do this in Start) public override void OnStart(PartModule.StartState state) { GameEvents.onVesselGoOnRails.Add(OnVesselGoOnRails); GameEvents.onVesselGoOffRails.Add(OnVesselGoOffRails); } public void OnVesselGoOnRails(Vessel v) { // do stuff here } public void OnVesselGoOffRails(Vessel v) { // if you need to do anything when going off rails then do it here }

That's what 'Keep Limited Throttle Over____%' is for. In MJ2 Utilities, enable that and set it to what you need the minimum to be for your engine configuration.

It's not event driven, it just goes through the list of intakes and if it finds that there are open intakes that are surplus then it closes them. Either it thinks it HAS enough intake air or it thinks the intake air isn't necessary at all. (might be because of the ignoreForIsp field, not sure, but basically jet engines are configured to ignore air for mass requirements because of reasons) Frankly, it's an obsolete system to begin with. There is no current need for intake management because there is no benefit to closing them. Back during the Mesozoic era when dinosaurs roamed the earth, intakes had more drag when open than when closed so it was beneficial to close them. There isn't much logic to that IRL so the feature was removed. (actually I can envision a streamlined hull with intakes only exposed by doors... I can see that having less drag, but whatever) Also, intake management is disabled by default. That's why most people don't notice it.

Except for other mods that are zzzSomething...