Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Assumption that matches don't start at exactly the start of their "slot" #23

Open
PeterJCLaw opened this issue Mar 26, 2023 · 0 comments

Comments

@PeterJCLaw
Copy link
Member

Matches in SRComp are represented as having two timing boundaries:

  • the slot, which is the time that that match can be thought of as having priority in the arena (i.e: it is being set up, run or torn down), and
  • the game, which is the time when the match is actually playing

The game portion is at most the same duration as the slot, though for practical reasons is likely to be non-trivially smaller. However there is nothing which requires that a game be in the middle of a slot. While that is the most common configuration, it could be at one end or the other.

Mixtape on the other hand assumes that it can listen to the event stream for the match events, which are fired when the stream detects that the "current" match has changed. (The bounds of the "current" match are those of its slot).

As Mixtape has no other source of timing information: if a compstate were configured which had the game starting at the start of the slot then mixtape would always be "late" to the start of the match -- the match even from the stream would happen a few seconds after the actual start time (the stream polls for changes about every 2 seconds) and mixtape is downstream from that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant