The rocket interior ports, more specifically; the Spacefarer Input Ports, have a bug that causes them to "delete" (leak) liquids under very specific circumstances.
This is caused by a bug in the code, combined with certain situations ingame:
Theoretical Behavior:
The Spacefarer Input Port behavior, while landed, transfers all liquids/gasses within it to its respective port on the habitat module. When it is blocked, it stops doing that, accumulating one pipe worth of liquid/gas inside its internal storage. When in space, it instead dumps anything pumped into it into the space around the rocket interior, to be deleted by space exposure (note that this space exposure doesn't work until the game has been saved and loaded once after the rocket interior was created, but thats not the main point of this bug report).
So far, thats how everything works in theory.
The Bug and when it happens:
Spacefarer input ports inside a landed rocket might start its in-space-behavior (dumping their materials to the tile above/below it inside of the rocket interior) while landed.
The circumstances under which this will happen are the following:
- There is atleast one rocket landed on a planet and atleast one rocket in space
- The landed rocket has a liquid/gas pipe inside its interior, with any element inside the pipe being pumped to the outside.
- The outside pipe is BLOCKED(!)
- The rocket in space then starts pumping gas/liquid through its spacefarer input port (same type of port than what is blocked for the landed rocket!) -> it will start dumping the materials (intended in-space-behavior)
What happens: Inside the landed rocket, the type of port that has started dumping materials in the in-space-rocket will start mirroring this behavior, dumping its materials into the space area of the interior, even tho it is currently landed.
Note:
- when you unblock the exterior pipe, the material dumping will stop and the materials inside the pipe will flow through the pipe again (as that takes priority). If you block it again, the bug will reoccur.
- Landing all rockets will also cause all ports to function as intended again (not dumping materials, even when the pipe is blocked)
Bug in the Code:
This bug is caused by the AutoStorageDropper state machine, more specifically the way a certain way it is coded.
The Spacefarer Input Ports use this component to dump the materials to the world. To do this, it has its filter set to neutronium. By default, this blocks any materials from being dispensed and is the default state the port has when landed (making it hold to its materials and not taking in more materials when the exterior pipe is blocked)
Then, when going to space, the State Machine in the InputPort that handles the Material Sending Behavior (RocketConduitSender) inverts the item filter on the AutoStorageDropper (while also disconnecting interior and exterior ports), this then (in theory) allows for the dropper to go into its intended state of dumping materials into space.
Here is where the bug has its origin:
Inverting the ItemFilter is done in the Method "AutoStorageDropper.Instance.SetInvertElementFilter".
the RocketConduitSender state machine calls that method on entering the state "on.working.notOnGround" to enable the FilterInversion and again on exiting the state to disable it.
Calling this method flips the Boolean value "invertElementFilter" on the Def of the state machine. THIS is what is causing the bug: The Def of a state machine is shared between all instances of the same state machine with the same parent, in this case all that are attached to Gas/Liquid Spacefarer Input Ports . This means calling that method on one of these Gas/Liquid Spacefarer Input Ports inverts the filter on ALL Gas/Liquid Spacefarer Input Ports, causing all landed (and blocked) ports of that type to start dumping materials. (Since porting the liquid/gas inside takes priority over dumping, the bug only appears on ports that have their outside pipe blocked.)
How to fix:
Fixing this is fairly simple: Move the "invertElementFilter" variable in the AutoStorageDropper from sitting in the Def to a location where it is no longer shared between state machine instances with the same parent, for example a local boolean variable inside the state instance.
I have attached a (Preview Branch) save file that contains a setup to reproduce the issue
(the interiors are smaller because I used a mod while creating them, for a similar reason there is only a terrania planet)
In that savefile you will find two rockets:
- Bug happens in here (referred to below as "landed rocket")
- This will cause the bug (referred to below as "space rocket")
by default, everything works as intended.
"Bug happens in there" has gas and liquid pumping through it, while the outputs are blocked via shutoffs, "This will cause the bug" is setup to cause the bug.
Start by launching the rocket "This will cause the bug".
Things that then can be observed:
- inside the space rocket, the liquid port will start dumping liquid (intended behavior)
- inside the landed rocket, the liquid port will start dumping liquid (bug)
- inside the landed rocket, the gas port WONT start dumping gas, since the gas port in the space rocket has its input flow blocked by a shutoff
Things I set up to trigger certain behaviors:
- outside the landed rocket is a switch that unblocks the outside pipes. Toggling it will cause the material transfer to take priority over the material dumping on the inside
- inside the space rocket is a switch that unblocks the gas flow inside. Toggling it will cause the gas interior port inside the landed rocket to start dumping gas (when the outside is blocked), as this triggersall AutoStorageDropper state machines attached to that parent type (in this case, GasRocketInteriorPorts) to go to their pre_drop state, having previously sat in "idle" and not going to a different state as being blocked caused them to be full, not triggering any OnStorageChange events
- landing the space rocket will restore the ports in all rockets to their intended behavior
-
1
-
1
A developer has marked this issue as fixed. This means that the issue has been addressed in the current development build and will likely be in the next update.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now