Jump to content

space scanner broken?


Recommended Posts

10 hours ago, Kderosa said:

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. 

It sounds like you are saying that the 3 scanners on the right also re-roll and sometimes individually will revert back to red, but the odds on all 3 of them doing that are low?  If that is the case then it should still happen sometimes, and in your video, none of them went red, and I don't think I've ever seen that happen.  I'm pretty sure I've even run just a single scanner on the whole map and once it locked on it never let go when the doors closed.

Link to comment
Share on other sites

3 hours ago, psusi said:

It sounds like you are saying that the 3 scanners on the right also re-roll and sometimes individually will revert back to red, but the odds on all 3 of them doing that are low?

No, here's what I think is happening

Summary: The problem is that the network quality signal (once a scanner detects a storm) does not persist until the end of the storm), like a normal scanner signal persists until the end of the storm.  I think this is not expected behavior and a likely bug.

1. Meteor storm event plus 200 seconds: scanners roll to determine detection and begin decrementing (something like this is going on)

2. One or more scanners detect meteor shower and send green signal to all connected scanners via BOTH the automation wire and to unconnected scanners via the scanner network. 

3. This causes all scanners to send a green signal even if they haven't detected the meteor shower yet.  Scanners that haven't detected the shower yet continue decrementing until they do detect.

4.  All doors connected to a scanner set to detect meteor shower will close.

5.  When the doors finish closing the network quality and scanner quality of each scanner reverts to zero. Whatever network signal existed is lost (This is important).

6. All scanners that detected the meteor shower before the doors were closed will continue to send a green signal until the meteor shower is over.  The remaining scanners that haven't will continue decrementing until they do detect the shower. (Not something you notice for connected scanners because the signal is already green from the scanners that detected earlier.) 

Here's where the problems occur if the scanners are connected incorrectly, one condition is a logic problem (not a bug), one condition is unexpected behavior (a likely bug).

7A.  Scanners connected after the NOT gate.  Once the network signal is lost,scanners revert to their own internal detection mode.  This means you will have some scanners sending red signals and some sending green signals.  If the scanners are connected before the NOT gate the green scanners will prevail and the doors will remain close.  If, however, they are connected after the NOT game, the NOT gate will negate the red signal, turning it green, and opening the doors.  This is a subtle logic problem caused by an incorrect connection of the scanners.  Not a bug.

7B. For Scanners not connected to any other scanner directly, once the network signal is lost, will revert back to its own detection ability.  If it hasn't detected the meteor show yet, it will continue decrementing until it does detect.  In the meantime, it will send a red signal which opens the doors. The problem is that the network quality signal (once a scanner detects a storm) does not persist until the end of the storm), like a normal scanner signal persists until the end of the storm.  I think this is not expected behavior and a likely bug.

16 hours ago, nakomaru said:

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.

Certainly something like this is going on.  The network signal doesn't persist after a scanner has detected a meteor shower as you would expect because that's how the individual scanner signals work.  I think this is unexpected behavior and a likely bug.

Link to comment
Share on other sites

Did they fsck this up in the last patch?  Because they did NOT used to work this way.  The automation wire is supposed to be a simple on/off and an output only from the scanner.  There wasn't and shouldn't be some extra magical data sharing network between scanners connected to the same wire ( no not gate ) to keep them locked on after the doors close.

Link to comment
Share on other sites

I believe this has long existed. It explains what happened in 2018-2019 when I was using a 33% quality network.

edit: @Kderosa is right - scanners (can?) reroll every time network quality is updated. (I previously thought it was one roll + realtime update of network quality offsets.)

T-200s to shower. All 6 individual signals are green (vertical lines). (quality 100%)

Step1.thumb.png.8afa56f788bbfbbfa4689a71652b0bf2.png

Airlocks are shut (automation) and a few seconds later scanners update, all 6 are red:

step2.thumb.png.54b867fa3e41af54a4cc6e75a0a8b361.png

Airlocks open (automation), network quality is 93% for some reason. Scanner number 4 locks on.

step3.thumb.png.52e0cef0d00cd3c869a6dd1c729dee21.png

About 5 more cycles of this (sometimes 93%, sometimes 100%), with random scanners at the 93% moments, when finally #5 locks and holds on.

step6.thumb.png.058b2834e8097a532b42d3a72daf9f3c.png]

After some time, others come online. Repeating the experiment, sometimes one scanner will hold its lock from the beginning.

Because the detecting scanner can vary in a single sequence, it's not a simple minimum offset as I previously thought. Save file:testbed2.sav

Link to comment
Share on other sites

Weird... why do they all go green the first time, but not each of the subsequent times the doors open?  And I had 3 scanners in my last world all on the same automation wire and they never all went green at the same time... though I was pulsing their power.  Maybe that has a similar effect of breaking the magic "network" detection.

Link to comment
Share on other sites

1 hour ago, psusi said:

why do they all go green the first time, but not each of the subsequent times the doors open?  And I had 3 scanners in my last world all on the same automation wire and they never all went green at the same time... though I was pulsing their power.

[edit] OOPS, looks like the left most door was disconnected from power, and kind of difficult to get to behave. So that's the cause of the 93% and non guaranteed detection. After deleting it, it just cycles between all on and all off (first two images) until one scanner holds a signal (e.g. third image).

Pulsing is a great option because you can stay at 0% quality the whole time and just reroll until you detect, and not suffer from the roll being updated.

Sometimes, I would also see a 100% scanner keep its roll after being updated to 0% at T-200s +animation. I'm not really sure what stops them from rerolling... I think it's luck. The save is there if it can help someone find a more parsimonious explanation.

Link to comment
Share on other sites

On 5/13/2020 at 6:54 PM, psusi said:

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.

II apologize for not responding sooner, I thought I would get email notifications! 

I've played through my colony to completion now and just ended up checking every time all three (main) scanners agreed a shower is incoming. Then watching them and flipping a manual switch if any of them  decided to go safe.  After 100s of cycles of this I can say:

  • Happens after the bunker doors are fully closed
  • Zero to All (3) scanners can flip to Safe unexpectedly,  though usually only one
  • There was not a total loss in power
  • May only occur during 3x "fast" speed, circumstantially the few times I played at slower speed, I don't recall this occurring
  • Saves/Loads happen when doors are fully opened or closed, I recognize the bug referred to earlier in this thread but it's not that. 

As I sidenote, I have it set up so all three scanners have to agree via an OR gate configuration to minimize the time the doors stay closed (given the detection range is 1XX-200s, all three detecting would be at the low end).  Outside of a few rare occurrences where the scanners all said Safe when it wasn't, using AND gates would have worked around this issue though resulting in the doors being closed more than they had to be. 

My colony since the screenshot became more complicated, with a few more scanners for spaceships -- not connected to the main bunker doors. The behavior has persisted.  If it is of any help, I can share the colony file. I did find a similar bug in the database and attach my info to it.  Thank you all for your help!

Link to comment
Share on other sites

11 hours ago, prokat said:

As I sidenote, I have it set up so all three scanners have to agree via an OR gate configuration to minimize the time the doors stay closed (given the detection range is 1XX-200s, all three detecting would be at the low end). 

Huh?  You said when they detect, all 3 go green at the same time, so what's the use of the OR gates?

 

Link to comment
Share on other sites

1 hour ago, psusi said:

Huh?  You said when they detect, all 3 go green at the same time, so what's the use of the OR gates?

 

Yes, I don’t think this is what typically happens. Some scanners detect early, others late. The late ones cause the problem that OP is seeing because the scanners are connected after the NOT gate. It’s happened to me and then I realized the logic problem. 

Link to comment
Share on other sites

8 minutes ago, Kderosa said:

Yes, I don’t think this is what typically happens. Some scanners detect early, others late. The late ones cause the problem that OP is seeing because the scanners are connected after the NOT gate. It’s happened to me and then I realized the logic problem. 

Huh?  You were the one saying that they do all go green at the same time as long as they are all directly connected with automation wire due to some unexplained magic.

Link to comment
Share on other sites

27 minutes ago, psusi said:

Huh?  You were the one saying that they do all go green at the same time as long as they are all directly connected with automation wire due to some unexplained magic.

No. When scanners detect the base blinks to indicate they’ve detected something. They all turn green because they’re connected, but that does not mean they’ve all detected. Watch the video I posted. Only three of the scanners detected up front. 

Also, the magic is the network which I think we both agree is wonky but does exist as some sort of separate signal which unfortunately doesn’t persist like individual scanner detection signals do  

 

 

Link to comment
Share on other sites

1 minute ago, Kderosa said:

No. When scanners detect the base blinks to indicate they’ve detected something. They all turn green because they’re connected, but that does not mean they’ve all detected. Watch the video I posted. Only three of the scanners detected up front. 

Yea, and all 3 of the ones that are wired together in the video have the base blinking at the same time, and your whole thesis has been that this happens on the initial detection, but then if the doors close and reopen, then each operates on its own and some ( or maybe even all ) of them may revert to red.

Link to comment
Share on other sites

There were six wired together. Only three blink initially. Some may have locked on later. It’s the ones that never locked on that cause problems under some wiring configurations or if unconnected. 

Link to comment
Share on other sites

15 minutes ago, Kderosa said:

There were six wired together. Only three blink initially. Some may have locked on later. It’s the ones that never locked on that cause problems under some wiring configurations or if unconnected. 

It looks to me like the 3 on the left at the same time, and about a frame or two later, all 3 on the right do the same.

So are you saying that there are two detection times: the network time, and the local time, and whichever comes first causes the scanner to light up, but after the doors close, the network time is lost and so any local time that has not yet passed will cause those scanners to revert to red?  So if the network time comes first, they may all light up at the same time, but with all 6 scanners, the odds are good that at least one of them will roll an earlier local time?

Link to comment
Share on other sites

On 5/13/2020 at 6:54 PM, psusi said:

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.

The red signal is only sent to the bunker doors when all three scanners send a green signal, which is intended to close with the shortest possible time allowed.  This means all three scanners have detected the incoming shower before the doors initiate closure. When the doors complete closure, at that point, one or more of the scanners will likely send a red signal (indicating no incoming shower).  They will do this for 1s to up until the shower actually hits and then turn back to green.  

Before the doors begin closing, all three scanners have detected the shower but once the doors close, one or more of the scanners will indicate there is no incoming shower.  That's the problem i faced.  

Link to comment
Share on other sites

8 hours ago, psusi said:

It looks to me like the 3 on the left at the same time, and about a frame or two later, all 3 on the right do the same.

So are you saying that there are two detection times: the network time, and the local time, and whichever comes first causes the scanner to light up, but after the doors close, the network time is lost and so any local time that has not yet passed will cause those scanners to revert to red?  So if the network time comes first, they may all light up at the same time, but with all 6 scanners, the odds are good that at least one of them will roll an earlier local time?

This is pretty close. The scanners don’t light up until they detect a shower themselves. But the network causes them to send a green signal until the doors close. Then the scanners revert back to their own signal. If they are connect then the doors will stay closed since at least one scanner has detected. But if an unconnected scanner hasn’t yet detected when the network signal is lost it will open up the doors again until it does. 

3 hours ago, prokat said:

The red signal is only sent to the bunker doors when all three scanners send a green signal, which is intended to close with the shortest possible time allowed.  This means all three scanners have detected the incoming shower before the doors initiate closure. When the doors complete closure, at that point, one or more of the scanners will likely send a red signal (indicating no incoming shower).  They will do this for 1s to up until the shower actually hits and then turn back to green.  

Before the doors begin closing, all three scanners have detected the shower but once the doors close, one or more of the scanners will indicate there is no incoming shower.  That's the problem i faced.  

Yes. Don’t connect them this way. Connect them all before the NOT gate and you won’t have this problem. 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Please be aware that the content of this thread may be outdated and no longer applicable.

×
  • Create New...