events; da.events.muf - calendar of events
eventEVENT - display detailed event information about EVENT.
event -all- list all events
event -nextn - list all events within next n days
event -new- make a new event
event -delEVENT - delete event EVENT
event -renameEVENT - change event EVENT's title
event -reschedEVENT - change event EVENT's time and repeat status
event -redescEVENT - change event EVENT's multi-line description
event -remiscEVENT - change event EVENT's write access and notification status
event -update- do nothing but check for elapsed events on this list
event -personal- Make this event list personal (ignore write access)
event -access- Change this event list's read access
event -calendar- Toggle list's calendar status (times shown in author's time zone)
event -time- Change my time display format for this event list
event -quiet- Toggle my listening to elapsed events on
event -trigger #dbref - Assume trigger object is
#dbref (in conjunction with other options)
strftimeformat to use to display event times in the
eventsis linked to this program, and this documentation will assume that you are using the
eventsglobal, though you may of course use the same commands for any event list.
events -alllisting. It should say what the event is.
This listing shows, from left to right, the event name, the time it occurs, the event's repeat status, its title, and (if the list is not personal) the event author, i.e., the player to contact about this event.
The single-character repeat status is blank if the event does not repeat, a single integer specifying days between repetitions for regularly repeating events, or an asterisk for repeats given in terms of a parsetime rule.
If the contact player ends with "...", you will need to display an event in its entirety to see the full list of contacts.
Since this list may be very long and you may not care about events far into the future, you can limit the listing to the events within the next n days with the command:
To display detailed information about an event, including its repeat status, complete list of contacts and description, type
where EVENT is the event name you want details on.
and answer the long list of questions. Each of the groups of questions is given its own section below. To abort at any time, type a single dot (".").
If the event does not repeat, answer "n" to the next question, otherwise type "y". If you answered yes, you will be asked to say when the event repeats. If the event repeats at the same time every day, or the same time every n days, simply type that number (e.g., "7" for a weekly event).
If your event does not repeat with precisely the same period (for instance, it is a monthly or annual event, or it repeats every 29 days, 6 hours and 12 minutes), you can enter a parsetime string, which will be interpreted just after the event elapses, and whatever time parsetime evaluates the string to be will be the next time the event occurs. Thus for an event that happens on the first of every month, the repeat rule could be "midnight 1st"; for an annual event every May Day, "midnight 1st May"; for an event that happens every lunar synodic period, "now +29d +6h +12m".
Then you are asked if the event should announce itself. If you answer "y" then the event will notify all connected players on the read access list about itself when it is added, and will also notify all connected players on the read access list when the event elapses.
You are not asked to confirm the deletion and you cannot undelete an event, although it may be possible to recall some of the data from the event. Contact the author of events if this happens.
All players with write access to an event may delete it.
-resched, you are first asked if you want to claim ownership of the event. If you answer yes, you are now the owner of the event and all times you subsequently type will be in your time zone using your language locale. If the event repeats using a parsetime rule, it will almost certainly be wrong unless you are absolutely sure that the original author has the same time zone and language locale that you have. You will be warned if this is not the case. If you answer no, the event remains owned by the original author and you will need to type the time of the next occurrence using that player's time zone (but your language locale). However, because you are not relevant when the event elapses, if the event repeats according to a parsetime rule, it must be typed in terms of the author's time zone, using the author's language locale. This probably won't matter unless the author has changed its language locale information (see timelib for much more). It is probably best to claim ownership of an event in this case, or have the original author do all rescheduling.
When you enter a new write access list for an event with
-remisc, it is your name,
not the author's name, which you leave off.
events -updatewhich simply checks for elapsed events and announces them if necessary. You can use this command to force an event to be announced if it has elapsed but not yet been announced because no one has run
events can, in conjunction with the
#dbrefoption, list or notify you of elapsed events upon
connection by placing an appropriate string in your
_connect property. Commands to automate this will be
included in a future version of events.
To prevent spamming players with unwelcome event
notifications from badly set-up event lists, if the read access of
an event list is
unset (i.e., anyone may access the event list), events will only be
announced if the trigger action is a global, that is, it is located in
Any player may choose not to see elapsing event notifications with the
and follow the instructions. Note that you, as the event list owner, are always included in this list. To forbid everyone else from using your event list, type a single space. Otherwise, type the names of other users who are allowed to use the list, separated by spaces.
From now on, events are displayed without the "Contact" field, and the write access list for all new events will be made equal to the global read access list. Note that existing events' write access lists are unchanged. Making a list personal is purely for convenience and does not provide any extra functionality.
You can still see the local time an event occurs by viewing the detailed event information with
Note that with this option set times may appear out of order on listings. If your time format contains the string "%Z" then you will see the author's time zone on each line.
This will silence messages about elapsing events without affecting anyone else.
events -nextn listings. You may want to do this if you prefer 24-hour time, or if you don't want the time to be displayed at all (on a celandar that is purely for listing day-long events like birthdays), or whatever reason. da.events.muf uses timelib for its time display functions, so your format should be as per the
strftimeformat. Because of strict width restrictions, you are limited to a format which produces strings 19 or fewer characters long. This should be long enough for most formats. It is also because of these restrictions that events cannot use your locale date and time formats, as set by
date -format. To set your format, type
and follow the instructions.
events PANIC: Illegal parsetime format on eventEVENT
events -rescheduleEVENT. to delete it, type
reschedules in the past.
events -rescheduleEVENT. to delete it, type
date -zone, for instance), the event will not be scheduled properly until it elapses and reschedules itself (for a repeating event) or you use
events -reschedEVENT and press "." to retain all current values. This is because
eventsstores times internally in UTC for efficiency, which will no longer be correct if you change your DST rule. Yet another reason not to use the "on" and "off" DST rules. I'm beginning to think maybe I should remove them . . .
It's entirely possible for an author to grant write access for an event to a player and for that player to revoke write access to the author. This may be considered a feature.