Yeah something is broken in this patch

Did the latest update of barotrauma break this for anyone else?

Or just make the airlock behave at any water level below 100% as if at 0%?

I'm trying to build a system where the lower airlock of my custom sub functions as a ballast whenever the system is in any of the A, B, or E states (functionally whenever the outside door is closed). It works, but with the caveat that it doesn't cycle properly out of the E state into the A state on account of never reaching 0% water level. Is there something I could change to make the E state cycle into the A state whenever the water level is at say, 90% or lower?

How do you open the .xml file in the sub editor?

Not sure if you're still into this project but it'd be great if you could add a version with a hatch (top and bottom) acting as the outer door.

It works perfectly.

It cant work and fxxk my submarine

Outdated? It dosent work. I powered pump and lights.

Nerd

@kwogger Ah, I had a feeling it was just me; the airlock I'm using has two hulls (EK berith, not my own design) so I used a weighted average to get an accurate reading, so that'll be where the decimals came from. In any case, works beautifully now.

False alarm!
It somehow appears that I got my docking set_state crossed with the navconsole's current_velocity_out :P

so I did add this to a sub, and in the editor test mode it works flawlessly

however in campaign the game hangs before the intro text shows and I can hear repeated cycling of the airlock indefinitely. ALT F4 is the only way out. Any ideas? (It didn't do this before adding the airlock)

@DeadMummy That's strange - water_% should only emit integers (source: https://github.com/Regalis11/Barotrauma/blob/d9baeaa2e12618380169dc3d8e3b4161653a9a97/Barotrauma/BarotraumaShared/SharedSource/Items/Components/Signal/WaterDetector.cs#L109) . I'm curious how you're ending up with decimal numbers.

The fix is fairly straightforward though of course - you appeared to have figured out a fix already. 😄

Another fix, same issue but on the pump; when the level is a decimal after 0, the pump sees this as empty without checking for decimals, stopping the state from progressing.
(ex:-100022,0,0,0.01 |pump:match, speed:0|core:no match, stuck.)
Easy enough to fix by modifying the Pump-RegEx level check: ┊(?!\k<level>(?!\.\d*))┊
-While I'm here, thought I should clarify my last comment was referring to the core RegEx.

Found a bug while implementing this; when receiving decimal values from the water sensor, the regex can get stuck in state=200. [ex: 200,0,0,89.099 does not match]
I modified the <level> group to account for this; [(?<level>[\d\.]+)], and that seems to fix it.
(Could also just be my use case, it doesn't do this on the demo sub)
Amazing work though, by the way!

@Finsterer Jeroid - You can either open the corresponding demo sub and copy the components, or place an item assembly. The demo sub has more customization options and explanations.

how can i spawn that in the Editor ?

Damn @Wokmaster, I didn't even think of that at all! That's a great solution.

@Wokmaster spectacular, works like a charm, thank you so much!

@Grimm Spector What I did is disable door control when something is docked. Rewire the cable that goes to set_state to both doors(or hatches) to input_1 and 2 of a relay, then wire output_1 and 2 of said relay to set_state of their respective door. Then wire state_out of the docking port to a not component then that not component to the relay set_state.

Every time something is docked, the doors will move freely. The pump can still be working if the outside door is closed but you can either add a switch to disable it or make it so that the outside hatch is always open when docked(which I did because of issues with hatches that are unclickable when docked).

To do so, connect state_out of the docking port with two wires to both input_1 and set_state of a relay. Then output_1 of said relay to set_state of the exterior hatch(or door).

Now the outside door is always open when docked and the inside door can move freely. The pump is also inactive.

Oh boy, ok I'll ... think hard on that and study the demo sub you made for it and see if I can figure it out, thanks!

@Grimm Spector That would actually require substantial changes, but I'll try to give a bit of a rough overview.

The core airlock cycling logic is where the majority of the changes are required. You'd have to modify it to concatenate the state from the docking port, and then update both the RegEx and the MEM library to take the docking port state into account when selecting the next airlock state.

You may be better off treating it as it's own separate state as well, as you'd want the pump to operate as a bilge while connected to the shuttle.

I'm trying to use this, but I on a docking hatch of a shuttle attached to the main ship, so that when people are in the sub they can cycle the airlock properly. What I want, is to check if the docking collar is docked or not, and keep cycling but don't fill with water. Trying to figure out the best way to do this, but it's fairly complex and I'm not sure the best way. Any suggestions?

@Angry Toaster By hatch, do you mean setting it up to use a hatch to go up/down as the exit? It should be a straightforward rewiring (in theory). How is it bugging out?

Im having trouble converting this to a hatch that leads outside, whatever I do I can't open it to get back in.

A supreme effort that I can certainly appreciate, having developed systems on my own custom subs that induced plenty of head scratching.

If there's one thing I've noticed, however, no matter how intricate or sensible a solution is patience for such things doesn't seem to feature much in online play. I added emergency override buttons to my own airlock, I noted that people just wanted to exit the airlock immediately and would always press the override buttons once they learned of their existence. It's a shame as I'd love to see my elaborate and hard work used as intended, that's just life I suppose!

When it comes to lack of player patience, I've begun to try to anticipate this and design my systems appropriately. Good luck with your future designs! I'll likely have a look at your airlock design to see if I can improve my own.

@Crazy Ivan - That's a pretty good idea! I tried a few approaches. Coilgun unfortunately has a tendency to dmgthe walls/doors (also does the wrong dmg type). Detonator systems in general are mostly single use.

Using a EDC is close, but a few issues:
- Does burn dmg
- Stun is a bit long
- Lots of particle effects

If you want to implement it for the button doors, here's some tips:
- Wire a RegEx to the Concat with these settings to trigger if the airlock is less than 80%:
Expression: ^100100,\d,1,(?:\d|[1-7]\d|80)#
Output: 1
Empty false output
No "Continuous output"
No "Use capture group"
- Setup the EDC w/ a duration of 0.05 to minimize particles

I've left it out of this workshop item for now
- Overall a bit unrefined and non-intuitive for players
- Flooding is fast enough to rarely trigger it
- Baro in general doesn't have water hammer damage

Let me know if this is enough info to add it into your builds; worst case I'll make a separate workshop item.

Excellent work. It is perfect. Thank you for making it with click doors, despite the added difficulty.

I have a crazy idea: is it possible to simulate water hammer when the player opens an underhydrated airlock to the sea? That way there's some penalty for skip-cycling to exit. (Interior flooding is already the penalty for skip-cycling to enter .) One way might be a hidden non-interactable/non-swappable turret in the airlock pointed at the inner door with invulnerable coilgun ammo that fires once when the outer door opens if the airlock isn't already 100% water.