Stationeers Programming a Custom Airlock

The standard airlocks can do most of the things you want in the game but sometimes it is handy to be able to customise their operation for a specific purpose. Today I code four different airlock setups. This is a code heavy project build so feel free to skip this one if dont like coding.
Workshop link: steamcommunity.com/sharedfile...

[@alecisla]

Mick, you're by far, the best KZbinr when it comes to Stationeers. I'm still to this day going back and watching old videos to learn how to do things, your content is quality!!! Thank you so much for your time and effort to put this videos together! .. and I know it's difficult to make a tutorial about something, because the game keeps changing, but once the Trader Updates stop, could you please consider making a tutorial on how to get them to land, maybe writing a new code to track them, etc... Thanks!

[@TallinuTV]

I see you fixed this at some point after it, but for 36:50 -- It's incredibly slow because a passive vent and a single pipe section provide an extremely small buffer for an active vent to pull from. It can only access the volume of gas already contained in the pipe network on each game tick -- it can't "suck" air in through the passive vent at a realistic rate, because it takes a full tick for the passive vent to refill the pipe to ambient atmospheric pressure. This can be worked around in a couple of ways: 1. By adding more pipe segments and/or inline tank(s) to the pipe network between the passive and active vents (it can stick off of a T, it doesn't have to be linear). That way the volume available in the pipe network is larger, so the active vent can transfer more gas per tick despite that gas being at only ambient pressure. (I believe active vents have upper limits of their own, though.) 2. Instead of using a passive vent and a pipe network at ambient pressure, use an inline tank (before they existed, extra pipe segments did the job just fine) and when the airlock is evacuated, that atmosphere just gets stored in the tank. This can result in much faster cycling due to the high pressure in the tank, but has the drawback of not refilling automatically if the pressure in the base is lower than what the airlock is trying to pressurize to, which can stall the cycle. I used pressure and back-pressure regulators to control the contents of that tank to prevent this, but if you don't mind having less-optimal repressurization speed, option 1 is much simpler (and still much faster than what you were experiencing).

[@dvdraymond]

Thank you for posting this. The version I came up with had way fewer features than this. Nice work. Some thoughts from when I was playing around though: -The 2 vent and 1 vent versions can use the same code if you use Branch (Relative) Device Not Set wherever you're using the second vent. -Alias lines are dynamic run-time code. So instead of duplicating all the code, 1 large block for side A to side B, and another for side B to side A, you can have a small section that checks for which direction you want to go, and re-alias the doors and vents so you only need 1 block of code that uses fromDoor, toDoor, fromVent, toVent. The names that show up on the pins will get switched around as it runs, but it saves code lines and helps avoid making a change to the code for one direction and forgetting to change the other direction. Pseudo code: Check_Direction: {code block to set r10 to direction. 1 for A->B, 0 for B->A} breqz r10 3 jal setAtoB j AirlockSequence: jal setBtoA j AirlockSequence setAtoB: alias fromDoor d0 alias toDoor d1 alias fromVent d2 alias toVent d3 j ra setBtoA: alias fromDoor d1 alias toDoor d0 alias fromVent d3 alias toVent d2 j ra AirlockSequence: s fromDoor Open 0 s fromVent On 1 ... s toDoor Open 1 ...

[@cowsareevil7514]

That would make the abort functions difficult and as you mentioned error checking for asymetric airlocks, but it should be possible.

[@ConnorArchibald]

use The Doors to Break On Through to the other side. Watch the volatiles or you'll Light My Fire! Hello, I love you for another great video! I am the lizard King!!

[@ratchet1freak]

14:00 you can instead do a wait loop until the "idle" of the closing door is equal to 1 that way even with super slow doors it will work instead of having to spam yields

[@tinygriffy]

Thought that too, slow door might not close within 2 yields... I wonder if wreckage or something can block the door, maybe in future versions...

[@cowsareevil7514]

To make it very multi purpose code that would be a better way.

[@lonjordan3019]

This is awesome. I really like seeing how you code multiple options into one IC. Will look for this on the workshop.

[@bobgsmith101011]

Great work as always. On Vulcan you tried to synchronize 2 airlocks. You can probably do that now by sending a signal to the ic housings. Oh and more graphs 😁

[@cowsareevil7514]

That is true, I would be able to get it to work properly now. After sooooo many hours, I am still learning new tricks.

[@firstlast9923]

If you use boolean logic you can avoid having so many different loops to make it work. Additionally I've found using atmos to vac and vac to atmos airlocks to generally be nicer as you only need to worry about one side so you can batch write to multiple active vents for a faster airlock.

[@cowsareevil7514]

Batch writing multiple vents will become very important when people start trying to build trade hangars that have to vac large rooms.

[@tinygriffy]

I love it ... Is it in the workshop yet ?

[@cowsareevil7514]

It is now

[@Rukkus333]

Thank you!

[@adamhawksworth2039]

Why the need for the IC chip, housing and program? This can be done with a console screen, an advanced airlock board. Or have I missed the point or something here?

[@brandonlaird6876]

You could have it look for things other than pressure such as outside toxicity levels. Or a link to your suit and the door won't open unless your helmet is closed. Or automatically activate when you enter the airlock (or start switching to outside if the outer door is closed when you approach). Or switching all airlock doors so they're always ready for you whether you're inside or outside. Just some ideas. Obviously not needed for normal operation.

[@cowsareevil7514]

Up to this point I have always used the vanilla airlocks and then manual operation when I wanted something different. Now I can automate the something different situations too.

[@hoveringgoat8061]

This isnt a volcano lair what the hell! :p This is cool. Ive actually been meaning to figure out airlocks. Still have all manual doors and air controls on my bases.

[@lionllew8459]

It's an open and shut case.

[@xares420]

When I started watching, the first thing I thought was I hope he integrates the pass through feature that you have as a separate script. You didn't disappoint! I'll definitely be using this one. What language do you code in in real life?

[@zairev3438]

I ussually go for 6 vents in airlock into buffer pipe and decide "direction" of gas transfer with turbo pumps from buffer. Make it super fast even in high pressurized enviroments. Btw, how about some sensor in airlock so it trigger cycle automatically without having to press buttons?

[@cowsareevil7514]

Nice idea. I was trying to think of a way to handle multiple vent. I do prefer the button press to stop accidnental triggering although a bulkhead door with blast doors and sensors would be handy.

[@Yotanido]

I feel like a lot of the code could be simplified with function calls. Even for the bulkhead, your wait loop is duplicated. Why not just have a waitButton function and call that instead, have it return once a button is pressed and wait otherwise? I'm not going to watch the entire video, but I suspect this is only going to get worse. Am I correct in assuming you end up having two vent loops and two pressurise loops for atmo-to-atmo airlocks? Each one could just be a function. Put the device you want to check in a register (let's say r0) and use indirect referencing to access it (dr0 in this example) Not only does it use less code, when you then see lines like "jal waitButton", it also makes it much easier to read, rather than having the entire loop there.

[@jojoskunk]

omg i was trying to make a custom airlock with volume pump since i was playing with elmo realistic atmospheric mod. the vent are not good at pressure change so i try to match them with volume pump in series.

[@Elmotrix]

it's way easier to accept not having a perfect airlock and give up at

[@JoelleTheAbsurdist]

@@Elmotrix Gezz, I wish I'd known you'd already figured it out... I had to look inside the the game code to figure the doors out. Which video do you show it in?

[@jojoskunk]

@@Elmotrix I was thinking it was a pressure difference thing. Outside vent pressure and inner vent pressure, so i was messing with pressure in the pipe to make it faster.

[@Elmotrix]

@@jojoskunk pressure difference does contribute, so depending on planet adding a volume pump behind the active vent can help (on venus you must), but you'll never get the airlock anywhere near as fast as in the base game if you aim for perfect vacuum.

[@Elmotrix]

@@JoelleTheAbsurdist moon series ep 9 :)

[@ausvampire]

Maybe you could use sleep instead of double yield ?

[@cowsareevil7514]

Yes, If I ran out of lines I would have come back and replaced them.

[@queenA6db]

how do you set up a creative test world? i still havent figured that out

[@alecisla]

When you click on "New World", on the main menu, look at the bottom left corner, where it says "Custom World"... there you choose if you want Creative mode or not.

[@queenA6db]

@@alecisla does that make it so you dont have to deal with water and food though? i have seen that setting, i just dont know how to set up anything else

[@hoveringgoat8061]

@@queenA6db nah but i think you can modify the XML doc for the save easy enough. stationeers > saves > your save. Open world settings.xml (you can open in notepad or whatever) Then find . Should have all the rates there. You can set em to 0 or whatever you want.