scoreboard
scoreboard copied to clipboard
rollerderby
[BUG] Start Jam does not work during halftime / end of period
Describe the bug When there are >30 seconds left in a period, sometimes lag or momentary delay between JT and SBO can result in the scoreboard moving into halftime or end of game mode, even though a jam is going to occur. In this case the SBO is usually poised with their finger over the "start jam" button and they hit it, but it does not work as expected.
A similar thing occurs when a team calls a timeout or official review with one second left on the scoreboard; the SBO hits the timeout button, but it is too late, as halftime or end-of-game has already begun.
Proposed solution: If "start jam" or "timeout" are hit within 10 seconds of the period clock expiring, the Scoreboard should revert to in-game mode with 0 seconds on the period clock and the relevant activity having started (e.g., a timeout, or the jam running). At this point if "zero seconds" is incorrect it can be easily adjusted by the SBO.
Hey Muffin,
When you say "there is a lag or delay", do you mean the publicly viewable scoreboard jumps "time" if you will?
If yes, this "public scoreboard", is it running off another device over a network? If yes, this device is it on WiFi or ethernet? If WiFi, do you find the WiFi signal is poor?
Just want to try and rule out some basics before I go hunting deep in the code for a potential bug.
Cheers
Jeneral Pain
On Tue, Mar 26, 2024 at 7:44 AM Muffin @.***> wrote:
Describe the bug When there are >30 seconds left in a period, sometimes lag or momentary delay between JT and SBO can result in the scoreboard moving into halftime or end of game mode, even though a jam is going to occur. In this case the SBO is usually poised with their finger over the "start jam" button and they hit it, but it does not work as expected.
A similar thing occurs when a team calls a timeout or official review with one second left on the scoreboard; the SBO hits the timeout button, but it is too late, as halftime or end-of-game has already begun.
Proposed solution: If "start jam" or "timeout" are hit within 10 seconds of the period clock expiring, the Scoreboard should revert to in-game mode with 0 seconds on the period clock and the relevant activity having started (e.g., a timeout, or the jam running). At this point if "zero seconds" is incorrect it can be easily adjusted by the SBO.
— Reply to this email directly, view it on GitHub https://github.com/rollerderby/scoreboard/issues/687, or unsubscribe https://github.com/notifications/unsubscribe-auth/AI4RNRAVIVAX66SV6ZSHUDTY2CECLAVCNFSM6AAAAABFHWR3E2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGIYDMNRXGI3TSNA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Sorry -- I mean lag between humans. The JT watches the SBO and blows the whistle, then the human being at the SBO pushes the button. In the half a second in between, is when the issue occurs.
Or in the case of a team timeout, after the four whistles the button is pushed, which is at some delay (i.e., SBOs often need to add a few seconds back to the period clock for timeouts...but if those seconds cross the "end of period" border, that is when the bug occurs.)
This is not a technical failing on the part of the Scoreboard. Maybe this should be a feature request and not a bug.
Considering this, 0.5ms should not be causing such a significant skew in the clock.
A lot of the time, the skew is caused by "hand to mouse" movement being heavily delayed, because by the time they hear "realise" and grab the mouse to click stop jam, that's where the time is being penalised. And I've taken on the point of teaching new SBOs to "stop the clock first" and then sort everything else out. Especially those who do not wish to/use the keyboard (due to preference, disability, etc).
Proposed solution: If "start jam" or "timeout" are hit within 10 seconds of the period clock expiring, the Scoreboard should revert to in-game mode with 0 seconds on the period clock and the relevant activity having started (e.g., a timeout, or the jam running). At this point if "zero seconds" is incorrect it can be easily adjusted by the SBO.
- I don't think that is a valid solution. It's purely because you're effectively removing 10 seconds and then fixing it. If the timeout had been pressed, the clock would stop with whatever was left. There is also the "Timeout called before the end of the period" option at the top, where they can set the number of correct seconds based on how many seconds actually remain. This would then stop the scoreboard getting confused with where it should be.
Message ID: @.***>
The intended behaviour is that until half of the intermission has passed or the score is final, the jam/timeout starts and is added to the previous period. So this is a plain and simple bug of the "Software doesn't work the way it's supposed to" variant.
@admdikramr I am trying to analyse this but am not able to reproduce it. I tried both right before and right after it ticked over into intermission and I tried both starting a Jam and a timeout. They always started. Can you try to figure out if there is some element that you might be doing differently that I am missing?