Bunker door activation is affected by camera attention

I noticed that too.

I think i noticed such thing too

Changed Status to Known Issue

Changed Redmine to https://redmine.klei.com/issues/4363

Weird. Thanks for reporting this!

It seems to be this issue effects time-sensitive automation logic more broadly. I have a simple gas filtering setup with an element sensor followed by a shutoff that filters out the selected element into the shutoff's line because the shutoff is activated for the tick where the gas moves into the shutoff-occupied pipe tile. Everything works as expected while you're watching it, but after a while of doing other things the storage tanks all have a mix of gasses in them. I haven't had any power outages so that can't be it. I've also encountered a similar thing with temperature filters before a aquatuner on my coolant line, where the aquatuner's output pipe breaks from over-cooling the pwater that should have been filtered out, then after noticing it and being confused finding that it didn't happen after reloading and watching it for the cycle.

On 2018. 11. 20. at 11:05 PM, AlexisBlackbird said:

It seems to be this issue effects time-sensitive automation logic more broadly. I have a simple gas filtering setup with an element sensor followed by a shutoff that filters out the selected element into the shutoff's line because the shutoff is activated for the tick where the gas moves into the shutoff-occupied pipe tile. Everything works as expected while you're watching it, but after a while of doing other things the storage tanks all have a mix of gasses in them. I haven't had any power outages so that can't be it. I've also encountered a similar thing with temperature filters before a aquatuner on my coolant line, where the aquatuner's output pipe breaks from over-cooling the pwater that should have been filtered out, then after noticing it and being confused finding that it didn't happen after reloading and watching it for the cycle.

I use very similar system for sorting gases and for aquatuner, but in my experience, malfunction of that system was always due to the blocked end of pipeline. But I can agree with that this issue is more broadly about automation, not only bunker door.

This bug is still present in QoL1. This bug can actually be pretty nasty because you can set up your automation properly to close the doors for a meteor storm, then if you happen to check on it or even just casually move your camera there while the doors are closing, they'll reset and that's potentially up to 40-45 seconds of your buildings being exposed (unless you give a cushion in your automation, but then you lose 40-45 seconds of solar power). Conversely, if you time something to the doors opening, that can go out of line too and cause more issues that you have to manually order your dupes to clean up after. You either have to keep a constant eye on it and not move the camera an inch while the doors are operating, or just look away altogether and hope nothing breaks.

I've been playing around with it and found the following observations:

• If the door starts opening/closing while the camera is away, if the camera remains away until the door is fully open/closed, the door acts as expected.
• If you move the camera to the door while it is still in the middle of opening/closing, the door will revert to its initial closed/open state, resetting the opening/closing progress.
• If the door starts opening/closing while on screen or near the camera, you will see the door open/close normally as expected. If you move the camera away, and don't bring it back until it finishes opening/closing, it should be fine.
• If you do move the camera away and subsequently move it back while the door is still moving, the door opening/closing progress will revert to where it was when the camera was moved away. This can happen multiple times if you keep moving the camera around.
• Toggling the power (e.g. with a shutoff, or even just batteries running out) while the door is operating also resets the door progress to whatever it was when you last looked at the door. This can happen repeatedly.

Not sure if other doors (e.g. airlocks) are affected - if they are it tends to be less noticeable since they open/close very quickly anyways.

My guess is that there's some optimization that's happening when the doors go off screen so that, rather than updating the door progress continuously for the animation, the game will simply remember the door progress and the exact time in the future when the door progress should complete. Then the game does not need to compute anything for those doors (besides generic stuff such as heat transfer) until:

1. The simulation reaches the "tick" where the door should finish its operation.
2. The completion time becomes invalidated, such as by a change in power state. The game then needs to update the progress and completion time.
3. You observe the door, i.e. move the camera close enough to it. The game then needs to update the progress and then continue from there in real time.

The game does #1 fine, but is doing #2 and #3 improperly. It does not update the progress; it simply keeps the progress that it had "saved" without accounting for how much time has passed.

To behave correctly, when going offscreen it should not only remember the door progress, but also the corresponding time in the simulation. Then when #2 or #3 happens; the progress can be updated either by knowing the original progress, the speed (based on whether it was powered), and how much time has passed; or it can be updated knowing the original progress, how much time has passed, and how long it would have taken to become fully opened/closed.

If the doors are indeed implemented in this manner, I don't think it should be too tricky to fix depending on how the game's code is structured.

This will be fixed in the next hotfix.