Starwaster

sigh

It depends on it has animation FX (or anything that implements IScalarModule) that you DON'T want the UI to show up for in the part action window. For instance if you had a drill that has a science experiment on, you DON'T to hide the UI for the drill so you set it to false. (it defaults to true)

Is his ModuleScienceContainer still on the part? If not it needs patching back in too and containerModuleIndex in your patch might need changing, depending on where the container ends up

I must be thinking of a different part that has no crew capacity at all.... the PBS equivalent of the stock station hub.

Why do you expect that it should have a lab at all?

The nitrogen thrusters are only for steering during recovery; alone and with grid fins (once it descends to where the air is dense enough for those)

That's ok for code changes and IFF code changes are required to get it functional for the next release. It doesn't do a thing towards pushing RSS towards a new release.

No.

Because we don't know what's intended?

aaaaand what does a 'swap converter' do?

Don't eat them!

Yeah lifesupport is a must since it forces you to play for logistics

What drives my choices in propellants is their boiloff temperatures, densities and isp. Hydrogen is a good choice for an upper stage since it it results in a lighter stage. Lighter upper stage means more lower stage delta-V. (the reason why Saturn V second and third stages were hydrogen based) I put a permanent single stage lander over the Mun to service the tourists that I keep getting contracts for. To maintain it I need a depot. To maintain the depot I will need regular shipments out there. Aerozine50 was the original best choice for the lander but that resulted in 1300 ton propellant shipments. Methane and hydrogen were 700 and 500 tons respectively. Methane gave better performance isp wise for the lander but hydrogen won out again to drive the shipment costs lower. Those were all real choices I had to make last night that weren't roleplaying choices. So now I have a lander design using the LC5 pod + lengthened lander tanks + a cupola for the pilot. (six tourist lander design...) - hydrogen based. (the old Aerozine powered lander can stay onstation as a backup I guess)

They're descended from the stock decouplers so they'll accept any sound setup that the stock ones do or any generic part effects. The only thing you can do as far as delays is waitForAnimation = true which will force it to wait for the entire animation to complete before decoupling. I didn't code the possibility of custom delays but if there's a real need for it then it shouldn't be too hard to do

How about a screenshot showing how you set up the rover and hitch?

@damonvv This is three years old; hopefully it should still be mostly valid but the center by default depends on its renderer bounds so scratch the bit about the model's origin. There's also supposed to be another way to setup a bay 'container' as a separate invisible model. I remember it was mentioned by one of the devs a year or two back but I don't remember much more than that. Consulting the API docs, it mentions bayContainer, useBayContainer and bayContainerName where bayContainer is a collider. (the others being a boolean and a string, respectively)

By setting lookupCenter (I capitalized it incorrectly earlier; it's lookupCenter) Treat it as being an offset to the part's center. (or wherever the model's origin is) BTW when I said you can use anything implementing IScalarModule, that apparently also includes ModuleColorChanger......

No, it's the point where you want the cargo bay to be when it's checking if something is in the cargo bay or not. For most parts that point is usually the center of the object which is usually where its transform is.

Did you set its LookupCenter? If it's not set then it's probably using the part's base transform.

It's not a cargo bay until it has ModuleCargoBay defined on it, with DeployModuleIndex set to the index of the appropriate ModuleAnimateGeneric module. (it could also be any other module that implements IScalarModule that the cargo bay can query as to open and closed states such as my Animated Decoupler)

I have and I go with separate engines

I just do nine individual engines. You're not really saving anything because in the end it boils down to 9 individual ModuleEngines* applying force against a single thrust vector or a single ModuleEngines* looping over nine thrust vectors applying force against each one. Six of one, half a dozen of the other.

To simulate denser propellants you should look at the utilization factor on the tank. That WILL allow you to load more propellant into the same sized tank and not do whatever it is you're doing with the engines. Here is what I use (below). It's realistic in that you will get actual mass increase on the propellants because it's literally more propellants in the same sized tanks. The utilization factor is educated guesswork but it is a guess since SpaceX keeps the exact numbers a trade secret. (or at least I have yet to come across those numbers and so have had to rely on old NASA documents) I left the temperature alone in these since the actual effect of going over the superchill temperature would be loss of densification before actual boiloff. The former of which RF doesn't handle and the latter affects gas recovery and venting. (vented boiloff is assumed by RF to be propulsive and is taken into consideration when calculating ullage state). Feel free to do what you want with them, but I would use a patch method like I did below instead of what you have now since it will survive and grow with RF updates. I'm still trying to figure out where your NaN is coming from. It's definitely not a part conductivity issue but there is a zero creeping into the calculation somewhere. A temperature delta of exactly zero could do it except that condition wouldn't survive contact with the first physics frame. In fact it is zero just prior to the very first physics frame when the vessel is first initialized. The other thing that would do it is a tank wall area of zero but I can already see from your screenshot that the tank wall area is calculated. (procedural parts tend to have that problem but none of those parts are) I probably won't be able to pursue this until after the weekend as I'm probably having a tooth extracted this weekend. (joy.) +TANK_DEFINITION[Cryogenic]:FOR[ZZZMyTweaks] { @name = SpaceX techRequired = largeVolumeContainment @TANK[LqdOxygen] { %utilization = 1.09954434 } @TANK[Kerosene] { @utilization = 1.04938272 // 1.049382716049383 } @TANK[LqdMethane] { %utilization = 1.12 } TANK { name = ElectricCharge mass = 0.00289 utilization = 1000 fillable = True amount = 0.0 maxAmount = 0.0 note = (pressurized) } TANK { name = Nitrogen mass = 0.000095 utilization = 342 fillable = True amount = 0.0 maxAmount = 0.0 note = (pressurized) } } +TANK_DEFINITION[CompositeCryogenic]:FOR[ZZZMyTweaks] { @name = SpaceX.Composite @basemass[0, ] *= 0.875 techRequired = metaMaterials @TANK[LqdOxygen] { %utilization = 1.09954434 } @TANK[Kerosene] { @utilization = 1.04938272 // 1.049382716049383 } @TANK[LqdMethane] { %utilization = 1.12 } @TANK[LqdHydrogen] { %utilization = 1.1 } TANK { name = ElectricCharge mass = 0.00289 utilization = 1000 fillable = True amount = 0.0 maxAmount = 0.0 note = (pressurized) } TANK { name = Nitrogen mass = 0.000095 utilization = 342 fillable = True amount = 0.0 maxAmount = 0.0 note = (pressurized) } } +TANK_DEFINITION[ServiceModule]:FOR[ZZZMyTweaks] { @name = ServiceModule.SpaceX.Composite @basemass[0, ] *= 0.875 techRequired = metaMaterials @TANK[LqdOxygen] { %utilization = 1.09954434 } @TANK[Kerosene] { @utilization = 1.04938272 // 1.049382716049383 } @TANK[LqdMethane] { %utilization = 1.12 } @TANK[LqdHydrogen] { %utilization = 1.1 } } @PART[*]:HAS[@MODULE[ModuleFuelTanks]:HAS[#typeAvailable[*],~typeAvailable[SpaceX*]]]:FINAL { @MODULE[ModuleFuelTanks] { typeAvailable = SpaceX typeAvailable = SpaceX.Composite } }

I notice you've got custom TANK_DEFINITION's set... your business, but lowering the temperature value for the TANK nodes, such as 80 for LqdOxygen will increase the rate of boiloff - What you just did there was tell it that boiloff at STP starts 10.15 K lower than than it should be. If the intent was to cool the tanks so they don't boil, well that's not what that field does. You're also robbing yourself of certain features such as Dewar flask tanks and extra builtin insulation because the necessary data isn't in your custom tank definitions. Also, when boiloff occurs, there is boiloff gas which can be recovered and (with the right mod and parts) re-liquefied but that's also dependent on the tank configs that come with RF - yours are missing that as well.

Need you to gather some more data please. First, enable boiloffDebugging by editing RealSettings.cfg, go to the section that says RFSETTINGS and add a line that says debugBoilOff = True So it should look something like RFSETTINGS { engineMassMultiplier = 4.0 useRealisticMass = true heatMultiplier = 1.0 debugBoiloff = true ... <all the rest of the stuff below> Start the game and enable physics thermal debugging (ALT-F12, Physics, Thermal) Then load up the craft and (assuming here it's reproducible and still happening) open the action menu for every part Take a screenshot