You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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?
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.
The text was updated successfully, but these errors were encountered: