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

Rework penalty queuing #21

Open
asquared opened this issue Oct 20, 2014 · 1 comment
Open

Rework penalty queuing #21

asquared opened this issue Oct 20, 2014 · 1 comment
Assignees

Comments

@asquared
Copy link
Member

The current penalty queue system isn't very flexible. First, it can't adapt easily to changing game rules, such as the number of penalties being served at once. Also, it doesn't really play nice with the format used by the RTD sync feed. Using a single queue for all penalties could eliminate some of these issues, but might introduce new ones.

In refactoring this, I'd like to avoid putting timers into the team state if possible. Perhaps individual penalties should have a time-assessed field, instead of that being a property of the queue. It's pretty easy to back out a time assessed from the RTD feed, so that might be the way to go.

It may be worth calculating tenths of a second between the last RTD time message and either now or the most recent "stop" message to allow penalty timers to be precise to the nearest tenth.

@asquared asquared self-assigned this Oct 20, 2014
@asquared
Copy link
Member Author

Represent penalties as (player number, time assessed, duration) or (player number, expected expiration, duration)? If we do expected expiration, we get problems. How about (player number, time assessed, duration, time cancelled)? Then cancelling a penalty doesn't have to change the data of other penalties.

The million dollar question: what does the RTD feed send when a penalty is cancelled? Does it send anything or do we have to figure it out?

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

No branches or pull requests

1 participant