Description of the task
The delay and duration validation classes are used to modify other validations, to add a delay or a duration that the validation has to be valid for. However, these validations were implemented using simple logic that assumes each validation check is going to be DEFAULT_SIMULATOR_TICK_RATE_SECONDS_PER_TICK seconds apart. This works fine for only simulated tests, but as we combine field and simulated tests under the same interface, we need support for field tests where each tick's duration is going to be dynamic.
Right now, the duration and delay validations pass super quickly, meaning that the duration of each tick is way faster than 1/60 of a second, which is the value of DEFAULT_SIMULATOR_TICK_RATE_SECONDS_PER_TICK. A possible approach to this issue is the TimeProvider class which is a global singleton that should be the single source of truth for anything related to the time since gameplay has started.
Acceptance criteria
Blocked By
#3744
Description of the task
The delay and duration validation classes are used to modify other validations, to add a delay or a duration that the validation has to be valid for. However, these validations were implemented using simple logic that assumes each validation check is going to be
DEFAULT_SIMULATOR_TICK_RATE_SECONDS_PER_TICKseconds apart. This works fine for only simulated tests, but as we combine field and simulated tests under the same interface, we need support for field tests where each tick's duration is going to be dynamic.Right now, the duration and delay validations pass super quickly, meaning that the duration of each tick is way faster than 1/60 of a second, which is the value of
DEFAULT_SIMULATOR_TICK_RATE_SECONDS_PER_TICK. A possible approach to this issue is the TimeProvider class which is a global singleton that should be the single source of truth for anything related to the time since gameplay has started.Acceptance criteria
DEFAULT_SIMULATOR_TICK_RATE_SECONDS_PER_TICKBlocked By
#3744