Jump to content

Bunker door activation is affected by camera attention


GnyoR
  • Branch: Live Branch Version: Windows Fixed

While all bunker doors above the solar panel are connected in single automation wire, the time it starts opening is different upon whether I'm watching on it or not. (same on closing)

1st pic shows some doors have already opened and some are opening and some just start to open. This gradation seems to have happened by my camera moving from left to right when bunker door has received ON signal. 

2nd pic is camera position when I found out this bug.
The step was : I was managing for the rocket at this camera position > and I found out bunker door is opening > then I moved camera to right side quickly > and I found out this gradation of various opening status of bunker doors. > So I paused and took the screenshot.

 

I attached the save file, but I couldn't find the log file, sorry.

But I saw another bunch of people in local ONI community suffering from same situation, so I believe this is easily reproducible.

 

OxygenNotIncluded_2018-10-23_03-50-04.jpg

OxygenNotIncluded_2018-10-23_03-50-21.jpg

Under the Stars.sav


Steps to Reproduce
Set the camera position on some of bunker doors which are connected in single automation wire. When doors receive the signal, the reaction of doors is faster in doors within the camera attention. Ironically, there seems to be no problem if all the doors are not within the camera attention. (Also no problem when I got all the doors within camera range using screenshot mode. But maybe these 2 situations - all within camera range and all out of camera range - have different opening speed)
  • Like 1



User Feedback


A developer has marked this issue as fixed. This means that the issue has been addressed in the current development build and will likely be in the next update.

Changed Status to Known Issue

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

Weird. Thanks for reporting this!

  • Thanks 1

Share this comment


Link to comment
Share on other sites

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.

Share this comment


Link to comment
Share on other sites

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.

Share this comment


Link to comment
Share on other sites

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.

  • Like 1

Share this comment


Link to comment
Share on other sites



Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
  • Create New...