Ksp b9 part switch fatal error

STR

• Have two adjacent subtypes sharing their second resource, e.g. LiquidFuel + Oxidizer and Liquid Hydrogen + Oxidizer
• Switch from one to the other

O

• Second resource will appear first

D

• Resource order is maintained

Explanation: The second resource already exists, so it is left alone, then the first resource is added to the end of the list, so it appears after

Steps to Reproduce

• Have a part with ModuleJettison affecting drag cubes and ModuleB9PartSwitch affecting drag cubes
• Have a craft that has this part and a part attached to the ModuleJettison node (so that the jettison object will appear)
• Load the craft in the flight scene

Observed

• Jettison object is missing

Desired

• Jettison object is present

Notes

• In KSP 1.4+, ModuleJettison now moves the jettison object to the attached part when the scene loads rather than when it detaches. This means that it cannot affect drag cubes if they are re-rendered, but also since it’s outside the part’s hierarchy, it won’t get duplicated for rendering drag cubes and AssumeDragCubePosition will disable/enable the real one, causing it to get disabled.
• Will have to re-architect the procedural drag cube implementation to handle this

Just getting around to playing with this feature — very nicely done.

One gripe. In the editor normal and expected behavior when switching types should be filling tanks (unless the type is specifically setup not to be filled), but in flight I can’t think of any scenario where filling tanks with a resource that was not already present is desirable. This is basically a cheat since tanks can be refilled by switching. I realize I could avoid this by defining the tank types to be empty by default, but that would leave the user with the annoyance of having to manually fill tanks in the editor.

In the editor, rendering drag cubes for a part or any part above it in the hierarchy will cause its texture switches to get reset. It doesn’t change the subtype, and switching to a different subtype and back corrects it.

Reason is that we reset texture switches before the part is cloned, and the part is cloned to produce drag cubes. When the part is cloned normally in the editor, KSP calls OnCopy which then tells the original to re-apply its texture switches, but this doesn’t happen when rendering drag cubes.

So I noticed that the actual mod doesn’t work AT ALL…
From what i saw in the logs, despite the fact it was in the GameData folder, it did not load at all, as if it didn’t exist…

KSP.log.txt

Easy to reproduce. Create a B9_TANK_TYPE with a resource that does not exist and start KSP. The first exception is thrown at B9PartSwitch.B9TankSettings.ModuleManagerPostLoad() and there after every part containing a ModuleB9PartSwitch fails to load with System.InvalidOperationException: The tank definitions have not been loaded yet (done after game database load). Perhaps ModuleManager is missing or out of date?.

I’m hesitant to call this a bug, better to make the game unplayable and force the problem to be fixed, however when the parts fail to load any vessels inflight containing those parts are unloaded potentially ruining a save game. Perhaps it could fail a bit more gracefully. Users commonly overlook dependencies which may contain the needed resource definitions when installing mods.

STR

• Launch a new vessel with root part having ModuleB9PartSwitch
• Exit to space center
• Return to new vessel

Physics now break and the ModuleB9PartSwitch has no subtypes.

Will have to investigate if root parts are loaded differently.

Current workaround: use something else as the root part.

When launching the game, I get this warning:

The game does seem to function fine after loading, however.

Relevant portion of the log file:

PartLoader: Compiling Part ‘NearFutureConstruction/Parts/Truss/truss-spinal/truss-spinal-01/truss-spinal-01’

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

DontDestroyOnLoad only work for root GameObjects or components on root GameObjects.

(Filename: Line: 481)

Warning on PartSubtype: Subtype has no name

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

Warning on PartSubtype: Subtype has no name

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

Warning on PartSubtype: Subtype has no name

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

DontDestroyOnLoad only work for root GameObjects or components on root GameObjects.

(Filename: Line: 481)

[ERROR] [Part truss-spinal-01] [ModuleB9PartSwitch ‘meshSwitch3’] Duplicate subtype names detected: System.String[]

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

Warning on PartSubtype: Subtype has no name

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

Warning on PartSubtype: Subtype has no name

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

Warning on PartSubtype: Subtype has no name

I can provide the full log if you want it, should I also bring this up with NearFutureConstuction?

While using a ladder transform/collider as a switcher target works very well in the flight scene, in the VAB the colliders used to specify the ladder become collidable and affect surface attachment.

Repro steps:

1. Install SSPX Redux (https://github.com/ChrisAdderley/StationPartsExpansionRedux)
2. Enter VAB
3. Create a PXL-1 ‘Hostel’ Habitation Module
4. Select a surface attachable part and notice it attaching to ladder colliders located along the EVA rails. Notice it not being affected by the ladder collider near the main airlock.

Requested by @ChrisAdderley

• Mass and cost are zero, no resources added
• What to do with transforms and nodes? Treat them all as disabled? If so, no other module would be able to force them to be enabled.

It’s well known to me by now that B9PS crashes when it determines that it’s attempting to assign subtypes to any ModuleB9PartSwitch before the associated tank type exists (in which case, B9PS finds itself adding a null or otherwise invalid subtype). My humble request is for an indication of at least:

• The subtype being parsed at that point
• The part config being read at the moment

Currently, KSP.log is dumped on with a load of 🐟 bones lol

This is risky but potentially incredibly useful. As far as I can tell there are two patterns

• Module exists and we just want to switch some data but not ever remove it
• Module exists for some subtypes but not for others (and maybe we also want to switch some data).

Removing modules (ModuleB9PartInfo for example) causes index mismatch errors if another module occupies the missing module’s indexed location. (anything after the missing module is shifted upwards).

When it appears in the prefab but is missing in flight mode, KSP tries to compensate by relocating the loaded modules to another location but this can be disastrous if there was more than one module by that name (multiple generator modules for example. KSP sees that the loaded module occupies a spot that MB9PI occupied in the prefab so it looks for a slot with an identically named module and loads into the first eligible slot that it finds)

If there IS more than one module by that name then they end up getting the wrong data loaded in.

So as an alternative to removing modules outright, how about just disabling it? You can save someone maybe five days worth of troubleshooting…..

It would be useful to change the stackSymmetry parameter when using different Subtypes, a PART-level variable which defines the symmetry number that is used when stack attaching to a part.

This would allow better functionality for symmetric engine clusters with variable node counts, which currently must be set to the lowest common denominator of all available variants for symmetry to work even partially.

The current download has:

  "KSP_VERSION" : {
    "MAJOR" : 1,
    "MINOR" : 5,
    "PATCH" : 
  }

PATCH is missing. This causes an error if you try to parse it:

Unexpected character encountered while parsing value: }. Path ‘KSP_VERSION.PATCH’, line 18, position 2.

Useful to be able to re-order subtypes without breaking craft. Determining the subtype would go like this:

• If name is present, find subtype with that name
• If name is blank or invalid, fall back to index
• If index is invalid, set to zero.

Index would be something like -1 to begin with.

Should also add a uniqueness constraint on subtype names.

Useful to see part’s current info:

• Current mass, wet and dry
  • Only display if a subtype has tank types or changes mass
  • Don’t differentiate wet/dry if no tanks
• Current cost, same as above
• maxTemp, if managed by any module
• skinMaxTemp, if managed by any module
• crashTolerance, if managed by any module

I’ve originally posted bugs on KSP bugtracker, but then realized that the only mod that causes this issue is B9PartSwitch (with many configurations of mods adding B9PartSwitch causes bugs, removing it makes KSP run perfectly).

There are logs, sampling, used mods and other info:
http://bugs.kerbalspaceprogram.com/issues/9721
http://bugs.kerbalspaceprogram.com/issues/9725

This reproduces on OSX (all info is in those invalid bugreports for vanilla KSP).

If you need more info, ask me.

It needs to take into account the unitsPerVolume of each resource as well, so line 61 should be:

public float ResourceUnitCost => resources.Sum(r => (r.resourceDefinition.unitCost) * (r.unitsPerVolume) );

In some situations it would be very handy to have a greater degree of precision when adjusting the amount of resources in a tank while working in the VAB/SPH. Right now the increments are (IIRC) 1/6th the tank’s volume, which is particularly problematic when trying to adjust the mass of heavier tanks.

Two examples where this would be useful:

1. Balancing the mass of asymmetrical vehicles, such as a Space Shuttle.
2. Ballast parts, which could be used to keep large vehicles stable at a desired angle during reentry, or as a mass simulator to test the performance of launch vehicles.

The latter example is of particular interest to me, as I’ve been working on a set of mass simulator parts. The initial version is nearly ready to go, but without the ability to fine-tune the mass, they’re not of much use. I’m already using this mod since it allows switching between different ballast materials, and also displays the exact mass of the parts via ModuleB9PartInfo.

I don’t know any C#, otherwise I’d make a pull request. Looking at the official API documentation, it seems like this might be possible to implement using the stepIncrement property of UI_FloatRange, though I’m pretty far out of my element here.

When switching (i.e. from UI), old subtype should just be given a message to deactivate. It will deactivate transforms and nodes and remove resources.

New subtype will be given a similar method to activate.

First time subtype setup will be similar to current methods. Switcher module should probably still hold logic for removing managed but not active resources.

This should fix #22

Keeps number of subtypes down on many switchers, aids ease-of-use

Current thinking: each child module registers itself to the «parent» to which it adds volume. Subtype changes on the child trigger a volume update on the parent.

Things to consider

• The parent shouldn’t really create any resources until all the children are initialized. Likely move resource creation/whatever to Start() so that OnStart() will be run on all modules first
• Each subtype should have a new volumeAddedToParent field that specifies the volume it adds to the parent (different from its actual volume)
• Volume update trigger: either keep track of parent and send method directly, or use part message

Should probably be tied to upgrade nodes

Maybe look into what can happen if the user tries to load a craft with subtypes that aren’t unlocked

Here:

Identified based on discussion in #78

Should I be concerned about this?

[WRN 19:53:49.699] [WARNING] [Part bluedog.Apollo.AARDV.Cargo] [ModuleB9PartSwitch 'cargoSwitch'] Only one subtype found, this may lead to unexpected behavior

We use Ore as a placeholder to define the volume on cargo parts. What gets added to the SUBTYPE’s depends on what life support mods are installed, if any are.

Very long term, somewhat limited use cases but potentially useful and probably not too hard to implement.

Only one module would be able to do this of course.