Jump to content

septemberWaves

Members
  • Posts

    2,375
  • Joined

  • Last visited

Posts posted by septemberWaves

  1. 1 hour ago, JadeOfMaar said:

    Anywhere in GameData.

    Due to the :FINAL it doesn't matter. It'll absolutely run last, but if I'm going to accept patches they need to not have that.I've had cases of wanting to tweak a mod but the existence of a FINAL blocked me so I had to choose to do without that mod or edit the mod's files (which would be reverted if I reinstall or update the mod).

    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.

  2. 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?

    h8yVkGN.png

  3. On 1/14/2024 at 2:00 AM, ltajax said:

    Not sure if this helps, but I use a patch I made with help from the guys on the Kerbalism Discord to override the number of experiment sots that are available to the player in Kerblsim for probes. I was told in the Kerbalism Discord that they needed to be placed in a file named FinalPatches.cfg. I can use this with my default kerbalism install when playing with the BDB probes so can do multiple experiments on the early Explorer and Pioneer models, it does override the number of slots for me without issue.

    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.

  4. On 1/16/2024 at 7:23 PM, lordcirth said:

    In what way is it not functioning? Refusing to load Kerbalism? Loading the default profile? Loading a null profile?

    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.

  5. 10 hours ago, OrbitalManeuvers said:

    The thing I really like about the Atlas skirt is that since it's triggered by g-forces, it's basically like saying "when we have enough thrust to make it..." which smartparts can't do, since it doesn't have a g-force trigger part. I suppose altitude is an ok trigger, but seems like that might be more dependent on payload mass? You'd know better than I what the trigger or set of triggers was for the Atlas skirt. Maybe just straight up timing? I have the same question about the center F1 on the S1-C, too. 

    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.

  6. 2 hours ago, dave1904 said:

    And how do you think able dealt with that? The AJ10-37 for example? Able doesnt have any ullage trusters and the engine doesnt have cold gas exhaust right? Sorry for being such a pain in the black haha

    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.

  7. 37 minutes ago, dave1904 said:

    Anyone know how the thor able rocket stage ignited? Was it pressurised? Hotstaging or what?

    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.

  8. 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.

    CYhX8yT.png

    dI2GzNN.png

  9. 4 hours ago, theJesuit said:

    I should have qualified... what you do is change the named profile in the settings.cfg for Kerbalism.  It requires a manual change by user.  The kerbalism simplex download already has it changed from default.

    Changing the profile in the settings.cfg has unintended consequences as so many of the part patches rely on default profile.

    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.

  10. 4 hours ago, Pappystein said:

    Thanks for sharing!   Wonderful pics and interesting ways to kitbash to make some of this work.  Your early Saturns probably should have 4x E-1 engines on them.   Looks like you used 8x H-2s which was not the engine of choice when those were conceptualized.  E-1 was canceled a few months before the cancellation of C-2 and C-3 (and its cancellation is directly responsible for the development of the S-IVB and the S-IVC.)

     

    I have a relatively minor nitpick.

    So as, *I guess* the local expert on S-III, there were exactly 2 designs for S-III.   1st was a notational stage with no known engine properties... it would have 2 Hydrolox engines.  Either the J-2 or the LR87-LH2   In the case of the LR-87-LH2 (whatever designation it would have received) it was a TWO bell engine... Just like on Titan...    The Notational S-III stage was 220" diameter, or the original diameter of the 4 engine S-IV.      The second and Final design, likely to be built by McDonnell Corp, was 260" in diameter and about 2/3rds of the height of the actually produced S-IVB.   It would have 2 engines...   So 2 Bells with J-2s or 4 bells with the LR-87.    <<<----  This is where the idea that the S-III was a 4 engine stage comes from.   Only 2x engines would be used.     And before someone jumps on me about the LR87... Just because the Hydrolox test engine was a single bell does not meant the production engine was! :D     Also Somewhere I have a photo of a single bell AZ50/NTO test engine too :D

    S-III stage was deleted long before Lunar Orbital Rendezvous was selected.  So late 1960.

     

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

  11. 20 minutes ago, DaveyJ576 said:

    Very nice kitbashing. I have my own versions of the C-2 and C-3. I have wondered about the B-series Saturns. Might try those too! Clustered tanks seem like such an engineering compromise though.

    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).

  12. I've been making some unconventional Saturns.

    UfFYV3f.png

    dUJtZ7X.png

    G2HyGwm.png

    SHCGwf8.png

    Juno V-A and V-B, and Saturn A-2 and B-1:

    Spoiler

    oPP8Azl.png

    3I2Ga5c.pngqBVBrHR.png

    GXzM3AF.png

    IDWlyaA.png

    Vpdqgyd.png

    Juno V-A uses a cluster of Juno II first stages as its second stage, and an entire Titan I as its third and fourth stages. This build requires the first stage to be underfueled to about 70% to allow it to get off of the pad, and it can transport something in the range of 2 to 3 tonnes to a trans-lunar trajectory - though you'd have to launch directly to TLI because the Titan I upper stage in reality would likely have been unable to restart in vacuum.

    UfFYV3f.png

    Juno V-B replaces the fourth stage (a Titan I second stage) with a Centaur. The payload capacity is very similar (though seems to be somewhat better), and the first stage once again must be underfueled to 70%.

    6GX4Eay.png

    Saturn A-2 retains the Juno cluster from Juno V, but removes the Titan I stages entirely in favour of a lone Centaur. This one can launch with a full load of fuel (just barely); payload to TLI is approximately the mass of one Gemini spacecraft, which is probably what it would be best at launching. Its limited TWR means that Saturn A-2, like both Juno V variants, is probably not well suited to launching anything to low Earth orbit.

    dUJtZ7X.png

    WP2qggL.png

    mriOazl.png

    CvQik2k.png

    Saturn B-1 (not to be confused with Saturn IB) uses a Titan cluster rather than a Juno cluster. The third and fourth stages are an S-IV and a Centaur, respectively. The tanks of the cluster are Titan 1 first stage tanks, but the engines are the Titan II's LR-87-5, rather than the LR-87-3 used on Titan I.

    The first stage is underfueled to 70% once again, and the second stage (the Titan cluster) is underfueled to 80%. Additionally, the second stage engines are reduced to 60% throttle, because otherwise the acceleration is far too high. Payload capacity is somewhere in the range of 4 to 7 tonnes to TLI, so it'd be a good launcher for small station modules or a resupply vehicle, both for a lunar orbit station.

     

    Saturn C-3, C-4, and C-8:

    Spoiler

    Saturn C-3:

    G2HyGwm.png

    8LlrBa9.png

    FrbUu3e.png

    hOn4a5w.png

    x1QwDwp.png

    HeGRxvQ.png

    The 1959 design for the Saturn C-3 is a five-stage rocket. The S-IB-2 first stage is powered by two F-1 engines. The S-II-C3 second stage has four J-2 engines, and is less wide than the typical S-II. The S-III third stage is similar to the S-IVB, but with four J-2 engines rather than one. The fourth stage is the S-IV, and the fifth stage is the Centaur (otherwise known in this context as the S-V). The payload capacity of this rocket is very high, but TWR at launch is extremely low. Even with uprated first stage engines (F-1A rather than F-1), the first three stages must be underfueled to 70% capacity for the rocket to even take off. With all five stages, the rocket is probably best suited to launching especially massive interplanetary space probes, or (with a large enough fairing) modules for a lunar space station.

    CszMksI.png

    The 1961 design for the C-3 omits the S-III stage in favour of a lengthened S-II-C stage. The Centaur is inside the fairing. With this build, the first stage must be underfueled to 60% and the second stage to 80%. Payload capacity is not substantially better than the B-1, but would be drastically improved if the first stage engines had more thrust.

    Saturn C-3B:

    FHITfCl.png

    This is the first of these early Saturns that actually starts to resemble the Saturn V. The diameter of its first two stages should actually be slightly less than the Saturn V, but this is the closest I can get.

    lrDgV6I.png

    The S-IC-C3B first stage is similar to the S-IC of the Saturn V, but is shorter (and ideally would be slightly less wide). While the BDB S-IC-C3B should usually be underfueled to 80% for KSRSS balance, this one is underfueled to 70% to account for the smaller diameter that it should have.

    tQWrhWo.png

    B0PtuIR.png

    Like the first stage, the S-II-C5B second stage is a shorter (and hypothetically smaller diameter) variant of the S-II of the Saturn V. It is underfueled to 90% in this build to account for the reduced diameter.

    mENjq6W.png

    UggYC6h.png

    The third stage is a smaller diameter version of the S-IVB that actually flew, but is a similar length. The fourth stage is a Centaur.

    The C-3B has a payload capacity of around 35 tonnes to LEO, or about half as much to TLI. Due to the very low TWR of the upper stages with high payload mass, it is much better suited for lunar payloads than LEO ones.

    Saturn C-4:

    DZ7hv6v.png

    Vdwqejw.png

    1xwrgFU.png

    The Saturn C-4 uses a shorter, four-engine version of the C-3B first stage, and does the same for the C-3B second stage; both of these are underfueled by the same amount as my C-3B. The third stage is a shorter version of the S-IVB that actually flew, but is otherwise very similar. The C-4 is smaller and cheaper than the C-3B, and has accordingly lower payload capacity: about 26 tonnes to LEO or 10 tonnes to TLI. Unlike the C-3B, the C-4 is well suited to the task of lifting large payloads to low Earth orbit.

    Saturn C-4B:

    ClUb02D.png

    The Saturn C-4B uses the same first and second stages as the C-3B (the first stage should be slightly shorter, but BDB doesn't have a part switch for such a small difference in length). The S-IVB-C5A third stage is a lengthened version of the S-IVB-C3B used on the Saturn C-3B. Payload performance is very similar to the C-3B, but there is no fourth stage.

    Saturn C-8:

    oEtQVt2.png

    drdUqoA.png

    SHCGwf8.png

    0pFFk2Z.png

    0sQJcZ7.png

    lhHdAhS.png

    The Saturn C-8 is a concept developed to study the requirements of a direct ascent lunar landing. The C-8 uses a widened first stage with 8 F-1 engines, a slightly lengthened S-II second stage with 8 J-2 engines, and a substantially lengthened S-IVB third stage. The payload capacity of this build is around 120 tonnes to LEO, or 75 tonnes to TLI.

  13. 7 hours ago, Kakub said:

    I have very very strange bug, when i launched the Apollo mission with Rover attached to the LEM, the whole rocket started loosing apoapsis like it was pushing whole SIV-b stage back. When i decople the rover from the hinge everything went back to normal. Any help with this kraken stuff ?

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

  14. 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?

  15. 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.

  16. 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?

  17. On 12/17/2023 at 5:39 PM, GoldForest said:

    The hydrogen fuel cell patch was created by someone not on the BDB team long ago and is not maintained by the BDB team.  Said person is either gone from KSP or modding in general, and thus does not maintain the patch anymore.

    Since the patch was last updated/created, the mod has gone through several big updates, thus breaking the patch. 

    It should be as easy as renaming the apollo modules inside the hydrogen fuel cell patch in the extra folder to the names of the new apollo modules. 

    The fact it still works with Gemini is kind of surprising. 

    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.

  18. 2 hours ago, OrbitalManeuvers said:

    Sounds likely that the Retro folder isn't there or is in the wrong place. There's a one-liner in the Github readme that says where it goes. It needs to form this path: GameData\KatnisssCapeCanaveral\Instances\Retro

    The readme says:

    !!!!! Instructions: Place the Retro/Modern folder into KatnisssCapeCanaveral/Instances !!!!!

    (p.s. there is no Modern folder, only a Retro folder)

    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.

  19. 1 hour ago, Unbreakify said:

    yes, i've had it installed since i got SOCK. to my knowledge it hasn't been updated since i downloaded it, and the rest of Tantares works fine. Im assuming this is just a weird bug with the Rotanev Size 4 Fairing.. which is oddly specific.

    My recommendation would be to take the following steps:

    1. Create a clean install of KSP. This is referred to as the "test instance" in the following steps.
    2. Using CKAN, install the Tantares mod set and all dependencies on the test instance.
    3. 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.
    4. 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.
    5. 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):

    1. 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).
    2. 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.
    3. 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.
×
×
  • Create New...