space scanner broken?

[prokat]

After detecting an incoming meteor shower, but before the shower hits, I have scanners changing from incoming (green) to safe (red) after the bunker doors close.  It's my understanding they should maintain incoming status until after the detected shower has hit.  Is that correct?  

I've attached a photo showing the bad behavior.  I have three scanners, chained to OR gates. The last AND gate has a switch for manual control.  I added buffers after the NOT gate from each to catch when they flip unexpectedly.  In my screenshot, the left most scanner was sending green (incoming) then flipped.  The buffer gate preventing this bad signal hasn't run out yet. 

Am I misunderstanding the expectation? Having to monitor the logic for each incoming shower is pretty annoying! 

I'm on the live 408920 version on steam. thanks

[psusi]

If the scanners are powered the whole time then yes, they should continue to output a green signal until the shower passes.  Did you have them powered the whole time?  In my last world I used the pulsed space scanner array design and it would sometimes pick up the shower early, get powered off, and then not pick it up again when powered on again for some time.

[Kderosa]

One of the problems you can run into is when you have a high scanner network value and scanners unconnected to the other scanners before the NOT gate that runs to the bunker doors.  What happens is one or more scanners detect the meteor shower well before it's due.  Other scanners have not yet detected the meteor shower.  The scanners that have detected the shower send a green signal which overwrites all the scanners which haven't detected the meteor shower (still sending a red signal).  The bunker doors close well before the shower hits and all the scanners lose sky contact.  The problem is that some of the scanners never detected the meteor shower before the doors closed and maintained their red signal which causes the bunker doors connected to this scanner to immediately open again.  Eventually the scanner will detect will detect the meteor shower but sometimes it will be too late to close the doors in time, negating the value of your scanner network.  At least this is what I think is going on due based on my observation.

There are three solutions I can think of:

1.  Put a FILTER gate before the NOT gate to delay the bunker doors closing until a seconds before the meteor shower hits.  Just leave about 40 seconds to close the doors in time (I think).  This assures that every scanner will pick up the meteor showers before the bunker doors close and avoids the unwanted cycling behavior.

2.  Connect all the scanners via an automation wire before the NOT gate.  This maintains the green signal on all the scanners until the end of the meteor shower because of the way the green signal overwrites the red signal in the game.

3.  To be extra safe do both.

In the screenshot you've provided you have the scanners connected after the NOT gate this negates the green signal overwrite advantage are pretty much assures that your bunker doors will cycle open and closed which will eventually lead to meteors smashing into your build.  I've learned this through hard experience.  Also, you don't need all those OR gates (I think that's what they look like), bare automation wire acts like an OR gate because green overwrites red.

Hope this helps

 

[psusi]

42 minutes ago, Kderosa said:

One of the problems you can run into is when you have a high scanner network value and scanners unconnected to the other scanners before the NOT gate that runs to the bunker doors.  What happens is one or more scanners detect the meteor shower well before it's due.  Other scanners have not yet detected the meteor shower.  The scanners that have detected the shower send a green signal which overwrites all the scanners which haven't detected the meteor shower (still sending a red signal).  The bunker doors close well before the shower hits and all the scanners lose sky contact.  The problem is that some of the scanners never detected the meteor shower before the doors closed and maintained their red signal which causes the bunker doors connected to this scanner to immediately open again.  Eventually the scanner will detect will detect the meteor shower but sometimes it will be too late to close the doors in time, negating the value of your scanner network.  At least this is what I think is going on due based on my observation.

Did you look at the picture?  He doesn't have some doors on one scanner and other doors on another scanner.  Also if you did have some doors connected to their own scanner, then the doors wouldn't close in the first place because another, unrelated scanner went green.

[Artorias36]

Did you load your file during a meteor storm? It happens occasionaly that during the loading of a save game, the grid is without power and so the scanner goes offline, opening or closing the doors without reason.

[Sasza22]

The scanners will detect meteors from 1 to 200 seconds before they hit. The better the scan quality the earlier they detect. But there`s a catch. If you detect it too early and close the doors way before it hits the scan quality will fall to 0% so there`s a small chance the scanners will stop detecting the meteors. It`s a rare occurence but can happen. Basically the scanners roll the detection chance again and might not detect the meteros for another 10-20 seconds and make the doors open again.

To prevent that if you got a 100% scan quality put a delay in your automation. Since at 100% it always detects them 200 seconds before make the doors close 155 seconds after the signal (iirc the doors take about 40-45 seconds to close) so that they fully close as the meteors start hitting. It will grant you more power from solar panels and minimize the risk the scanners lose the signal and open the doors back.

[Kderosa]

5 hours ago, psusi said:

Did you look at the picture?  He doesn't have some doors on one scanner and other doors on another scanner.  Also if you did have some doors connected to their own scanner, then the doors wouldn't close in the first place because another, unrelated scanner went green.

I did.  

He doesn't but his scanners are connected after the NOT gate which causes similar problems.

I don't believe that is accurate.  Look at a recent scanner set-up of mine.

On the left I have a scanner array of six scanners with 100% network quality. On the right all the way over on the other side of the map is my solar array with one scanner that controls all the bunker doors above.  Note the 0% scan quality.  But also the 100% network quality.  This scanner would reliably close its bunker doors along with the scanner array on the other side of the map with no connection at 200 seconds out (without a filter gate attached).  However, as soon as the doors would close, because the scanner had not yet detected the meteor shower on its own the scanner would immediately open the bunker doors since the network quality had dropped to 0%.  Eventually it would detect the meteor shower but often not before the shower started.  I "fixed" the problem by running an automation wire across the map and connected the lone scanner to the scanner array.Now all the scanners closed the doors at 200s out and the doors remained closed because the scanners that had detected the meteor shower continued to send a green signal until the end of the meteor shower.  This green signal overwrote any red signals of the scanners thatt had not detected the shower.

 

3 minutes ago, Sasza22 said:

 But there`s a catch. If you detect it too early and close the doors way before it hits the scan quality will fall to 0% so there`s a small chance the scanners will stop detecting the meteors. It`s a rare occurence but can happen. Basically the scanners roll the detection chance again and might not detect the meteros for another 10-20 seconds and make the doors open again.

My experience was that the smallness and rareness of it depends on the scan quality of the scanner not connected to the network. My scanner had 0% scan quality so the door closing and opening dance happened frequently with devastating consequences.If all the scanners are connected make sure the scanners are connected before the not gate not after.  And slapping a filter gate on the network helps greatly.  But actually connecting all the scanners works best of all as far as reliability goes.  The filter gate just keeps the doors open longer which further reduces your chances of having a problem since you maintain sky exposure longer and lose network quality only right before the shower starts.  Also helps with preventing your rockets from crashing through your bunker doors since the longer sky exposure increase the chance that your rocket scanner locks onto your rocket as it approaches and before the bunker doors close when a meteor shower hits.

[psusi]

2 hours ago, Kderosa said:

He doesn't but his scanners are connected after the NOT gate which causes similar problems.

How so?  There is still only one signal to all doors so you can't have some close and some open.

2 hours ago, Kderosa said:

On the left I have a scanner array of six scanners with 100% network quality. On the right all the way over on the other side of the map is my solar array with one scanner that controls all the bunker doors above.  Note the 0% scan quality.  But also the 100% network quality.  This scanner would reliably close its bunker doors along with the scanner array on the other side of the map with no connection at 200 seconds out (without a filter gate attached).  However, as soon as the doors would close, because the scanner had not yet detected the meteor shower on its own the scanner would immediately open the bunker doors since the network quality had dropped to 0%.

If that lone scanner hadn't detected the meteors yet, why would the doors connected to it close?  Like you said, each scanner has its own output based on its detection, so if some other scanner has detected the meteors, this lone one will still have a red output and not close its doors.

3 hours ago, Sasza22 said:

Basically the scanners roll the detection chance again and might not detect the meteros for another 10-20 seconds and make the doors open again.

When and why would they roll the detection again?  If they were I would think this would be a very common occurrence.  Like it would happen every time with a high quality network that suddenly goes to 0 quality when the doors close.  I always thought that once they detected the shower, that is it, they are locked on and aren't going to let up until the shower is actually over.  The only time I've ever see one go green and then back to red before the shower was over is when using the pulsed setup since loss of power makes them roll the detection time again when they are powered back on.

[Kderosa]

18 minutes ago, psusi said:

How so?  There is still only one signal to all doors so you can't have some close and some open.

They’ll all close than immediately open. Sorry if I wasn’t clear

21 minutes ago, psusi said:

If that lone scanner hadn't detected the meteors yet, why would the doors connected to it close?  Like you said, each scanner has its own output based on its detection, so if some other scanner has detected the meteors, this lone one will still have a red output and not close its doors.

It uses the scanner network which appears to be “wireless”. But then once the doors all close the network signal is lost. Each scanner reverts to its own signal. If a few are connected the scanners that have detected will retain their green signal until the shower is over and this green signal will overwrite the red. But for a lone scanner that hasn’t detected that red signal will open the doors up the second they finish closing. Then you have to pray it detects the shower in time to close the doors again. 

 

29 minutes ago, psusi said:

When and why would they roll the detection again?  If they were I would think this would be a very common occurrence.  Like it would happen every time with a high quality network that suddenly goes to 0 quality when the doors close.  I always thought that once they detected the shower, that is it, they are locked on and aren't going to let up until the shower is actually over.  The only time I've ever see one go green and then back to red before the shower was over is when using the pulsed setup since loss of power makes them roll the detection time again when they are powered back on.

Don’t the scanners keep rolling until they detect? Once they detect they lock the signal until the shower is over. But if they haven’t detected they keep rolling. This only becomes a problem when your network is high quality and the doors close early that there’s a good chance some individual scanners haven’t detected yet. If the scanners are separate doors will open the second the network signal is lost. If they connected after the not gate, those red signals become green after the not gate so the doors open then too. Very annoying. 

[psusi]

10 hours ago, Kderosa said:

It uses the scanner network which appears to be “wireless”. But then once the doors all close the network signal is lost. Each scanner reverts to its own signal. If a few are connected the scanners that have detected will retain their green signal until the shower is over and this green signal will overwrite the red. But for a lone scanner that hasn’t detected that red signal will open the doors up the second they finish closing. Then you have to pray it detects the shower in time to close the doors again. 

You're not making any sense.  If the doors and scanners are all connected to one automation grid, then they will all close as soon as one scanner goes green.  They will also stay closed because that scanner is still green, even if other scanners are not.

If you do not have all of them connected to the same automation grid, then the one lone scanner starts off red, stays red, and so any doors connected only to that one scanner never close in the first place.  Other scanners not connected to this one going green do not cause this one to go green and so the doors on this side of the map never close.

You seem to be trying to mix aspects from these two configurations.  It's either one, or the other, not both.

 

[yoakenashi]

There is a difference between:

Close if A or B or C detects meteors - how it should be and is commonly set up

vs

Open if A or B or C is clear - which is how the OP set up their design

Neither should toggle state, but the latter will likely not protect against meteors.

[psusi]

58 minutes ago, yoakenashi said:

Open if A or B or C is clear - which is how the OP set up their design

Oh my, I thought those were AND gates.

[Kderosa]

2 hours ago, yoakenashi said:

There is a difference between:

Close if A or B or C detects meteors - how it should be and is commonly set up

vs

Open if A or B or C is clear - which is how the OP set up their design

Neither should toggle state, but the latter will likely not protect against meteors.

Right.  What happens is when the doors close the sky exposure is lost and network quality drops to zero.  The scanners that detected the shower remain green but the scanners that haven't yet remain red.  If the scanners are connected after the NOT gate, the pokey scanners will send a green signal after the NOT gate which immediately overwrites the red signal from the faster scanners (after the NOT gate) and opens up the bunker doors again - 40 seconds to open, 40 seconds to close again.  The next thing you realize when you check in on your set-up is extensive meteor damage.   

6 hours ago, psusi said:

 Other scanners not connected to this one going green do not cause this one to go green and so the doors on this side of the map never close.

Pretty sure this isn't the case, In my set-up above the lone scanner has 0% scanner quality yet it reliably closed the bunker doors it was connected to every meteor shower because it relied on the 100% network quality.  The problem was that since it was not physically connected to the network, once the network quality dropped to zero, the network signal was lost and the scanner reverted back to its own detection, which being 0% (even at 100% you'd get problems just not as many), served to immediately open the doors it was attached to.  The lesson is either connect all your scanners directly and/or slap on a filter gate so the doors remain open until a few seconds before the meteors hit.

[psusi]

34 minutes ago, Kderosa said:

Right.  What happens is when the doors close the sky exposure is lost and network quality drops to zero.  The scanners that detected the shower remain green but the scanners that haven't yet remain red.  If the scanners are connected after the NOT gate, the pokey scanners will send a green signal after the NOT gate which immediately overwrites the red signal from the faster scanners (after the NOT gate) and opens up the bunker doors again - 40 seconds to open, 40 seconds to close again.  The next thing you realize when you check in on your set-up is extensive meteor damage.   

If the red signal from the scanner can make the doors close, then it would have prevented them from opening in the first place.  The change in network quality is irrelevant.

35 minutes ago, Kderosa said:

Pretty sure this isn't the case, In my set-up above the lone scanner has 0% scanner quality yet it reliably closed the bunker doors it was connected to every meteor shower because it relied on the 100% network quality. 

Definitely not...even if you watch the scanners that are connected to one another you will see that one of them detects the meteors first and the others can still be scanning and not see it for some time.  The doors may even close before they detect the meteors.

37 minutes ago, Kderosa said:

The problem was that since it was not physically connected to the network, once the network quality dropped to zero, the network signal was lost and the scanner reverted back to its own detection, which being 0% (even at 100% you'd get problems just not as many), served to immediately open the doors it was attached to.

Scanners always use the network quality to compute their detection time.  Having their automation outputs connected or not does not change that.  All of the other scanners also have a network quality of zero once the doors are closed.  There's no reason for this one to behave differently than the rest and "forget" that it had already detected the incoming shower.

[Kderosa]

21 hours ago, psusi said:

If the red signal from the scanner can make the doors close, then it would have prevented them from opening in the first place.  The change in network quality is irrelevant.

You'd think, but watch what happens ...

[psusi]

Whoa!  That is fubar!  Bug report!

 

[Kderosa]

I'm surprised more people haven't gotten burned by this glitch.

[psusi]

1 minute ago, Kderosa said:

I'm surprised more people haven't gotten burned by this glitch.

I think most people don't put a lone scanner off by itself without a view of the sky and expect it to work

 

[Kderosa]

9 minutes ago, psusi said:

I think most people don't put a lone scanner off by itself without a view of the sky and expect it to work

 

It does the same thing even when it has a view of the sky, it's just not as bad since it detects the meteors earlier.

Hey, the only reason I even tried it this way is because I had read that the scanners didn't have to be connected to rely on the network signal.  Which is true! But as soon as the network signal is lost  you fall back to individual scanner detection which seems kinda dumb.

SO IF ANYBODY IS STILL READING THIS - ALWAYS CONNECT YOUR SCANNERS IF YOU WANT TO BE SAFE!

[psusi]

That's just weird... the only thing I can think of is that once the doors close, it causes the scanner to re-roll and since it's scan quality is now zero, it likely gets a bad detection time.  The only thing is, why doesn't this happen to the other scanners?  I mean the scanner can't even know that it is connected to the other scanners since it only thinks it is connected to a NOT gate, if it thinks anything at all.

[Kderosa]

I think what happens is that once the scanners detect the meteors they stay detected until after the storm and send a green signal the entire time, overwriting all the red signals from the other scanners that haven't if they are connected.  If you look closely at the video, the three scanners on the left all detected the meteors right away, while the others did not.  So it doesn't matter that the signal got lost when the door closed because some had locked on already.  But the unconnected scanner didn't get that benefit of the green signal overwrite, so it flipped to red when the doors closed and didn't flip back to green until it detected the meteors itself.

[psusi]

1 hour ago, Kderosa said:

But the unconnected scanner didn't get that benefit of the green signal overwrite, so it flipped to red when the doors closed and didn't flip back to green until it detected the meteors itself.

There isn't something magical about "signal overwrite".  Wires simply are green if any output connected to them is green, and red otherwise.  Thus it shouldn't matter how many scanners you have on the wire, or even if you use a signal switch to force it to be green: once a scanner has locked on, it should remain locked on.

[nakomaru]

7 hours ago, Kderosa said:

I'm surprised more people haven't gotten burned by this glitch.

Before I switched to a 0% network, I used a 33% network pair in the past and was frustrated by this, because you can't time everything out like you can at 100%. Speaking of which, it's fine to have isolated scanners as long as you time everything out at 100%.

5 hours ago, psusi said:

That's just weird... the only thing I can think of is that once the doors close, it causes the scanner to re-roll and since it's scan quality is now zero, it likely gets a bad detection time.  The only thing is, why doesn't this happen to the other scanners?  I mean the scanner can't even know that it is connected to the other scanners since it only thinks it is connected to a NOT gate, if it thinks anything at all.

Yep, I believe this is essentially what is happening. But it might not reroll: it keeps it's "x seconds random detection + y network quality offset". But you killed the " + y network quality offset" part of the equation after the doors closed and left only the x seconds random detection.

It happens to all the scanners, but you have 6 chances in a linked network for one of their base rolls (or rerolls) to be further out than the point when your doors closed.

[psusi]

57 minutes ago, nakomaru said:

It happens to all the scanners, but you have 6 chances in a linked network for one of their base rolls (or rerolls) to be further out than the point when your doors closed.

I think the OP only had 3 scanners in the "main" network though, and none of them seemed to reroll and get a bad roll.  Then again, maybe they do sometimes and they just didn't happen to this time?  In my last world I used a 3 scanner pulsed "Space Scanner Array" design and it sometimes did this, but I chalked it up to the fact that they were pulsed so after each on pulse, they each got a new roll.

[Kderosa]

3 hours ago, psusi said:

There isn't something magical about "signal overwrite".  Wires simply are green if any output connected to them is green, and red otherwise.  Thus it shouldn't matter how many scanners you have on the wire, or even if you use a signal switch to force it to be green: once a scanner has locked on, it should remain locked on.

The magical part is that green takes precedence and you need to be aware of it in your designs. The number does kinda matter since the more scanners the greater the chance one scanner locks on. Once one locks on you’re golden.