-
Notifications
You must be signed in to change notification settings - Fork 398
Description
Description:
The phase management algorithm ignores delays when deciding upon the contest phase,
when starting_time is none, so the delays have no effect at all when starting USACO style contests
(when contest window starts, all users can press the start button, even if they have delay_time,
and when contest window stops, there is no start button, even if the user has delay_time).
On the other hand, once a contestant presses the start button, and starting_time is configured, he cannot see the questions until delay_time seconds pass, which I believe is not the desired behaviour.
In addition, in regular contests (no per_user_time), a timer to the original contest start time is displayed for all users, regardless of their delay_time (though the explicit time written as "contest start" includes the delay_time and isn't synchronized with the timer).
When there is delay_time, once the timer reachs 00:00 (contest start), it's updated to delay_time and starts counting down again (upon changing the phase from -2 to -1), and the text says "contest started in contest_start + delay_time" even when this time is in the future.
Expected:
In regular contests, the timer should count down until contest_start + delay_time from the beginning.
In USACO-style contests, I believe for most uses delay_time should be zero.
But if we want to configure a delay_time, it probably means the entire contest window should move by delay_time for that user, and it should be added to the actual real start_time.
There were a few comments in the code regarding manually configured future start_times by the admin, but in such a case a "start" button still appears and overrides start_time, so it doesn't replace the delay_time functionallity.
Suggested solution
I've implemented a change in our local repo, if you think it's relevant for the main CMS branch I can open a PR here as well:
https://github.com/ioi-isr/cms/pull/23/commits