septemberWaves

The X-15 is making me wonder if it's possible for some form of RP-1's air-launch system to be decoupled from RP-1 for things like this. It'd be useful for Pegasus too.

What is the function of the pipe that sticks out below the Atlas skirt, and why was its shape changed after Atlas A?

Changing the patch ordering to remove ":FINAL" is fine, as long as I am able to override Kerbalism at all. The "FinalPatches.cfg" file didn't work; Kerbalism still overrides my patches regardless if the default profile is enabled and unedited. I've asked in the Kerbalism Discord how to make this function, and whether it is actually possible at all to patch life support resources differently than the default profile without them getting overridden or whether I am forced to create a custom profile. If it is possible to make these patches function without creating a custom profile, then I'll provide updated patches with altered patch ordering to remove ":FINAL" modifiers (which were only used in the preliminary patch versions as a futile attempt to prevent Kerbalism from overriding the patches). If I am forced to create a custom profile, then it is probably better to have that be a separate project, since an entirely custom Kerbalism profile seems a lot less within the scope of quality-of-life patches than just patching the default profile.

I am trying to patch the fuel cell for the Shuttle Orbiter Construction Kit space shuttle, to replace a stock-style LFO converter with a hydrogen-oxygen fuel cell based on the ones in BDB. The original module looks like this: MODULE { name = ModuleResourceConverter ConverterName = #autoLOC_502022 //#autoLOC_502022 = Fuel Cell StartActionName = #autoLOC_502023 //#autoLOC_502023 = Start Fuel Cell StopActionName = #autoLOC_502024 //#autoLOC_502024 = Stop Fuel Cell ToggleActionName = #autoLOC_502025 //#autoLOC_502025 = Toggle Fuel Cell FillAmount = 0.95 AutoShutdown = false GeneratesHeat = false UseSpecialistBonus = false INPUT_RESOURCE { ResourceName = LiquidFuel Ratio = 0.00009 FlowMode = NO_FLOW } INPUT_RESOURCE { ResourceName = Oxidizer Ratio = 0.00011 FlowMode = NO_FLOW } OUTPUT_RESOURCE { ResourceName = ElectricCharge Ratio = 1.0 DumpExcess = True } } My attempt at patching it looks like this: @PART[benjee10_shuttle_midFuselage]:NEEDS[Benjee10_shuttleOrbiter]:FINAL { !RESOURCE[LiquidFuel] !RESOURCE[Oxidizer] RESOURCE { name = Hydrogen amount = 64000 maxAmount = 64000 } RESOURCE { name = Oxygen amount = 32000 maxAmount = 32000 } @MODULE[ModuleResourceConverter] { @AutoShutdown = True !INPUT_RESOURCE[LiquidFuel] !INPUT_RESOURCE[Oxidizer] INPUT_RESOURCE { ResourceName = Hydrogen Ratio = 0.7 FlowMode = NO_FLOW } INPUT_RESOURCE { ResourceName = Oxygen Ratio = 0.35 FlowMode = NO_FLOW } @OUTPUT_RESOURCE { ResourceName = ElectricCharge Ratio = 1.5 DumpExcess = False } OUTPUT_RESOURCE { ResourceName = Water Ratio = 0.00055643 DumpExcess = True } } } The first parts of this patch are an attempt to remove the liquid fuel and oxidizer from the part as they are no longer needed for the fuel cell, plus an attempt to add the hydrogen and oxygen that are now needed. The rest of the patch is for editing the module itself. The result is that the functionality of the edited fuel cell gets inexplicably merged with the functionality of the original fuel cell (see image below), instead of replacing it. What is going wrong here, and what is the correct way to do this?

Is this "FinalPatches.cfg" file able to go anywhere in GameData, or does it have to go somewhere specific? I'll try this out, if it works it'll be very helpful.

I assume the "null profile" is what is happening. The planner still exists but most actual features of Kerbalism (e.g. life support) are completely absent if I try to load up the game with a custom profile.

The way the half-stage skirts (Saturn has one too) decouple based on acceleration is useful but still quite limited. I've especially run into trouble with solid-boosted half-staged Saturns, where peak acceleration happens during the solid stage. In that circumstance, the half-stage can't auto-jettison because it has to jettison after booster burn-out (because the lower structural attachment points for the boosters are on the half-stage skirt). It also has to be configured differently depending on payload mass like you said. Half-stage timing in general is heavily dependent on the payload and the desired orbit for that payload. You need enough extra time-to-apoapsis for the reduced thrust after jettison, which requires a significant vertical component of the vector prior to jettison, but that vertical component takes away from horizontal delta-v (which is of course the main thing you need to reach orbit). It's a matter of balancing how much delta-v you need to send your payload to the correct trajectory (either orbit or beyond) with the trajectory that the rocket is capable of acheiving. Jettisoning the half-stage early is good for delta-v but bad for thrust (meaning it's less capable of sending larger payloads to orbit); jettisoning it late is good for thrust but bad for delta-v (the thrust is therefore good for more massive payloads but delta-v margins become the limiting factor). And you typically also have to avoid jettisoning the half-stage while dynamic pressure is high, if you want to retain control of the rocket. In general, heavier payloads are restricted by how late you can jettison the half-stage while still having enough delta-v to reach orbit, and lighter payloads are limited by how early you can jettison the half-stage while still having enough thrust.

Able does have built-in ullage thrusters. Look at the fuel tank, it has RCS thrusters for ullage in addition to the ones for attitude control. Edit: I just double-checked this and it turned out I was thinking of Ablestar. I also double-checked the in-game part models, and the Thor-Able interstage fairing has a couple of holes in it which are presumably for hotstaging purposes. The Thor-Delta engine fairing lacks these holes, which leads me to assume that the real rocket would've had breakaway panels for hotstaging installed somewhere in the interstage section, similar to the S-IV (either that, or BDB just doesn't model the hotstaging holes for Thor-Delta). I have not managed to find any clear source information regarding how Able was staged, so I am just going by how it is represented in BDB.

I think it may have been hotstaged, but I am not entirely certain of that. It apparently also could be restarted, which is presumably the reason for the prograde RCS thrusters built into the fuel tank.

I have a request regarding the Space Shuttle tail service masts. I'm building a version of the Space Shuttle which uses Oranges and Photon Corp for the external tank and solid rocket boosters respectively. As you can see in the first image below, the tail service masts are not tall enough to properly interface with the spacecraft (and I can't lower the rocket because otherwise the boosters clip into the launch pad). This is not an error of construction or of proportions, as the second image demonstrates (the angle and distance of the screenshot compared to the photograph isn't quite right, but I think it is sufficient to demonstrate that my issue with the launch pad does not stem from errors made while constructing the spacecraft). To resolve this issue, I'd like to request one of the following changes to the tail service mast: Add an optional taller version of the part as a part variant. This is probably the more complicated option because it involves figuring out the right height for a variant. Make the base of the part model extend below the attach node, so that players can use the offset tool to adjust it upwards without compromizing the appearance of the launch pad. EDIT: I think that there is an argument to be made for using the SOCK+Oranges+Photon Corp build as the standard Space Shuttle around which the launch pad is configured - specifically, the fact that it provides a very accurately-proportioned launch vehicle for the SOCK shuttle that the current shuttle launch pad appears to be sized for. If this is done, then I have four more changes to recommend: a taller position for the rotating service structure with correspondingly longer legs (to account for the fact that the shuttle is positioned higher above the launch pad); an adjustment to the SRB hold-down part (to make the bolts line up); repositioned SRB exhaust holes (the current ones are slightly too far apart); and repositioning of the nodes on the main launch platform to attach the external tank and SRB hold-downs in the right places. That said, the main thing causing an issue for this build is the inability to change the height of the tail service masts, hence why I am specifically requesting that change to allow the current launch plaform to be more versatile.

I know that you can only have one profile. I am not trying to install multiple profiles simultaneously, I am trying to replace the default one with a custom one and I cannot get that to work for reasons that are unknown to me. The "unintended consequences" that you refer to here presumably involve things like almost every feature of Kerbalism simply ceasing to function, because that is what happens when I create a new profile with a unique name and very minor edits compared to the default (or even with no edits), and change the selected profile in the settings file accordingly. As for why the compatibility patches I have made thus far require a custom profile in order to function, I have no idea. The patches currently use :FINAL modifiers (which I used for testing purposes just to make sure that absolutely nothing else could possibly interfere with them after), but Kerbalism somehow still overrides my edited life support resource quantities to its default values. If Kerbalism is overriding :FINAL patches then it is doubtful that any other patch ordering (such as specifically telling the patches to happen AFTER Kerbalism) would have any effect. This is the information that led me to believe that a custom Kerbalism profile is the only way to make this work, and which subsequently caused me to run into the problem of my custom profile not working no matter what I try. Another unfortunate consequence of the way I have to edit the Kerbalism profile is that any parts which are not specifically patched will have no food, water, or oxygen at all. If it were possible to edit these resources without Kerbalism overriding the patches, then this wouldn't be an issue, but as it stands I am forced to directly patch any crewed part which requires these resources (stock parts are next on my list, but I need to figure out the required supply duration for the space shuttle before I can complete that). I would much prefer not to have to create a custom profile at all, but this behaviour of overriding even :FINAL patches is not something that I know how to circumvent without one.

Regarding these comments: I based these Saturn builds on Friznit's unofficial BDB wiki, so any incorrect design choices come from there.

Clustered tanks are absolutely an engineering compromise, and they're an engineering compromise that made it all the way to the Saturn I and IB rockets that actually launched. Being able to reuse existing manufacturing facilities with minimal changes to tooling, or simply being able to reuse surplus older rockets that were never launched, is certainly a good reason to consider clustered tanks. Compared to a single fuel tank with the same volume, a cluster of tanks has higher dry mass and is longer (the latter of which necessitates a taller assembly building, if the rest of the rocket is unchanged). The reason it was done for the first stage, and likely the reason it was considered for upper stages of these early Saturns, is because it is cheaper to manufacture (at least hypothetically).

I've been making some unconventional Saturns. Juno V-A and V-B, and Saturn A-2 and B-1: Saturn C-3, C-4, and C-8:

De-autostrut them. If you have stability issues, I recommend that you use KJR Continued rather than autostruts.