Pressurization not working properly

Hans Peter shared this bug 2 years ago
Need More Information

local game, online friends only.


the airvent signal gets yellow, it looks like airtight rooms are not airtight anymore from time to time. restart fix this. i dont know how to trigger it, maybe if a player leaves the area.

is there a way to turn off tempeature feature?

Comments (54)

photo
2

Same here but on a hosted server (my own).

I realized that this only happens when i dock a large grid ship onto another large grid ship (with landing gears so far, haven´t tested the alternatives).

After doing so, both ships get depressurized and cannot be repressurized until i restart my server.

Docking small grid ships on a large grid ship is fine, no issues here. Docking large grids with stations - haven´t tested it yet.

photo
2

we have a large grid station fixed on an asteroid and only small ships without landing gears, just connector

photo
1

Yes today i realized this also happens when NO ship is docked. There were two players on the large ship walking around and out of nowhere the whole vessel got depressurized.

I don´t know how to reproduce this issue yet, hoping this gets more support soon.

photo
1

Read full comment

did not mean to post it here.

photo
photo
2

This pretty much breaks the game for me for this issue occurs quite frequently on my server.

Have to restart it every time - not a suitable solution on a MP Server...

I still don´t know what may be the cause, landed ships of every size and sometimes it happens, sometimes it doesn´t.

Anyone yet know how to reproduce it ?

photo
2

Yep same here.

We built a large grid ship and when another player enters it or lands a ship we don´t have any pressure on the whole ship.

photo
2

Same here on a multiplayer server.

Everything works fine unless at last one person is close to the pressurized grid.

After all users leaving the grid and re-enter the grid again the lights on the air vent shines yellow.

After a while, the room is pressurized again. I don´t know what it triggers.

Maybe an initialisation problem.

photo
2

I mean: "Everything works fine as long as there is at least one person near the pressurized grid."

photo
photo
3

Hello, Engineer!


Thank you for your feedback! Your topic has been added between considered issues.

Please keep voting for the issue as it will help us to identify the most serious bugs.


We really appreciate your patience.


Kind Regards

Keen Software House: QA Department

photo
1

Since another month is gone now and no solutions to be found:

When can we expect more to this issue ? Any information if this will get fixed during the next year ?

Sorry to ask again but this issue just makes it impossible to play on ANY Server for me and some friends.

photo
1

Had to edit my comment because of some issue with Chrome Browser (works with IE).

I started experiencing problems with pressurization today. Rooms depressurized and at first the vents showed "Not Pressurized". I quit out of game and loaded it again. Vents start to pressurize, but they do not keep at 100%. I did an experiment where I blocked myself in a 1x1x1 room with vent; I could pressurize to 100%, but if I turn off vent, pressure drops. The larger the room, the faster the pressure drops. All blocks in ship have 100% integrity.

photo
1

After several switching the airlock of the base with pressurization bug,sometimes it fixed but airvent uses tons of oxygen for pressurizing the area.

photo
1

Noticed this bug on my station's hangar, pressurizes fine sometimes but can get stuck yellow. Occasionally removing a block then putting it back un-sticks it and it can be pressurized again though sometimes that fix makes it take a lot of air (and time) to pressurize and depressurize. Restarting the server fixes it and everything works like it should.

photo
1

Moved world to SP from MP server, issue went away and never came back.

photo
photo
1

Just came across the same issue. Also can reproduce this relyable in my current save.


Restarting the game fixes this ... for simply a single other interaction

photo
2

Hi guys, thank you very much for your feedback.

X39: Please, can you provide the save with info how to reproduce the issue? It would be very helpful for investigating the issue.

Thanks again and have a nice day :)

photo
1

I have this issue and tried multiple ways to work my way around it. What (kind of) seems to work is to use a separate system for O2 production and air vents that is completely disconnected from the normal conveyor system used for items/ores/materials etc.

O2 pressure will still be lost randomly when exiting/entering buildings and rooms or when removing/placing blocks but with a separate system the air will be replenished immediately whereas with a combined system I would get one green light on the air vents but they would not replenish the air lost.

Another thing that happens when the air vents get stuck is that my O2/H2 generators will start running at full power but will not produce anything, even if I'm sitting in a cockpit. Restarting the generators will sometimes fix this but not always. Recycling base power does not seem to have any effect.

photo
1

Could have sworn i pressed post ...

https://steamcommunity.com/sharedfiles/filedetails/?id=1959030791

Steps to Reproduce:

  1. Walk through the closed Door to your right, wait until other door opens
  2. Walk through now open door into the "hangar area" until the door closes behind you
  3. Repeat the steps 1 - 2 into the opposite direction
  4. Move to the buttons panel and press "1" to open the hangar doors
  5. Repeat Step 1 - 3, notice that no air vent in the current grid is working anymore (Yellow light)


Note that this world uses a very basic script for the detection of direction (to properly pressurize or unpressurize).


Kindly Regards, X39

photo
1

Hello - again nothing new here ? This pressurization bug is the reason i quit the game for MONTHS now - still no fix ?

What information do you need ? How can we help ??

photo
1

I see this issue quite often, especially in servers. Some air vents suddenly show not pressurized even though the room is sealed. Sometimes opening and closing the doors fixes the issue, but not all the time.


I've also seen this in my single player game when working on airlock script. In it I added a "decontamination" option which basically opens all the doors for 60 seconds to vent all the air to space. This feature seems to often break several vents randomly with this "not pressurized" issue, especially when doing this "decontamination" several times in the row. Restarting the game fixes the issue.

photo
3

So just now occured again this morning at 08:38:

Having a small area fully pressurized, opened a door to space - boom pressurization level down to zero. Now closed the door again and the vents still show "Yellow" - air not coming back.

The room still is completely sealed.


The thing is, now if i open a door to an attached room (also fully pressurized), the air of this area also gets sucked out to the first area, making this new area also "yellow" on all vents. Same with the next attached one and so forth.

Just like the disease spreads from one room to the next :)

Oh and just to be sure: This happens in a vanilla world as well as in a modded world.


Got the log file and the world itself to dropbox: https://www.dropbox.com/sh/y23faxbk5lr9ozi/AAAREQMQlzpY9mcdcfEEyctZa?dl=0" rel="nofollow" target="_blank">https://www.dropbox.com/sh/y23faxbk5lr9ozi/AAAREQMQlzpY9mcdcfEEyctZa?dl=0">https://www.dropbox.com/sh/y23faxbk5lr9ozi/AAAREQMQlzpY9mcdcfEEyctZa?dl=0


If you need anything else feel free to contact me.

photo
1

I ran into this same problem on a dedicated server. My ship was originally built airtight and pressurized fine. It had 2 separate compartments with their own air vents. The upper compartment was fine for several days -- it even re-pressurized correctly after I derped and opened both airlock doors at once.

Eventually i went into the lower compartment to check something, and when I opened the door, the entire ship de-pressurized. After closing the door between upper and lower compartments, i was able to re-pressurize the lower compartment, but the upper compartment remained bugged for many days afterwards. I logged in and out many times and the server was res restarted on a regular schedule every 6 hours. Yet the problem persisted until I stopped playing on the server.

photo
4

Frustration would be less a thing if someone actually would respond to this issue. I don´t think only so few ppl have problems here - get ppl to vote here !

photo
3

Happening again and again, Keen what more information do you need ? Please advise

photo
3

I had to restart a map on my dedicated server because this was happening, out of nowhere(from my perspective) rooms that were previously pressurized suddenly weren't anymore. Same issue as reported, on a restart they were ok, but when I would use a door or let it otherwise become unpressurized, it wouldn't recognize the room as a whole. Even newly constructed rooms that were just a closed block out of armor(Full square) and all the necessary stuff inside of it didn't want to pressurize anymore.

photo
3

We have been having the same issue on our private MP server. Server restart fixes the issue as does copying the grid and pasting it back into the world, or pasting it into a creative single player game... very annoying.

photo
4

Hello there.

The same bug occurred multiple times while I was playing on a multiplayer server.

We encountered this problem as we tried to pressurize a base on an asteroid. Of course, we triple-checked the air tightness of the whole building before considering this anomaly as a bug. But the fact is that restarting our server solved the problem... at least temporarily. Since then, our base regularly lose its air tightness - often when we interact with doors (which are obviously between fully pressurized rooms).

It is quite a game-breaking bug, since we must frequently restart the server in order to properly play on it. Unfortunately, it is difficult to provide information that weren't already mentioned above.

Please consider to investigate further this bug (if that's not the case yet). Your game is really fantastic, but would be even better without this kind of problem. Keep it up !

Best regards,

A fellow Engineer


EDIT : I forgot to mention the fact that sometimes a room or another stay pressurized when the others are stuck in a bug state, even if its doors are open.

photo
2

Hello again,


I'm actually on the same multiplayer server than Draco Nocte (the one who posted above me) so my post will not give you any further explication of the observation we could have about this bug. Apart for the fact giving more visibility to this post.


I just came to convey to you all my gratefulness about this game, I discovered it by a friend's recommandation weeks ago and i'm getting closer to the 200hours now, just fell in love with this game.

One more time, i invite you to investigate on the bug, if it's not already in process of course, and I hope that this is gonna be fix soon we will be able to fully enjoy the game again.


Warmly,


A noob engineer who prayed Klang this morning.

photo
3

I am beating a dead horse on this topic but I too have a pressure problem. Built a space base. Found and closed all air leaks. Built air vents for two sections (inner hub and outer ring). Pressurized both areas and maintained pressure for the last week. I installed sensors on all sliding doors to automatically open and close. Pressure still working. Today, pressure failed. I have added no interior pressurized space. I have 8 oxygen tanks at 100%. I have 8 oxygen farms and 5 O2/H2 generators with plenty of ice to spare. Can't figure out why they stopped working in two separate pressurized zones. I have now closed the game and restarted it while I am typing this. After the restart neither area will pressurize with all 15 air vents showing one yellow light so the problem persists. Another related issue that I have noticed is that the Medical Room and Survival kits will not supply oxygen either. They are not co-located and reside in each section. I can go to a docked ship and get oxygen replenished from the onboard survival kit.

It appears that O2 is not passing through the conveyors. I did get O2 from a Cyro chamber when I entered it.

photo
3

Same issue here, my brother and I have spent the past few *weeks* trying to figure out the cause of this bug even going so far to play without any mods (which we hate to do) and frankly we are reaching our breaking point in patience as it seems nothing has been done to *fix* this bug.

There is a thread about it on reddit and also one on steam about the problem; I really do wish a solution could be found since it makes the game unplayable after awhile (and having to constantly restart the server is not a solution)

photo
2

The issue is very aggravating to say the least. Whatever the problem was has cleared for me and the base is now pressurized with no action taken by me. it was 4-5 days of no pressure and then it started working. I have no idea.....

photo
1

It seems to be somewhat related to the grid size from what I can tell. On a moon base, it started doing this where rooms would not pressurize. Meanwhile a hallway that is not sealed up is trying to pressurize and venting all my O2. After turning off the leaking vent, I started to build a wall around a vent and it suddenly pressurized again. I open the door to space and the room doesn't depressurize until I CLOSE the door.

At the minimum, is there any debug tools that we can use or logs that give us some idea why this is happening? It completely ruins the game especially when I instantly die because the room pressure has gone into the NEGATIVES and my suit's power drains instantly trying to keep me warm.

photo
photo
1

Yep. All this. I've got a station, multiple floors connected by an elevator. Leak detector shows no leaks. 100% oxy tanks x4, vents right on top of those 4 tanks. That room won't pressurise, neither will the crew quarters (individual or common) on the floor above. Yesterday, pressurised. Tonight, not pressurised. Very aggravating/confusing. Last time, a sacrifice to Clang fixed the problem... that trick not working tonight.

I've also had it seem like the o2 gen isn't working, walked away and come back to find it 'suddenly' working again, untouched.

photo
2

Im going to leave a comment here as well. This is still very much and issue. And makes playing survival MP an absolute pain.


Private host with brothers. our ship is perfectly air tight with self closing airlocks. hours will go by and randomly, entire floors will become depressurized with no oxygen.


the ONLY will to fix it is to reload the world, and the ship instantly gets all its air back.


Ill share a world if need be, but im not sure how that helps or matters since this seems to be such a common issue.

photo
2

I have this problem too, at the beginning I destroyed the rooms inventing many theories to try to work.

Basically, when it occurs, it appears to be general or in an intermediary region.

I used a plugin that displays where the leaks are and shows nothing.

photo
2

I'm also having a similar issue. Built a large launch silo underground. Just been layering rooms around the central chamber. Drilled out an entire floor and sealed it up airtight then pressurised it. Just separated that floor into 4 rooms using doors and built a med bay. Added all the cosmetics and everything. Built a medical room for healing/respawning, then depressurised the room so I could put a hole in the ceiling without wasting the oxygen, and connect the medical room to conveyor system for H2/O2 replenishment. Repressurized the room and the vent just kept pumping without increasing the pressurization %. Turned the vent off then back on and now the entire floor, including all the other isolated rooms are claiming they aren't pressurized even though I didn't make any changes to their armor blocks. Tried reloading and reconnecting the system but I just can't seem to fix the bug.

photo
2

Still an issue.

Got a large hangar with 9 air vents connected to oxygen tanks and the rest of the conveyor system.

Got timer blocks setup so the room gets depressurized first and then opens the hangar door. Works fine.

But when I do the reverse, sometimes the air vents will put pressure in the hangar and it takes about 15 seconds to fill. Sometimes it takes ages to fill (1 minute and just 0,3 pressure on the room). And sometimes the air vents say there is a leak and do nothing.

It's basicly ransom, everything is sealed because sometimes it does work.

I'm on a self hosted dedicated server with 2 persons. Using quite a lot of mods, but guessing the same issue is without mods?

Restarting the server works.

photo
1

I'm getting this from time to time on single player. Sometimes the airtightness spontaneously fails while I'm sat in a chair or walking in the cabin. Sometimes it fails briefly, sometimes it fails until a reload.

photo
1

Found a pattern: The pressurization failure occurs the moment that my airtight hangar doors (which are on a separate airtight space, within the same grid) finish closing. I often do this remotely before departure, but there's plenty of time to get out of the flight seat and walk around before they finish closing.

Opening them seems not to cause any trouble at all. I've attached a blueprint of the ship in question if it helps.

photo
1

It seems this isn't a reliable repro after all. )-:

photo
1

Hello Brian!

Can you please supply some reliable steps for reproduction on this?

Kind Regards

Laura, QA Department

photo
1

I'm sorry, I can't yet. I'm fairly sure it happens at the moment that a door closes, but it certainly isn't every time. I'll keep working on it.

photo
photo
2

Got this issue with my large grid ship. On MP dedicated server (I'm not the admin), both in space and on planets, with and without mods.

The ship is sectioned into small, medium and large compartments. Smallest has an internal volume of around 328 cubic metres, while the largest has a volume of 4125 cubic meters.

All sections pressurize with little trouble, however, frequently when opening a gate (frostbite), or sliding door the pressure will go negative, somewhere around -9000. This has caused my 3 o2 tanks to completely empty trying to re-fill the volume, but usually the system just bugs and shows no lights on the vents.

Closing the gate / door does not restore airtight status.

Re-opening the gate / door, sometimes zeros out the pressure again, but except for rare occasions, a server restart is required to fix the 'leaks'.

I also noticed that the area immediately around my ship, on the outside shows high oxygen, so it seems the air tight calculations are reading an area extending to the outside of the ship - also explaining why refilling a hangar after restoring air-tightness can use up all my o2. I've confirmed this with an exterior vent - which when set to depressurize shows exactly the same pressure as the previously bugged hangar vent. Having the hangar set to pressurize, and the exterior vent set to depressurize seems to just cycle the same volume of air through the system, neither gaining any ground. Again confirming that the airtight volume extends beyond the ship bulkheads.

The hangars use only vanilla blocks, no weird angles, and have no gaps. Blocks used:

Light armor blocks, light armor half blocks, sloped windows (not an issue as the volume behind the windows remains airtight unless deliberately vented), sliding door, gate, piston (in floor but capped off on all exterior sides), welders (in floor but capped on exterior side).

I can reproduce this issue by opening an exterior door, and occasionally by attempting to depressurize a space. Adding blocks to the hull occasionally causes the bug too.

This happens with and without o2 / vent management scripts.

Edit: I can't reproduce this in offline mode. Seems to be a MP bug.

photo
2

Still no reaction from ksh here ?

What Information do they need ? Is this report getting ignored still after over 1 year ? How can we help ?

photo
1

They always ignore their support requests and tickets, as well as most of the issues that arise. This specific issue is one that's spanned every version of the game and still without fix. They seem to be more concerned with releasing dlc than addressing the numerous bugs in game.

photo
photo
1

Randomly happens no real reproducible steps that I have found. I play on MP. Only fix is to restart the server.

photo
1

I am having this problem with an underground base on the earthlike planet. Sealed rooms with air vents will randomly have the vent indicators go black and the room will be depressurized when I go through the door. Next time I go through the space it will be pressurized. I thought maybe it was due to the weather feature being turned on, but turning off weather effects didn't fix the issue. This needs to be fixed!

photo
1

Disabling Oxygen and Air tightness, saving, re-nabling Oxygen and Air tightness seems to fix the issue, but it DOES need to be fixed. And it doesn't always happen to worlds. Some get it, others don't, and even if it DOES happen in a world, it may affect one grid, it may affect more....it's a literal dice roll whether or not it occurs. And they want more information. On something that you can't predict WHEN or IF it'll happen. I mean, I know they need steps to reproduce it, but with something like this, there ARE no steps to reproduce it. It just...HAPPENS, like it''s on some random number generator.

photo
1

I have the same problem, from time to time, I cannot pressurize my airlock but my base still has oxygen, when I open the door the problem spreads and I start to lose oxygen in every room I enter without being able to recover it. I think this is because I built a very large base for my computer, I have a ship near my base that can still pressurize without problems when this happens.

Restarting the server solves the problem, once it corrected itself and crashed again minutes later.

My computer is:

AMD athlon II x 3450

6 GB of RAM

Nvidia Gt610 2G gddr3 graphics

Windows 7

A related problem, when I depressurize a room it does not always remain at 0%, sometimes it remains at 0. (decimal) E-8,

photo
2

I'm surprised you can even play SE with those specs. Minimum RAM requirement on the store page is 8 GB Not talkin' down at ya, just impressed.

photo
photo
1

I'm running into this issue currently while hosting a MP server with 1 other person playing with me. My entire ship is air tight and Notice that I will loose room pressure from 100% to 1-2%, sometimes I would loose pressure completely. Other times I will watch pressure slowly climb from 1% to roughly 75%. this would take 30 minutes or so during the time frame (regardless of room size or a large amount of vents in the room). While the pressure climbs it will drop .5% every couple seconds. This happens to all of my rooms on the ship all at once big and small. My experience with this was on the large grid ship.

photo
1

Same - we're running a 1.197.069 dedicated server. We've just turned off all air vents. It kept bleeding oxygen out of the entire base. Periodically I would return to an airtight room to find that the entire room had depressurized and was using more O2 to re-pressurize - even though no blocks had changed in the room, and no doors had been opened/closed.

We've also had rare instances where a room would go to -500 or 600% pressure and never pressurize even though it was sealed and air vents were feeding O2 in.

photo
1

This hit me 2 days ago, 2 diff worlds on 2 diff saves. Fully airtight, full power, ice, etc. 2 vents and 2 h20 genies and still have room not pressurized. Smh

photo
1

Same problem rooms will not presureize but I have had times when walking back and forth through a doorway triggered it to pressurize again.

At one time before launch I had hanagar doors open and close and instead of pressurizeing it went -56,000 while I walked back and forth through the regular doors and open/closing hangar doors trying to figure out what was going on.

Got everything green and got rid of the negative pressure but now today it is all yellow again and will not pressurize for some reason and nothing has changed.

photo
1

Some friends and I are having the same issue on our server. Had part of our base pressurized. Just a few small rooms with a "dumb" air lock to the non pressurized area. (I say "dumb" because it's not one that has a depressurize vent to save o2)


At any rate everything worked fine for a while and then all of a sudden it gave us the yellow light out of nowhere. We've searched around and can't find any leaks, nothing has changed from before. We have plenty of Ice and the o2 tanks are full.

Our vents are connected to other objects like Med Stations and Cryo tubes. Do the vents need to be on their own independent connection? Has anyone experienced this issue who had that set up?

Side note:

I just thought about putting in a sorting conveyor set to force pull oxygen to the vent, I wonder if this would solve the issue. Will test and get back.

TESTED: FAILED

The conveyor sorter block does not work with oxygen at all

photo
2

It will often fail on all oxygen systems on the server, whether they're connected or not. It's like a memory leak or memory buffer problem - once it uses the data allowance up for keeping track of the oxygen systems, it just turns off. Doesn't seem to affect cockpits, more just pressurised rooms.

photo
3

This post needs more votes.

photo
1

Same bug, at this point the sever has to be reset every time someone leaves their ship to go mining. Get back and the vents seem to be endlessly 'sucking' when I get back even when the hangar is depressurised when I left.

But wait it gets better, when I then leave the hangar depressurised because even though I have sealed all bulkheads and doors the best I can do is it be yellow light, when I enter any pressurised areas of the ship the instantly 'bug out' and vent too, the only fix is to respawn the ship or base and or restart the whole server which is not tenable. It hurts because it's such a simple issue that is rendering the game nearly unplayable for me.

The trigger action seems to be using my connectors. When I return and drop my ore off via any connector (ship sealed and pressurised or not) it bugs out.

photo
2

Hello All!
I've been having a look through this thread and have tested X39's save from quite some time ago. For me, it is working as intended and although goes to yellow, then starts pressurizing as expected straight after closing the door and to green. Is it possible that some other people could supply some saves where this is happening? Also, please include reliable steps for reproducing the bug as it's really helpful!


  • You can access your save files by typing %appdata% into your Windows search bar and you will be redirected to the hidden Roaming folder. After that just follow: \Roaming\SpaceEngineers\Saves. There should be a folder with your SteamID and your saves.


Please zip the file and attach it here. If you are having difficulty attaching files you can optionally use Google Drive. When sharing a google drive link please make sure it is set to be downloadable by anyone with the link
Kind Regards
Laura, QA Department

photo
1

Hi Laura,

Much as I'd love to provide a saved game, saving and reloading is my go-to workaround for the issue. Whenever a pressurised grid "forgets" that it is pressurised, I save, quit to menu and reload. The problem has so far not been present in a freshly loaded game.

photo
1

Hello Brian!

I appreciate this is not easy to reproduce the issue. Unfortunately, I need to be able to reproduce it to report it so I'm hoping someone is able to provide a world where it's happened a few times in their playtime with it and I'll have the chance to reproduce it enough to report it :)

Kind Regards

laura, QA Department

photo
1

I think it has happened at some point in all of my games, but when is more random. i don't have steps to reproduce something I only ever observe happening, not cause to happen.

The only variable i can think of are long running games or servers. At some point air just stops working and you have to reset to get it working again.

photo
1

It has happened to me in several worlds and on online servers, I don't think the problem is in the world, when I build a station big enough with several pressurized rooms the problem occurs.

photo
1

Now that I think about it, it may be the size of the room that causes it, because it has happened to me every time I build a large hangar that takes more than 30 seconds to be pressurized with more than one air outlet (about 8 air vents).

photo
1

So I think I've found some issues with certain set ups through some testing of my own, regarding the "depressurization bug".

Something that seems to aggravate the system and cause the "bug" seems to be when the oxygen vent system is hooked into other conveyor systems. Especially if its connected into conveyor systems that are passing other major items like ore/ingots and components/ammo. The oxygen vent system should be on its entirely own line.

On my crews MP server we originally had our oxygen vent conveyor line set up in line with our Medical/Survival kits. Thinking that since both need oxygen to function they should be fine on the same conveyor system. (This system was separate from our other conveyor lines that are pulling from our mining vehicles to the refinery etc.) We were constantly having the pressurization system glitch out and not work properly. We'd reset the server and everything would work for a short while until it would eventually go back to not re-pressurizing and give us only yellow light when it should have been going green and re-pressurizing.

After the umpteenth time of this happening I went through and separated the Oxygen Vent system conveyor line from the Medical/Survival kit conveyor lines. Meaning our Oxygen vents were now inline together on a dedicated conveyor system for ONLY the Oxygen Pressurization Vents. The Medical/Survival Kit's in our base were now on their own dedicated line as well.

Now that our Vent system is on its on dedicated conveyor line we have not had any issues (knock on wood). So far this seems to solve the "depressurization bug" issue that we were experiencing. Does anyone have theirs set up on a dedicated conveyor line like this that are still having the issue?

If the "bug" issue resurfaces with this new set up for us I will certainly put forth my findings, but so far over the last week or so we haven't had any issues.

photo
photo
1

This is not a world issue. This simply happens after the game has been running for some time, same as the 'your graphics card may have overheated error'.

As such, keen should not be denying they don't have enough data when it's clearly some kind of memory issue. This happens in single player offline also. It happens more frequently when the world is big and the game has been running for some time (hence why people see it more in MP servers).


Stop labelling issues with 'need more information'. You are the developers and this issue should be clear to you.

It's becoming a tiresome sight on this support portal with the 'need more information' excuse put about everywhere.

photo
1

While I agree, the problem is that Laura P has to be able to demonstrate the issue to a developer before it can be raised with them. There are plenty of bugs on this site, and those that can be reproduced get escalated. Those that can't, don't. It's a simple heuristic, and it often fails us (as it is failing us here) but that's just how Keen's bugs are handled. Either one of us will stumble across a means of reproduction, or the bug will languish indefinitely.

photo
1

That's not how development works, at least not good development. This is clearly a bug, and should be investigated as such. The key points are how many have this bug (90 is a lot of people voting on here, and there are many duplicate threads), and how it happens.

Anyone going through the replies will know it's not a specific world issue. It's very likely something to do with memory, as I pointed out.

So the fallacy here is saying they won't investigate when they can't reproduce it from world files. Sometimes things need investigation. Keen has far more information than a lot of other developers do from it's customers, how do they fix the bugs?

A decent developer should be able to know where to start looking.

photo
1

It hasn't even reached a Keen developer. It won't, unless it can be reproduced by Laura or one of her colleagues.

photo
1

That's my point. It needs to reach a developer as it might not easily be replicable by someone. Not all bugs can be replicated easily, certainly doesn't mean they shouldn't be investigated by someone with actual knowledge.

Especially ones with high numbers suffering it. I can't understand why anyone would think that's acceptable in a development process.

If you don't believe me, go on a developer forum and pose the scenario.

photo
1

At least there should be an easy way of debugging, if they publish the source code I could find the error myself.

photo
1

They tried that. An older version is still on Github now. Trouble is, people are terrible, and piracy became an acute issue.

photo
1

I think if they can give us more debugging tools or maybe make a debugging build that logs additional things it would help.

I think another problem is there 'no mod' policy. I understand they can't debug mods but when a core system seems to be having issues and others are seeing the same issue without mods, they could at least look at the save file. I usually have some mods on and the bug doesn't show up until hours or work is done. A friend of mine I believe submitted a save file where they removed every mod, started a fresh game and was able to duplicate the issue after some time.

If it is indeed a memory leak that is causing the issues, there isn't necessarily easy instructions to duplicate; you have to play around and do things like a player and that means hours of playing until the bug reveals itself. It also could be more hardware specific; for all we know, the more RAM you have, the more likely the bug will show itself. Then again it could be less RAM.

Ultimately I think if there was a way to do more debugging on the player side like logs or saving the memory state of the game along with the save file so the developer can take a look, that would be far more helpful.

photo
photo
1

Bigger rooms to be sure. I've not had it happen in small block rooms, only large. Also, never in cockpits or anything that you sit in.

photo
1

hi there,


i believe i just found a way too 100% replicate the issue!


i have a back-up from our dedicated server that i can send you, but it is about 60 MB so i can't attach it to this message. I'd be happy to give you this back-up so your dev can look it up.


in this, you'll find a large grid ship named ''ATL-A'' ( a big red/black mobile base/factory ship)


This ship has a vast interior zone which is normally pressurized without any problems. in the back of the ship there is an airlock leading to an unpressurized hangar which is sealed from the outside by a hangar door.


as soon as anyone open/close the hangar door, the ships Air vents shows a ''not presurized'' status. Once that happens, there's is no way to presurized the ship back. the only way to re-presurize the ship is to re-start the server. on logon, it will work perfectly as long as we do not use the hangar doors. using conventional ''dumb'' airlock causes no issues.


i have successfully replicated the situation mentioned above 3 times today.


we tried finding air leaks using the ''buildinfos mod'' but the mod says there are none but it won't presurize


except ''Buildinfo'' (which we installed at our second occurance of the problems) we run completely vanilla on a GTX gaming serer (the hosting service you recomand on your website)


I'd be glad to provide what ever help i can to help resolve that frustrating issue.

photo
1

Hello enric!

  • You can access your save files by typing %appdata% into your Windows search bar and you will be redirected to the hidden Roaming folder. After that just follow: \Roaming\SpaceEngineers\Saves. There should be a folder with your SteamID and your saves.

Please zip the file and attach it here. If you are having difficulty attaching files you can optionally use Google Drive. When sharing a google drive link please make sure it is set to be downloadable by anyone with the link.

Thank you for the information on this too.

Kind Regards

Laura, QA Department

photo
1

sorry for the delay, was out of town and no acces to my computer


here is the files link, in them you will get the whole server backup, should have all you need in there.


https://drive.google.com/file/d/1i8L-l6TfixXlhUiGPyb0v69UMEIllJim/view?usp=sharing

photo
1

Hello enric!

No problem at all. I'm afraid that the file appears to be showing as corrupted for me. Is it possible to double-check it and resend it?

Kind Regards

Laura, QA Department

photo
1

here is the new link


https://drive.google.com/file/d/1TyLyERLXoJCD9aYXpNiV1hbvn01bIppi/view?usp=sharing


please note that i can replicate it 100% on multiplayer server, but i cannot replicate it in a local game

photo
1

Hello enric!

Thank you for the updated link. I've been testing this following your instructions and so far everything is pressurizing as expected (please see attached video) Am I missing any steps that you are taking? If so, are you able to possibly record a video? https://drive.google.com/file/d/1aNHECMFD4gb5PLXuKSUOp24YMGnQcDmP/view?usp=sharing

Kind Regards

Laura, QA Department

photo
1

Laura, you do not need a video. This has been explained very, very clearly to you, and you have the information from this, and many other threads with the same issue.

Clearly, this is a memory issue. The 3 clues which are constant throughout all these threads are:

It's more common in large world files

It happens after lengthy sessions

It's fixed on a restart, but happens again

As a developer, this should be obvious and the customers not constantly asked for more and more information which takes them time to get.

You need to:

Change status of this ticket away from 'Need more information'

Pass this onto the bug fixing team to replicate and fix.

Respond on here saying you have done so.

Investigate and look at all the duplicate threads with the same issue and update them accordingly (something which should be done anyway).


A video will show you absolutely nothing since there are no actual steps to recreate. All you will be able to see is the yellow indicators on an air vent showing it's not pressurised.

Personally, I think Keen are doing this on purpose to blame users for not coming up with enough evidence. This behaviour is evident in other threads too.

photo
1

Luke, the video is to accompany enric's save file. I mean, perhaps you just haven't complained enough yet, and if you just complain a bit more it'll get passed on to the developers without reproduction instructions, but I suspect (as I suspect you do too) that this isn't going to happen.

photo
1

Brian, did you read my comment? A video simply will show nothing. There is literally no clues as the steps which make this happen ingame - because there isn't any. This would be very clear had you worked in development at all. In development, sometimes bug don't have specific reproduction instructions because it's not do-able. Hence what I said about it likely being tied to some kind of memory issue.

How about you see here, where they gave the requested information and keen never bothered to reply: https://support.keenswh.com/spaceengineers/pc/topic/pressurization-not-working-1-196-012


And you'll see on there someone saying this has been an issue for a long time. Someone else said that they gave the exact information, but post was removed.

And if you look on your right under similar topics, you'll see some of the many many threads on here about the same issue.

Again, if you knew about development, you'd know it's incredibly wrong to keep badgering the user for useless information. Clearly this is a long standing bug that needs to be looked into by the bug fixers, not constantly stalled by front line staff going from a script sheet.

It's disgusting behaviour.

photo
1

I read it. You're not helping.

photo
1

Actually, I am more so than you.

I've submitted many, many crash logs (over 30) for the mislablled 'overheating' issue. I've uploaded a world file. Yet have they responded? NOPE.

And I am pointing out where they are deliberately misleading people and refusing to submit bugs to the team. The evidence is literally all over this site. Did you even read the link I gave, what's your excuse for that?

You defending a bad practice helps no-one bar Keen. Does the opposite for customers.

photo
1

OK, you win, you're helping. Thanks for helping.

photo
1

You're welcome. And some advice - next time you want to discuss a point, you have to address the evidence otherwise you will simply need to make an exit.

photo
1

Your advice is very helpful. Also, I am being extremely sarcastic. Just in case you missed it.

photo
1

I didn't. I'm simply used to people like you who have no knowledge of the subject. By all means though, feel free to continue discussion because I'm always open to other opinions. But you need to have some fact or knowledge behind you, otherwise your opinion is useless.


You clearly didn't even look at the link I gave - this shows the same problem, hints that it's a memory issue (again, they state it fixes when restarting) but keen don't even respond after the user takes the time to do exactly what they say.

Seriously, what further evidence do you need? I would genuinely like you to say.

photo
1

It's your approach I'm criticising, and your confrontational manner. That's without even addressing the assumptions you're making about me, which have nothing to do with that. Twice now, in this one issue, you've given unhelpful rants which will not change anything about Keen's bug triage process. Try contacting the actual decision makers.

photo
1

You haven't looked at the evidence at all have you?

Look at all the threads on this issue and tell me I'm wrong.

You talk about contacting the decision makers - WTF are you on about? This only purpose of this site is exactly for that. That explicit purpose. It's monitored by people FROM Keen. This is not about decision making, this is about deliberate attempts to ignore bugs.

This Laura has more direct access to Keens 'decision makers' than I ever will. She chooses not to respond (evidence on many other threads). Or more likely, told to follow a script sheet and not discuss anything else.

They are developers. They should have MORE knowledge than I do, yet as I say, this is clearly something to do with memory, and yet they keep asking for evidence and replicable steps. I do not believe that I have more knowledge than they do about developing, that would be simply stupid.

That leaves them being obtuse on purpose.

Also, my first post was very helpful, as it's simply the best resolution. Why? Because:

It's obvious there are no clear replicable steps to produce this issue.

Changing status of the ticket would let people know this bug is actually being looked at, not ignored.

Doing something about the duplicate threads would help MASSIVELY. It would enable them to pool all the data submitted (including various logs and world files), get a more accurate tally of how many users have voted for this, and let everyone see from a single source what's being done and kept up to date.

It would also ultimately reduce their time in trying to separately manage all these threads.

My manner is perfectly inline with the way the customers are being treated.

If you really want, I can link you to over 20 threads which display the same behaviour by Keen? You could find as many as you want, depends how much time you want to spend.

I'm sure you get my point.

photo
1

I get your point. You seem to think that shouting about it here will accomlish your goal. Well, carry on. I'm powerless to stop you. Unfortunately, I can't opt out of just your replies, so from now whenever your ineffective ranting ends up in my inbox I'll just delete it and move on.

photo
1

Well that's a cop out if ever I saw one. Next time try to address points instead of being a sycophant.

photo
1

Hi Laura,


you are repeating the steps i do correctly.


are you testing in a local game (single player)? in single player i cannot replicate the issue, it only ever happens in multiplayer on a GTX gaming Dedicated server i rent.


i am no dev nor do i have any relevant programing skills, but to me, this seems like the server (or the client) fails to communicate/register the right ''state'' for the ship


here is a ideo showing you the exact same ship aftyer the depresurization bugs hits me. the server have been running for about 12 hours as this test takes places, i am the only player online at the moment


https://drive.google.com/file/d/1fhRNNMLdQIzQG-QgsQRkg-SFUGBkfFAj/view?usp=sharing


if you look closely, at the ends, i use the ''build info'' mods to try to find the a potential leak, but it fails to find it it. (small gree text that says no leaks detected)


i also took time to show you a scripted LCD screens that report damaged blocks, none shows up (does not works with armor block)

photo
4

25 days later. No, wait! 2 years later. This is why I quit this game and I'm still incredibly annoyed about the complete disinterest from Keen to solve some of the most serious issues they have on this bugtracker. If they even attempted to communicate with us this could probably have been solved long ago. Instead some q&a person makes an appearance every 6 months or so to tell us that they won't even show this to an actual developer and that they need a world file even though several have been provided, with logs, which they naturally ignored.. It's a fantastically bad behaviour from a company that we all have bought a product from. Imagine buying any other kind of product than a computer game. Would you find this level of support acceptable?

photo
1

I have also stopped playing, it seems that they are more concerned with launching dlc than correcting the problems, if someone is interested I can sell my game with a slight discount (actually my whole steam account since I only bought this game).

photo
1

I have the same bug. I'm playing on a dedicated server with a couple of friends. We just built an asteroid station. After we added 200 batteries to the station - all set on auto, the bug appeared for us. If any room on the station gets depressurized at all the air vents won't ever pressurize it again.


We had some luck setting the batteries to discharge or recharge and turned off getting the room to pressurize again but it's iffy - even the room pressurization eventually broke with all the batteries turned OFF.


It feels like there is some code running on the server that says cuts off a calculation if it takes too long on a per grid basis. It seems like maybe the Oxygen system is a lower priority on that system and never gets a chance to run.


If you want to reproduce it we have a very large base - 320 solar panels, 200 batteries, 6 refineries, a ton of light armor blocks used as we went up until we had 24/7 sun from the asteroid wouldn't block out the sun at all, etc.


It's discouraged my group of players, two of which bought every DLC pack and a third player who literally just purchased space engineers.


I've also noticed some other oddities in my testing: At times a single 3 block airlock the air vent was filling at 0.01% per second - taking forever and ever to fill.


This bug absolutely needs to be solved. It's either some priority issue, some server stability code, or there is a memory corruption bug that gets triggered randomly when the air pressurization code also runs.

photo
1

Hello, enric!

I have still been testing this and trying to reproduce it but sadly it pressurizes each time! I've recently managed to reproduce an issue where a room was failing to repressurize after a small ship was disconnected and reconnected but this was singleplayer. I have been testing your save on a dedicated server. I do appreciate that for you, you've said it is 100& replicable but for me, it hasn't happened once. This thread is being open for users to post saves and reliable steps as I'd love to be able to reproduce someones save :)

Kind Regards

Laura, QA Department

photo
1

Laura, what exactly is it are we supposed to do? You have been told it's clearly NOT the save files.

As someone monitoring the bug submissions, you need to pass this on to the team.

Just because you cannot replicate it with your hardware doesn't mean it should be shelved and remain a problem for customers.

As you've been told multiple times, this is clearly some form of memory issue, same as the false CPU overheating bug (which you have ignored multiple replies to).

Without a response people can only assume Keen are deliberately ignoring issues which have been tagged by hundreds of customers, across multiple threads. It's obvious you are only saying what you have so you can mark it incorrectly as 'Need more information'.

photo
1

Hi Laura,

Please take a look at the save file from our dedicated server. It has the air vent bug:

https://www.dropbox.com/s/brk7a9y3hoijsle/Air Vent Bug Submission.zip?dl=1

I'm able to reproduce the air vent bug in single player but it takes significantly more tries than on the dedicated server. The dedicated server breaks within 1-5 vents, it takes 20-30 attempts on single player. I'm also happy to send over the entire dedicated server app data folder too if requested.


Reproduction Steps:

1. Spawn at the Air Vent Bug Survival Kit

2. Enter/Exit the building 20-30+ times until the air vents turn yellow permanently. Sometimes try standing in the automatic door to let it vent longer too or refill air longer too.

Expected:

Air Vents do not turn yellow.

Air Vents don't try to pressurize very slowly at 0.01% per second.

Results:

Air Vents eventually turn yellow and stay yellow for the rest of the session unless all players leave the area. Sometimes instead of turning yellow Air Vents will pressurize very very slowly at 0.01% per second.


Notes:

The air vent leak mod shows no leaks in this room. All windows are correctly placed on the inside surface.

The air vents even break with using normal doors vs the automated door setup we have. It's inconsistent when they break but eventually they WILL break.

Air vent bug seems even worse if we have 200+ batteries on the station all set to auto, or tons of other resources active like refineries, assemblers, etc. Please try adding 200+ batteries set to auto to the station if you cannot reproduce the air vent bug on your end.

Only our home base has this issue. Individual ship grids have not ran into this issue yet. It does not matter how many ships are connected to the base either. It breaks even with every ship disconnected.

The airlock bug hit our base when it grew tremendously in size. Larger grid sizes seem to trigger it easier. We're absolutely fine on the dedicated server with sim speed wise - still at 1.0 with the thread at 15-20% utilization. It feels like it's either some memory corruption bug in the air vent code, some timing issue in the air vent code, or some intentional code that stops computation of air tightness to keep the game's sim speed running at 1.0.

Given how complex the bug is, please forward this bug to one of your software engineers to take a look as well, even if you're not able to reproduce it with my save file.

Please reach out for my entire dedicated server file if you still cannot reproduce this with the above save file.

I hope you're able to reproduce this bug! I'm the owner of this dedicated server and my players are absolutely frustrated with the bug. Several of my players, including myself, have purchased every DLC product as we love Space Engineers.

photo
1

Hello Ritaelyn!

Thank you for the saves and reproduction steps! Just to double-check, I wasn't given the option of that spawn point. Is it the Citadel Station? I see automatic doors and vents in front. Just want to check this is the correct room/grid :)

Kind Regards

Laura, QA Department

photo
1

Hi Laura,

Yes. Citadel Station is the station that has the buggy air vents. :)

Cheers,

Ritaelyn

photo
1

Any news here? This just appered on our server. Large grid ship. Several merged modules, all pressurized properly. Detached one, WHOLE SHIP depressurized, since then no pressiruzation remains. I use double sliding doors everywhere as airlock, and it seems after playing around with them, it pressurizes again, but gain and again i find it depressurized with Vets showing yellow light. use of merge blocks might play into this.

Update: Opening all Sliding Doors at the same time, and then closing them again, makes the Vent pressurize it again.

I have normal double Sliding Door setups as airlocks, and I am actually right now standing in a CLOSED one that just lets all the air out!!!

photo
photo
2

I think I have found a way to replicate this problem.

1º Build a large hangar with pressurized hangar doors

2º Pressurize, (making sure you have enough space to store the oxygen again and something else)

3º Depressurize and wait for it to finish

4º Open the hangar doors

5º Go mining for a while (I'm not sure it's necessary)

6º Close the doors

7º Try to pressurize again.

You should already have the problem with the pressurization, "yellow lights"


Sometimes the problem begins at the 3rd point depressurizing much more than 0% reaching negative numbers.

I have tested this with small hangars and it works perfectly so the size must affect, maybe if you test it on a NASA computer you will have to create a hangar many times bigger for the problem to occur.


Another thing, try to build Space Engineers from https://github.com/KeenSoftwareHouse/SpaceEngineers code but it fails. Is it still possible? What else do I need to install that is not in the instructions?


I do not put the world because it will happen in any game you create.

photo
5

Hello,


After a (very) long time saving and reloading, i also discovered a way to replicate the issue. This is working 100% of the time on my computer. Here is the procedure :


- Minimal large grid version... : https://steamcommunity.com/sharedfiles/filedetails/?id=2471812037

- ...with a bunch of light armor on it : https://steamcommunity.com/sharedfiles/filedetails/?id=2471814666

- Create a new world, creative mode. Go to Mars Base or Moon Base (couldn't replicate in space). Enable experimental mode and ingame scripts. If you don't want to, then you'll have to trigger the bug manually.

- Get outside

- Spawn the "TOWER" version with all the light armor on the top (try to attach the small base to the ground).

- Make sure the door is closed and push button 1 on the command panel.

- The programming block will start opening the door, waiting 3 ticks, closing the door, waiting 3 ticks, and so on.

- After a while (sometimes seconds, sometimes 2 minutes, shouldn't be too long), you will see the outside vent trying to pressurize the outside environment.


If that does not trigger the bug on your side, stop the program using button 2, close the door if needed, then add more blocks to the grid. I mean, really, could be a lot more depending on your computer. Eventually, restart the program using button 1. You can also try to enable your jetpack and go back and forth.


Further notes :

- Once the bug is triggered, returning to the main menu and reloading will make it go away (until next time).

- Also, the vents will enter into some weird state. Sometimes they will have very low pressurization speeds (like 0.01 % every second), but still working. Another time, they will just stay yellow, without pressurizing the room. I even got some negative pressure states toying with this grid.

- I said "waiting 3 ticks" earlier, about the door, but that's probably not correct. With an actual grid (not just a bunch of steel, because investigating this bug all started with my base...), i had to increase that value, up to ~10-12 to trigger the bug.

- This also means that if you don't wan't to enable the experimental mode, you'll have to open the door, wait 3 ticks (yeah...), and close the door. And probably do that multiple times to have a chance to catch it. On an actual grid, since that value can be larger, you have more chances. It's quite easy to trigger it manually on my actual base.


Please find some screenshots below, the script used in the programming block, and also a brand new save where i replicated this. Hope this will help, since this bug is really game-breaking in survival.


Screenshots attached :

1 - The "minimal" thing

2 - The inside, just a vent

3 - The "minimal" thing with a bunch of light armor...

4 - ...pressurizing the moon after pushing button 1

5 - Pressure of the outside vent.

6 - Pressure of the inside vent, going up 0.01% by 0.01%.

7 - Final view

bonus - Large negative pressure on another similar grid


Script :


int runCount = 0;
int timer = -1;
// Starts messing at 3. Not sure of actual max value
int maxTimer = 3;
bool running = false;

public Program()
{
    Runtime.UpdateFrequency = UpdateFrequency.Update1;
}

public void Save()
{
}

private IMyTextSurface GetMySurface(int n)
{
    IMyTextSurface mySurface = Me.GetSurface(n);
    mySurface.ContentType = ContentType.TEXT_AND_IMAGE;
    return mySurface;
}

private IMyTextSurface GetMyScreen()
{
    return GetMySurface(0);
}

private IMyTextSurface GetMyKeyboard()
{
    return GetMySurface(1);
}

private IMyTextSurface GetSurface(IMyTerminalBlock b, int i) 
{
    var p = b as IMyTextSurfaceProvider;
    if (p == null) return null;
    return p.GetSurface(i);
}

public void Main(string argument, UpdateType updateSource)
{
    IMyDoor door = (IMyDoor)GridTerminalSystem.GetBlockWithName("door");
    IMyAirVent vent = (IMyAirVent)GridTerminalSystem.GetBlockWithName("vent");

    if(argument == "go") {
        running = true;
    } else if(argument == "stop") {
        running = false;
    }
    if(running) {
        bool doorOpen = door.OpenRatio >= 1;
        bool doorClosed = door.OpenRatio <= 0;

        if(doorClosed) {
            if(timer == -1) {
                timer = 0;
            }
            if(timer == maxTimer) {
                timer = -1;
                door.OpenDoor();
            } else {
                timer++;
            }
        } else if(doorOpen) {
            if(timer == -1) {
                timer = 0;
            }
            if(timer == maxTimer) {
                timer = -1;
                door.CloseDoor();
            } else {
                timer++;
            }
        }
        runCount++;
    }
    string status = "RUNCOUNT="+runCount+"\nDoorOpenRatio="+door.OpenRatio+"\nPressure="+(vent.GetOxygenLevel()*100);
    Echo(status);
    IMyTextSurface myScreen = GetMyScreen();
    myScreen.WriteText(status);
}

Save (and all other files) : https://drive.google.com/drive/folders/1qR4yanmXyHJiydcMiFkbaEIKYSJZqB0G?usp=sharing

photo
2

I added a video to the GDrive folder. Here is the direct link to the video :

https://drive.google.com/file/d/12wh-8H8_BgLPNWy3uLzBST9HlPVAOjAA/view?usp=sharing

photo
5

Hello, LDIUD!

Thank you for posting this with such excellent reproduction steps. I have successfully reproduced this issue and reported it internally. I really appreciate you taking the time with this as so far, these have been so very difficult to reproduce.

Kind Regards

Laura, QA Department

photo
1

so will it be fixed now or?

photo
photo
1

We can replicate this issue most of the time. Usually happens when we connect two ships with a merge block. The ships will not pressurize while merged. When disconnected they will usually start to pressurize again. In some cases, we need to restart the server to get it working again.

photo
1

I have another case of reproductible pressurization bug.

It requires two doors (similar to a rudimentary airlock) but works in space and on a fairly small structure with no CPU load to speak of.

You can spawn the attached blueprint anywhere (in space or on an asteroid) in a new custom/empty world game in creative mode. Hitting the "Run" button from the programmable block will toggle the test program on and off (as indicated by the red light).

Looking at the air vent through the window, you should see the indicators shortly turn into a single yellow light.

If you toggle the program off at this point, you can either see the room re-pressurizing after about one second, *or* witness one of these strange results:

- the room re-pressurizing very slowly (more than 10 times slower than usual)

- the vent staying stuck indefinitely on a yellow light (reported as "can't pressurize" when inspected from a terminal)

Running the program again usually gets the vent unstuck. If you recompile the program, you'll have to hit 'run' once to start it.


I ran into this bug while trying to come up with an automated airlock system. I had an initial recognition phase where each door was tested to see if it opened to a pressurized or unpressurized space. That would work fine for a single airlock, but mess up the pressurization completely when two airlocks in the same room were tested in parallel. I finally managed to get it working, but I had to enforce a minimal delay of 10 ticks between any two doors closing or opening.

If you like, I can post a saved game with the working system and another showing how removing this delay wreaks havoc on the air vents. On the other hand, the code is about 500 lines long, using a kind of rudimentary, undocumented homemade multitasking scheduler and might be a tad bit hard to read.

Files: bp.rar