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.

Did you lock the robotic parts? You have to lock them during flight to prevent flexing.

Is there any documentation that explains how to create a custom Kerbalism profile? I need to make a custom profile but I can't get it to function; this means that I am clearly missing something or doing something wrong, but I have no idea how to tell what is going wrong. Is there any documentation on this?

Here are my preliminary BDB compatibility patches: https://www.dropbox.com/scl/fo/gj62p00qyjlklzp5u17pg/h?rlkey=v8f4nj2wd2z8nem02pnvv6m8c&dl=0 Every crewed spacecraft has been patched to have enough life support resources to accomplish its historical missions (or, for those that never actually flew, they've been patched to accomplish the mission profiles that they are intended for). Additionally, some of the space probes (particularly early ones) have been patched to have enough electricity to run their associated Kerbalism experiments (at least, the ones that currently exist). I have not yet added custom Kerbalism experiments in the many places that they are missing. It's important to note that these patches strictly require a custom Kerbalism profile. Otherwise, my edits to the amount of life support resources in capsules (the most important adjustments) get overridden by Kerbalism, and I can't find any way of preventing that without using a custom profile. The only required edits are removing the "supply" line from food, water, and oxygen sections right at the start of the profile; I directly patch crewed parts to provide these resources in quantities needed for historical mission profiles. Stock crew parts are currently not patched in a similar way, but that's one of my next steps (and presumably most people who use BDB will make very little use of stock crew parts anyway). Additionally, I cannot find a way of making a custom Kerbalism profile actually function. I have no idea what I am missing, but all attempts at making a custom profile result in Kerbalism refusing to recognize the custom profile as one which exists. As a result, I've been working with a directly-edited "default" profile. If you know how to make a custom profile that Kerbalism won't ignore, I'll put one together properly.

I'm trying to create a custom Kerbalism profile. If I edit the "default" profile, my changes work with no apparent issues. If I instead create a copy of the "default" profile, change the profile name to something new, and change the setting in the config file to use the profile with this new name, many features of Kerbalism go missing despite the fact that I have not removed them. Why is this happening, and how can it be fixed? Does the setting for "profile used" in the config file affect things outside of the "Profiles" folder, or is something else going wrong?

Upon thinking about this, I'm not sure this is entirely the case. I do not have an optional patch for BDB installed (aside from the real names patch). The hydrogen-oxygen fuel cell switch exists within the standard BDB file for the Gemini equipment module. Still, I'll go looking for the old Apollo fuel cell patch.

Does anyone happen to have some source documentation for the Mercury lab proposal? I'm hoping to find out how long a single mission with the lab would last and what kind of experiments would be done, for the purpose of configuring Kerbalism life support supplies.

I did see this line; I couldn't find the "Retro" folder so I assumed it must be an out-of-date instruction. Upon looking again, I've found it. Thanks.

My recommendation would be to take the following steps: Create a clean install of KSP. This is referred to as the "test instance" in the following steps. Using CKAN, install the Tantares mod set and all dependencies on the test instance. Load up the test instance and check if the bug is present. If not (and I suspect this will be the case), proceed to the following step. Re-download the latest Tantares builds from the Github, and manually replace the CKAN-installed versions in the test instance with the newly-downloaded latest versions. Load up the test instance to check if the bug is still present. There are three possible outcomes (assuming nothing breaks in the middle of this process): If the bug is present at step 3, with the CKAN builds of Tantares, then either this is an issue that has existed in Tantares for multiple updates without being noticed, or one of the dependencies of Tantares (likely B9 Part Switch) is bugged, or your clean install wasn't made properly (i.e. there are lingering mod files that shouldn't be there). If the bug is not present at step 3 but is present at step 5, with the latest builds of Tantares, then either this is a new issue with the latest builds of Tantares, or one of the dependencies of Tantares is bugged, or your clean install wasn't made properly. If the bug isn't present on the test instance in either case, then the issue is localized to the install where you first encountered it. In this eventuality, I'd recommend adding the modlist of that install to the test instance gradually (add mods one by one or in small groups) and load up the game each time you make a change to find what's causing the problem.

Do you have B9 Part Switch? And, if so, did you install it properly? If I'm not mistaken, texture glitches like this are usually to do with B9 Part Switch either malfunctioning or being absent.

The terrain exists, but I don't seem to be able to use any launch pad other than the default KSC launch site. Is there a fix?