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
If we restructure the hunters object, we could add a custom reminders field, which would create a per-user custom timeout, and activate a doCustomWarn(timer) method which uses the timer.getDemand() method instead of getAnnouncement(), as is done with the response to the next command.
To build these, I think <keyword> <timer identifiers> <units> <number> (or <numbers> <units>) could work: numbers is parsed to int, bounded positive and non-infinity, and units is normalized then passed to a Duration.fromObject constructor, e.g. warn ... 15 hr -> warn ... 15 hours -> {hours: 15}. The duration would then be bounded to be less than the repeat interval for the associated timer, and less than the max number value 2.14..... when represented as milliseconds.
This data would need to be serialized with the hunters object, and instantiated on load. We could add support for a timeout value longer than the max representable, by having it self-set the next timeout as needed.
Usage
-mh warn <area> [<sub-area>] [<num>]
If sub-area is provided warn only for that sub-area.
If num is provided then warn that many times in 15 minute intervals before the timer or sub-area timer.
Warn only warns once against the next timer.
The text was updated successfully, but these errors were encountered: