Date/time redo reset options

[SXRWahrheit]

(Required) What is your Quests version / build number (do not say "latest")? b169

(Required) Please describe the problem and how to replicate it. Any console errors? Currently, Quests only offers a redo-delay option for quests. Like more traditional MMOs and to stimulate server activity around desired peak times, I would like to be able to implement a "daily/weekly" reset time. Then, players can sign on to all complete quests together. I can manage non-Quests resets with Denizen, but I can't even script this on Denizen because there is no questadmin command to eliminate redo-delay from players, and it seems like this would be a broadly used and appreciated feature, so it would be best if it were implemented into Quests directly.

(Optional) Can you provide an example quest from quests.yml using Pastebin.com? Current:

  Daily Fishing:
    name: Demonstrate your fishing skills (Daily)
    redo-delay: 43200
    npc-giver-id: 11
    requirements:
      quests:
      - Teach the newbie to fish
      fail-requirement-message: '<gray>Fishing Newbie<white>: You need to teach me
        how to fish first!'
    ask-message: '<gray>Fishing Newbie<white>: Could you show me a little more of
      your fishing skills?'
    finish-message: '<gray>Fishing Newbie<white>: Awesome! Maybe someday I''ll be
      as good as you are!'
    stages:
      ordered:
        '1':
          fish-to-catch: 16
    rewards:
      money: 50
      quest-points: 1

Conceptual version:

  Daily Fishing:
    name: Demonstrate your fishing skills (Daily)
    redo-day-of-week: MONDAY,WEDNESDAY,FRIDAY # Optional, use this OR redo-day-of-month
    redo-day-of-month: 1
    redo-time-of-day: 1900 # hhmm
    redo-timezone: -5 # Relative to UTC
    redo-months: 1,3,5,7,9,11 # For the odd user who wants a quest available every 2 months
    redo-years: 2018,2020,2022,2024 # See above
    npc-giver-id: 11
    requirements:
      quests:
      - Teach the newbie to fish
      fail-requirement-message: '<gray>Fishing Newbie<white>: You need to teach me
        how to fish first!'
    ask-message: '<gray>Fishing Newbie<white>: Could you show me a little more of
      your fishing skills?'
    finish-message: '<gray>Fishing Newbie<white>: Awesome! Maybe someday I''ll be
      as good as you are!'
    stages:
      ordered:
        '1':
          fish-to-catch: 16
    rewards:
      money: 50
      quest-points: 1

An alternative to timezone could be a list of all timezones and an option to automatically check DST or not. However, Guild Wars 2, for example, just uses UTC for server time and it seems to work fine. People adjust to the 1-hour change on boss rotations etc.

If you need explanations of how I designed the config options, let me know! I tried to think of all possible use cases and easy ways to accommodate them. The idea is that if the date/time match the config options, the quest becomes doable again.

[SXRWahrheit]

This could also easily be used to set up "holiday" quests only available at certain times of year that automatically reset without admins having to remove + re-add them to the config.

[PikaMug]

Although this feature does sound cool, it may very well be better to include a command to reset redo-delays for some or all players. Otherwise - and although you've done a great job condensing them - the number of quest options to realize this addition looks a little excessive imho. Although, I should note that timezone be determined from the system.

Also, I wonder if /questadmin quit [player] would have any negative effects if used for this purpose. If not, perhaps that followed by a new /questadmin take [player] command?

Leaving open for debate.

[SXRWahrheit]

Timezone from the system seems fine. A combination of quit and take is not desired - the optimal behavior is "if quest is completed, reset availability." I don't want to interrupt anyone's progress. Some games do that, but it's not my intended functionality. :)

I realize the number of options MIGHT be excessive, but they're not all necessary. Here's what my config would look like, which I anticipate would be fairly normal:

  Weekly Fishing:
    name: Demonstrate your fishing skills (Weekly)
    redo-day-of-week: FRIDAY
    redo-time-of-day: 1900 # hhmm
    npc-giver-id: 11
    requirements:
      quests:
      - Teach the newbie to fish
      fail-requirement-message: '<gray>Fishing Newbie<white>: You need to teach me
        how to fish first!'
    ask-message: '<gray>Fishing Newbie<white>: Could you show me a little more of
      your fishing skills?'
    finish-message: '<gray>Fishing Newbie<white>: Awesome! Maybe someday I''ll be
      as good as you are!'
    stages:
      ordered:
        '1':
          fish-to-catch: 256
    rewards:
      money: 300
      quest-points: 5

[PikaMug]

Understood. I am, then, concerned by the "odd user" that wants more functionality like running the event every other month. Expanding to compensate might put us back at your original conception which is still a little wordy imho. Probably gonna sleep on this.

[SXRWahrheit]

Right, what I'm saying is all of the options can be available, but only used by whoever needs them. If you don't care about the time of day, you could exclude that and it would just tick at midnight server time on the specified days.

The benefit of my proposal is it allows users to specify exactly the criteria they want to use, thereby allowing huge customizability with very little effort on the dev side. They get what they want - they just have to define it properly. You don't have to add super complicated methods to calculate their wants and needs.

They could use comma-separated lists for days of the month, two, if they wanted it roughly every two weeks.

The only thing I could think of adding additionally is a redo-week-of-month: 1,2,3,4,5 - that way, players can reset quests on weeks 1, 3, and 5. Or 2 and 4. Or 1, 3, and 4, but not 2 or 5.

Or if you want to allow EXTREME customizability on top of my proposals, you could add redo-dates, and they could specify specific dates out of the whole year, allowing them to customize some wacky schedule of their choosing.

redo-dates:
- 01-09
- 01-22
- 02-13
- 02-24

etc.

I don't think it would be hard to accommodate extra use cases if demanded, but the options I provided initially would probably cover almost every desired use case, especially as compared to no options at all.

[PikaMug]

Given the number of possible combinations, and thereby number of possible config options, I'm thinking this would be better left to a module, Denizen script, or external plugin.

If using Citizens 2, at desired times one could even:

• Block off a physical entrance to an NPC, perhaps even with Command blocks
• Open/close a portal to an NPC, perhaps even with Command blocks
• Configure the NPC to walk/teleport to a specific area

So I think in a similar vein to https://github.com/Blackvein/Quests/issues/24, this is a great idea but there are already options available that can creatively accomplish this without bloating the plugin. I'm going to close this, but feel free to drop new ideas should they arise. Thanks!

[SXRWahrheit]

Your proposed workarounds add needless complexity to the system, and don't really work lore-wise. An NPC seals itself off from the world because I already gave it enough wheat today? What does that do for multiple players? I have to arbitrarily seal off NPCs and only allow players to travel through some arbitrary gate to access them based on a time check? In any other game, you just talk to the NPC, and if you've done what they want already, they tell you so.

Why is a large number of config options a bad thing? They're all optional. And if Quests doesn't provide the API to allow a separate module to handle this, it's impossible for the module to do so, anyway. Right now, Quests only allows a redo-delay to prevent retaking quests within the Quests system itself. That's inadequate to use other features to provide the desired functionality, as described earlier in the ticket, and to do so externally would also be very messy.

[SXRWahrheit]

Put more succinctly - there is no functionality in Quests right now that allows me to, on a player-specific basis, reset a player's ability to replay a quest if they have already completed it / it's not in-progress and the server time is X. There is also no functionality that allows me to use an outside plugin to achieve that result, even if I wanted to, and it would be messier to do so.

Players expect one system to handle all interactions with that system, and they expect to chat with NPCs to know whether they can take a quest, not to have those NPCs arbitrarily blocked off. No other game that I know of handles repeatable quests like that.

[PikaMug]

Our feelings about needless complexity have different targets: you to your server and myself to Quests. That said, I must disagree about using the environment to control NPC access being arbitrary. You mentioned Guild Wars 2 earlier, which is a great example of your point. However, my example would be Destiny, in which there's literally a giant metal gate in Felwinter Peak to keep noobs out of half the level, which can contain NPCs at certain times (see Lady Efrideet during Iron Banner campaigns). Another example would be invisible/gated/blocked paths to zones with bigger monsters throughout the entire Legend of Zelda series, bar Breath of the Wild. So I feel you shouldn't say your logic applies to "any other game" when either of us could be right depending on the application.

Many of Quests's methods are public (including the Quest.redoDelay variable), so I'm fairly certain that a skilled coder could implement this functionality regardless of whether they're using the official APIs. One could even have their code read redo times from the /data folder. My point is it can be done externally. Of course, not every player has such knowledge, which wraps around to my point of putting a few blocks in the way being an easy alternative for the time being.

On that note, I'm just not willing to implement functionality that I consider unnecessarily messy. I could add functionality for NPCs farting sparkles when a quest is completed if enough players "expect" it, but when they want config options to control the direction, velocity, color, particle type, duration and smell of the fart, adding all those options for a single feature doesn't sit well with me (and in this case, exceeds to scope of the plugin).

That said, these are merely my options atm. If you were to submit a PR and/or have another developer work on this or, again, come up with a cleaner implementation, I'd be willing to take a crack at it. But since I'd currently be doing all the work for a setup I don't like, my answer, in this case, is "no."

[SXRWahrheit]

Destiny uses that for a periodic, quarterly event and Breath of the Wild is a single-player game - if Minecraft were single-player, yes, the BotW systems would work. Elsewhere in BotW, though (say, Impa, who gives you your primary quest), when NPCs have nothing for you to do, they tell you so. You aren't blocked from talking to them.

redoDelay is not the same thing as triggering a change in availability. You would need to implement methods for a putative extension author to set quests as repeatable-but-unavailable and then repeatable-and-available.

I'm not asking for NPCs to fart sparkles, and that wouldn't add anything useful to the abilities of server owners to create quests. Timed resets would.

What kind of cleaner implementation are you thinking of? The suggested options are how most configurations for other systems I've used handle resets. Here's another alternative, two separate (mutually exclusive) systems that allow different functionality but in clean ways:

# The repeat timer uses static specifications to reset the availability of the quest when the server time matches the variables specified.
# You can use as many or as few of the variables you like - variables not included in the configuration will not be checked.
repeat-timer:
  weekdays: FRIDAY # If none specified, defaults to all
  times: 0700,1900 # If none specified, defaults to 0000  (midnight)
  months: 04,08,12 # If none specified, defaults to all
  years: 2018,2020,2022 # If none specified, defaults to all
  dates: # If none specified, defaults to to all; list
  - 01
  - 08
  - 15
  - 22
  - 29
# The recurring timer uses an "anchor" time and calculates how often to allow the quest to be repeated by players (if not already active) when server time matches the anchor time plus the specified interval.
# An interval of 1 day, as specified in this example, would reset the availability of the quest at 7PM server time every day, anchored from July 31st, 2017.
# To create a weekly quest, which would reset on August 7th, August 14th, etc., change "days" to 0 and "weeks" to 1, or use 7 days, etc.
recurring-timer:
  seconds: 0 # defaults to 0
  minutes: 0 # defaults to 0
  hours: 0 # defaults to 0
  days: 1 # defaults to 1
  weeks: 0 # defaults to 0
  months: 0 # defaults to 0
  years: 0 # defaults to 0
  anchor: 31-07-2017 19:00

I'm not sure why you think my proposals are messier than using outside systems to hodgepodge together barely-similar functionality. If you could be more specific about what your design goals are and how my proposals fail to meet them, I'm happy to come up with alternative prototypes, like these.

[PikaMug]

Weren't periodic events the point of this issue? And I said "bar Breath of the Wild", meaning excluding.

Sorry, my point was redoDelay could be checked at any time, then be used in conjunction with the /data folder to cause the delay to expire for a player ahead of time or as needed. Could probably just check delay for a specific player through code, just didn't bother to check if that's public or private.

Farts were a silly example. The point was the excessive config options.

I'm not thinking of one, but I know that the suggestion you've just made practically doubles the size of a quest in quests.yml, and that's assuming we don't add more in the future. Guess I should say this is messy relative to the rest of the config options (although it makes me wonder if a separate config might be a good idea).

I don't see something being handled externally as necessarily being hodgepodge'd, but let's agree to disagree. As I said in my comment prior to close, feel free to post new ideas in-case we get a winner.

[SXRWahrheit]

Why is doubling the size of the config a problem if that's what a user wants to do? All of this is optional, and the repeat-timer and recurring-timer are mutually exclusive. The point of the config is to allow users to customize their quest designs, and if a user wants a convoluted quest, they knowingly adopt the complexity in the config.

If you're talking about examples, I take your point, but I think it would be better to have separate example quests for each feature, as users may not take the features to be optional even if you list them as such. I'm happy to help write more example quests, if needed.

In order to implement this externally, an extension would need to check the existing redo-delays of all players and cancel them. Is that even possible?

I'm trying to understand what your principle design objections are to adding this as a main feature of Quests. So far, all I'm picking up is that it would make the config longer (okay, so do most things, and that's a tradeoff of usefulness versus length, where you've given no reason why length should be objectionable and the usefulness is very high) and that you think it exceeds what Quests should do - but I'm having a hard time understanding why. It's a core feature of many online games and would be well-placed in Quests, too. When I first started using the plugin, I was surprised it didn't already exist, and the existing methods make it hard for users to keep track of when they're supposed to log on to play the daily (or weekly, etc) content.

[SXRWahrheit]

Again, put more succinctly - why is having more options bad, if options provide utility?

[PikaMug]

Again yes, it is certainly possible to handle this externally.

I'm seeing part of the problem. You're saying these options would not be present in quests.yml unless a quest has specified them? If so, this is the first time you've alluded to this. Although maybe I should've guessed that since the redo-delay option works similarly.

Having realized that, now my only objection is that the options don't feel streamlined, yet complete... to answer your most recent question it can be confusing and opens the door for more and more options to be requested if there's no line drawn for how customizable it should be. You could say my principle here is to "do it once, do it right" for most users especially if I'm the one whom is likely to be doing it. Laziness aside, think of how we just handled #92. In regards to the new particle effect, we accomplished that with a single new config option (redoable-quest) which let's users pick the effect. There was no need to add anything extra, like from the fart sparkles example. Just one option that covers everything Quests should handle, leaving any niche options to external devices. I'd like to see that same efficiency here.

I'm not saying we can narrow this down to one config option, but how about... initial-start, repeat, and deadline options? initial-start would be a date and time that the quest first becomes available. deadline would be how long the quest is available for and repeat is how long from initial-start until it triggers again. Although these alone would not allow for variation in schedule, one could combine them with redo-delay to make users unable to take the quest every other day, or once every three days, etc. TimerEvent can enforce completion.

So it'd look like this:

  Bi-Weekly Fishing:
    name: Demonstrate your fishing skills (Bi-Weekly)
    initial-start: 08-07-2017@06:00PM_EST <------ or similar format
      deadline: 3600 <------- 1 hour until quest is unavailable... could also use date format
      repeat: 604800 <---- 7 days until available again
    redo-delay: 864000 <------ 10 days, trivial but means user can do every other week while keeping the quest open weekly for new users
    npc-giver-id: 11
    requirements:
      quests:
      - Teach the newbie to fish
      fail-requirement-message: '<gray>Fishing Newbie<white>: You need to teach me
        how to fish first!'
    ask-message: '<gray>Fishing Newbie<white>: Could you show me a little more of
      your fishing skills?'
    finish-message: '<gray>Fishing Newbie<white>: Awesome! Maybe someday I''ll be
      as good as you are!'
    stages:
      ordered:
        '1':
          fish-to-catch: 256
          start-event: MyTimerEvent <----------------- forces player to finish within 12 hours
          finish-event: CancelTimer
    rewards:
      money: 300
      quest-points: 5

This isn't perfect - for example if the player fails to complete the quest in 12 hours, there would be no redo-delay so they could take the quest next week rather than every other week as intended. Would adding fail-quest: true to a timer event trigger a redo-delay?

  MyTimerEvent:
    fail-quest: true
    timer: 1000

EDIT: I suppose the repeat option should be further optional in case someone wants to create a one-time event.

[SXRWahrheit]

I'm not interested in deadline options. I could use timers (yay!) to achieve that functionality if I wanted to, but the intended logic is this:

When the quest timer (recurring+anchor or static) matches server time:
- Check for players who have completed the quest
- Make quest available to them

If a player has completed a quest and it has a repeat timer:
- Tell the player the quest is not available and how long until repeat
OR
- Tell the player the quest is not yet available

If a player has not completed the quest:
- Do nothing

If the player is currently completing the quest:
- Do nothing

I take your point that a timer to expire the quest could be useful - say, if you want to have multiple slates of rotating quests. In that case, though, you would still want to have those quests all expire at the same time for the whole server. Does Quests support this natively? It seems like you'd have to use a script to force admin commands to force them to quit, which works, but not cleanly - and players may be confused if they are online when it happens. They won't get a message like "The weekly quests have ended, and new ones are available" - they'll just see that an admin forced them out of the quest.

I apologize that I didn't make it clear enough to you that all of these are optional; yes, you could exclude all of this entirely, just like the redo-delay. The functionality is merely to allow folks who want to set up repeatable quests on server-wide timers to have the leniency to do so. I think the methods I propose in fact allow a great amount of flexibility without a lot of complicated coding on your end - some plugins have mechanisms to interpret plain English like "every 2 weeks" or something like that; here, the numbers are made clear and can be parsed easily.

I understand your interest in having simple config options, but I think if you use my proposals, you let users achieve the arbitrary complexity that you might worry about, while still providing simplistic coverage, too.

Consider a daily quest:

  Daily Fishing:
    name: Demonstrate your fishing skills (Daily)
    recurring-timer:
      days: 1
      anchor: 31-07-2017
    npc-giver-id: 11
    requirements:
      quests:
      - Teach the newbie to fish
      fail-requirement-message: '<gray>Fishing Newbie<white>: You need to teach me
        how to fish first!'
    ask-message: '<gray>Fishing Newbie<white>: Could you show me a little more of
      your fishing skills?'
    finish-message: '<gray>Fishing Newbie<white>: Awesome! Maybe someday I''ll be
      as good as you are!'
    stages:
      ordered:
        '1':
          fish-to-catch: 16
    rewards:
      money: 50
      quest-points: 1

Or a weekly one; swap the days for weeks, change the lang bits and rewards:

  Daily Fishing:
    name: Demonstrate your fishing skills (Weekly)
    recurring-timer:
      weeks: 1
      anchor: 31-07-2017
    npc-giver-id: 11
    requirements:
      quests:
      - Teach the newbie to fish
      fail-requirement-message: '<gray>Fishing Newbie<white>: You need to teach me
        how to fish first!'
    ask-message: '<gray>Fishing Newbie<white>: Could you show me a little more of
      your fishing skills?'
    finish-message: '<gray>Fishing Newbie<white>: Awesome! Maybe someday I''ll be
      as good as you are!'
    stages:
      ordered:
        '1':
          fish-to-catch: 256
    rewards:
      money: 300
      quest-points: 5

For most people, that will be sufficient. The other options allow a more fine-grained customizability to avoid pesky commenters asking for more, but they don't ruin anything for people who want a more simple approach.

The addition of timers allows another dimension of usability; start a quest a week before Halloween, have it set to expire on November 1st. I like that idea, too, and I think the more options created for time manipulation, the better. And they can all be non-mandatory, of course.

[PikaMug]

A timer event does not determine how long a quest is available like the deadline option, but instead how long a player has to complete a quest once accepted. That said, my suggestion appears to complete your logic (think of deadline answering "Make quest available to them" but for how long).

I'm not sure how it'd work in a script, but for an external plugin or module, sending a message would be as a simple as player.sendMessage("The weekly quests have ended, and new ones are available");

Your new suggestion looks good, but having an option for each possible unit of time (hours:, days:, weeks:, months:, et al.) is less efficient code-wise than say (unit: hours, unit: days, et al.) - minor gripe. I should also digress and say we should take into account date format for either of our suggestions. You put "31-07-2017" which is correct in much of the world, but in the US for example, it'd be "07-31-2017" for whatever reason. Lastly, how long should the quest be available for once the time comes, since you have no deadline equivalent? Maybe we should just make it an hour, but frankly it's hard to know exactly what admins want when we're the only ones discussing it xD

[SXRWahrheit]

I'm in the US and went with the "much of the world" option because I'm sure more folks use the plugin than just the US. I actually edited the suggestion after posting at the realization.

I think deadline is actually a really good idea and should exist alongside this feature - that way, admins can use whatever combination of features they like. I'll even volunteer to help people write their quests using this feature set if they post or create issues about it; just tag me.

I want to say again that I think both repeat-timer and recurring-timer should be implemented; they are designed to be mutually exclusive and serve different use cases. Implementing both will help you avoid requests for one or the other in the future - I'm trying to future-proof here, like you said.

The problem is I think your deadline proposal relies on player-specific timers, and the goal in my design is to have global timers.

How long should the quest be available? My intention - for now - is for many of my quests to be available (and able to be completed) for as long as players like. I don't want to interrupt progress on a quest with a weekly rollover, some players prefer slow and steady.

It might be sensible to have a units option, but it risks them getting the units wrong, adds complexity in terms of having to multiply minutes or hours if they want fractions, and more. I don't think it's bad to have more lines of config as long as those lines add utility, which I think they do here - and clarity.

[SXRWahrheit]

Also, I would change deadline to available-until, or something - deadline implies that the quest must be completed by then. And maybe that deserves an option!

  deadline:
    weeks: 2
    force-quit: true

[PikaMug]

Maybe I'm wrong, but isn't a recurring-timer the same as repeat-timer, but with an anchor? So if I wanted a quest to "repeat" every Friday, I would just set the anchor to any Friday in history and set recur at weeks: 1?

Agreed that "deadline" might not be the best choice of word.

[SXRWahrheit]

Nope, the repeat-timer relies on specific matches, and can therefore use lengths between repeats of arbitrary lengths - I can have a quest reset in February, and then in July, but then again in August. It allows deep customizability for users who seek such functionality and doesn't force them to create multiple quests, each on their own recurring-timer, which would be the alternative.

[PikaMug]

Ah, so the difference is that you can skip units of time. It kinda irks me that my suggestion can accomplish that with just 3 config options (in combination with already existing redo-delay and timer event). On that note, that force-quit option is accomplished in my suggestion with the timer's fail-quest option, I think.

So I guess we're accomplishing the same level of customizability in different formats, which is great! I still feel like my suggestion is more compact, but I could be biased at this point. Almost feels like we should get some third-party or community opinion.

[SXRWahrheit]

Lol, I was just going to say you should reopen this so more people can see it.

[SXRWahrheit]

"Skipping units of time" might seem arbitrary, but I'm almost certain it'd be a requested feature in the future. Like I said, my proposal is an effort to future-proof. I'm also trying to make options to the user transparent, so they don't get stuck.

Also, for clarity of wording - by "user" I mean server owner. I use "player" to refer to server-end users (players on servers).

[SXRWahrheit]

Also, just so every potential commenter can compare, could you write out how you would expect to accomplish the functionality of recurring-timer and repeat-timer using the three config options?

[SXRWahrheit]

Whatcha thinkin' here @FlyingPikachu?

[PikaMug]

@SXRWahrheit Sorry, my schedule has been tight lately. Hopefully someone cares to comment, otherwise I'll be coming back to this at a later date.

[SXRWahrheit]

No problem! Just wanted to keep the conversation going. :)

[bengtsol]

Original reporter and random resident on Wahrheit's server here. I care!

[SXRWahrheit]

Not sure if you maintain a development roadmap or where this is on your radar, but just wanted to bump it in case you wanted to chat about implementation more.

[PikaMug]

This is still something I plan on integrating, but am currently involved in finding a solution for #172 and #320. Plus, there's school, work, and 1.13 getting released soon(ish). Can't make any promises :(

[SXRWahrheit]

No worries! That's why I asked. :)

[PikaMug]

@SXRWahrheit I'm 90% done adding this feature. There's still some minor aesthetics to work on, but I'd appreciate if you gave it a whirl. Someone other than myself should test it before it gets released to Spigot:

http://ci.ac3-servers.eu/job/Quests/297/

In the Quests Editor, you'll notice a new option "Edit Planner" where you can set a Start and End date, as discussed. There is also a Repeat option which is exactly what it sounds like. The Cooldown setting is actually just redo-delay, moved and renamed.

Highly suggest creating a backup of your Quests data prior to testing, even though it's pretty stable.

[SXRWahrheit]

Oh, this is awesome news. I'll give it a try soon.

[PikaMug]

@SXRWahrheit Were you able to experiment at all? Just checking before I close this and post a Spigot release.

[SXRWahrheit]

The setup worked well, I haven't had time to check an actual repetition. No apparent data loss. Probably worth pushing it and fixing bugs after the fact.

The specific implementation is different than I would have liked - the recurring-timer option, for example, would facilitate holiday events, and the current option only allows for stuff like dailies/weeklies/monthlies. Which is a good improvement! But it would be cool to automate as much of the infrastructure as possible.

[PikaMug]

Think I'm inclined to agree, seeing as everything works dandy for me. I appreciate you taking a look!

You're right that I made some compromises, but holidays should be covered if you set the start-date to a given holiday and the repeat to 31536000 (number of seconds in a calendar year / 365 days). Think I'd like to add the ability to be able to just enter "1 year" rather than seconds later on.

Just occurred to me that the code may not compensate for leap years (in fact, it probably doesn't). For anyone reading that needs this, use 31557600 for the time being (number of seconds in an astronomical year / 365.25 days). Hopefully I'll get around to fixing that in the future.