It`s just a small server for myself and some friends and it`s pretty much only me that uses scripts.

The sim speed is a steady 1 and I have not heard any complaints about lag. I do have some lag sometimes, but I don`t have a very good internet connection.

When the doors stop too early, there is only a thin opening. If it was real life, I`d say it would be about 2-3 cm. Hope that helps you imagine the gap :P
I get the impression that the PB sometimes skips ahead a bit compared to the animation.
I`ve started keeping an eye on the door that is closing, so that as soon as I see that it has stopped too early, I cycle the lock again. Never had it stop twice in a row when I do that.

Zarkash, also I would like to know how 'closed' the door gets before turning off, both in what the 3d model looks like as well what the percentage readout on an attached LCD panel shows.

Thanks,

Thanks for raising this issue, Zarkash. I have not tested this on a multiplayer server, let alone one that is under load.

The script really should wait until it can detect that the door is fully closed. I suspect the lag is somehow causing the script to "skip a step" or something. I could see about making the script wait a little longer until it is closed. Perhaps I will have to make a house call to a server that allows scripts to see if I can recreate what you experience.

Although I don't fully understand multiplayer yet, please, Zarkash, let me know the conditions of your server: is sim speed okay when it doesn't work? are there many players on the server? is you fps pretty standard? Can other players recreate the bug on their own grid, too? Can you recreate the bug in a single player game as well? Answers to these may or may not help me.

When I get the time, I will investigate this.

Is it possible to make it slightly slower? I am using this script on a server and it happens quite often that the door won`t close properly before being turned off. This breaks the seal and the airlock stops working

Thank you for this nice script. I added a sensor to avoid pressing buttons and it's really nice.

Herr Doktor, are you hell bent on solving this by scripting? Are you not interested in the solution detailed in the section "Airlock Issues"? the one where it uses connectors to isolate the oxygen tank?

But if you really want to try writing scripts then go for it. I can try to help you if you need it.

But an airlock like this really helps for when I start running low on ice. I used to improvice by having a chamber with a perpetually depressurizing airvent, as long as I close the door behind me the vent does what it can before I open the next. Really the only time the vent would need to turn off is if only the inner door is open, since it'll just cause a ventilation loop.

Sadly, that's all I know right now. I'll look over that weblink and see what I can do. Maybe I can blindly make a miracle happen.

I suppose if I'm a position where I'm generating so much oxygen that it breaks the airlock, I did my job well enough. After all, the only time you can have too much air is when there's a fire. xD

I am not a great engineer yet, so I can't/don't calculate how much of what thing I need for a grid. So I just err on the side of caution. 1 OTank? Why not 10? 1 Reactor? 4 of them plus some hydrogen engines in case I run out of Uranium. Plus I only play singleplayer, so it's really easy for me to end up have a surplus of o2 and h2.

I kinda take pride in that, security in redundancy.

Honestly, you are on to something. I wouldn't even have to specially name the tanks. I can just grab all Oxygen Tanks on the grid (well, I guess the ones that are piped up) and only if they are all 100% will the outside door automatically open.

If I do this, it defeats the purpose of the airlock, which is to preserve oxygen, thus saving on ice or whatever. So if a grid is constantly filling the tanks, then the emergency-open will always activate. This comes down to grid design, i.e. it is the engineer's fault, not the script, heheh.

Almost everything I learned was from this: https://github.com/malware-dev/MDK-SE/wiki/Quick-Introduction-to-Space-Engineers-Ingame-Scripts

I do not recommend two two separate scripts with the same blocks, or even on the same grid, if you do not know exactly how they operate. They are clearly in conflict with one another.

Remember that a player cannot get truly trapped; they can access the panel on the door, switch off the ProgBlock, switch on the door, then open it. This however, is still not the desired method for this script, but it is a work around until I think of something better (and get around to implementing it).

I did run a test with this though: https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=2021393659

By naming the doors the exact same, and changed the suffixes from "interior" and "exterior" to "[ALI]" and "[ALO]", both the scripts try to work at once. The doors flicker on and off to fast to not be opened, and by shutting off Airlock Managent Script, the Simple Airlock begins it's work right away.

I'll try to look into it further, maybe reverse engineer some more code, and I hope what I found helps you.

If you know where to find scripting info for SE, may I see it?

I've long since given up on controlling the OTanks aside from setting them to Stockpile. Granted having a button to suck up as much air in the ship as possible could be useful, it's not worth worrying about.

All that's needed from the OTanks is the Oxygen Percentage.
Maybe:
if OTanks == 100;
unlock the doors
if door 1 is opened
lock lock door 2
elif OTanks == 0;
....

Like I said, very little understanding of C#, and I don't know the variables for SE. Isn't like there's a coding wiki like for Garry's Mod.

The main goals for fixing this is making sure that the player doesn't lock themselves out of their ship or in the lock. I swear that lock can quickly become an asphyxiation chamber when it tries to pressurize without any o2 to pressurize with. And a fully oxidized moonbase isn't worth much if the player is locked outside because the chamber can't empty.

Oh ya, so I don't (at least not anytime soon) plan to add Oxygen Tanks to the list of blocks that the script looks after. I didn't want it to be so advanced that it does that. If I recall correctly, there isn't even a way to stop oxygen from being pumped into the tank. You'd have to control all the connected O2 generators, and switch them off, which is way too invasive, and would halt H2 and O2 production for the entire grid. Anytime an Oxygen Tank is on, and has a connected O2/H2 Gen with ice, it will start filling up.

Although, I still want to add a bit of code that will "time-out" eventually, and open the door letting the air escape. I would like to avoid adding more "required" blocks if necessary.

Let me know what you think, though, Herr Doktor. This is only my opinion, after all.

Any luck? I've been trying to make sense of the script with my *extremely* limited knowledge of C#. My best guess it that the player should have a group of Oxygen named whatever, and have the amount of oxygen in that group be measured.

If it reaches 100%, it should into a second mode based on the Simple Airlock Script. At this point, a door can only be opened if the others are closed, and as long as that door is opened, the others are locked. The open door will autoclose, unlocking the others.

This way the player won't accidently be trapped in their ship for hours waiting for their oxygen to run low, but they won't have to risk venting all of their air out either.

I'm doing some tests to see if I can run both scripts side by side, so if I did have to disable this one, it'll have a fall back already working.

That is a great idea Herr Doktor, and at some point I did consider it. I recall you can actually get trapped in the airlock if the oxygen tank is too full. And the solution would be to shut down the airlock system and manual open the doors. But your idea is great; perhaps it can detect when it is 'stuck' depressurizing, then it gives up and opens the appropriate door anyway.

Thanks.

Sorry for the late reply.

The Airlock was at 84% Pressure and was fully sealed with the door named "[ALI]". I removed the inner door; replaced, renamed, and regrouped the door; and recompiled the code. I also used two vents to pressurize the test room to 100%, which most likely pressurized the airlock to 100%.

The Airlock now works.

I'm still not sure what I did wrong, but at least it works now.

I did find a funny issue. It cannot function if there isn't enough room in the oxygen tanks for the air in the lock. Since it can't depressurize the room, it just get's stuck attempting to depressurize until there's room. It won't open the inner door either.

Is there an override function to force at least one door to open, even if it means venting the lock's air into space?

Hi Herr Doktor,

Can you please state the precise message?
And just to be as clear as possible, by 'terminal' you mean you went in to the terminal of the programmable block, and it displayed some text like "Airlock 1 Status"?

There is an error message there that can say "Not all InDoor are functional"
If that is your message, then this means either the door is damaged below the functional line, or there are no doors in that airlock group. The InDoor must have [ALI] in the name, and it must be in a group with [AL] in the name.

If you have all of this satisfied, then I will need more detail as to how your airlock is set up.

I encountered an issue. The terminal says the InDoor is nonfunctional, but the door is just fine. What am I doing wrong?