It's possible to do something very much like TigerLily's %after command on the server, which has the potential to be a very good thing.

A braindead implementation might look like:

{sTime,sCmd} = args;
iTime = $string_utils:parseTime(sTime);
player:notify("(in " + tostr(iTime) + "s, I will run '" + sCmd + "')");
fork (iTime)
  force_input(player,command);
endfork

This version would let you do something like:

/after 10s "Prisoner;nanny nanny doo doo!"
/bye

which would cause Prisoner to see:

*** Jerk has left lily ***

>> Private message from Jerk:
- nanny nanny doo doo!

So, clearly some thought would have to go in how to make this safer. Anyone want the feature enough to thunk out how it should work? (just gedanken is fine.)

-- CoKe - 29 Dec 2003

Note that there is the beginnings of a scheduler in the current core, although it is not used for anything yet. The code is there, but it isn't running (which implies that it might not actually work yet...). That code looks very useful for scheduling system tasks, I do not know if it could be used for this.

I wouldn't want anything close to two-second granularity on events. Consider the system 'at' command on FreeBSD: "Note that at is implemented through the cron(8) daemon by calling atrun(8) every five minutes." So, the best you can hope for is asking for something to happen at a 5-minute interval.

I'd much rather have something that works like that, with a single task that looks for events, than having perhaps hundreds of forked tasks running. Also note that it's probably a bad idea to assume 'force_input()' is reentrant -- and even if it is, there is a mighty good chance that most of our code is not. Thus, you don't want to just wake up and call any arbitrary verb. You'd want to set some flag that the regular player's task could pick up, perhaps in do_command() processing.

I do think this could be a useful feature, but we will have to spend some time to come up with the right implementation.

-- GaranceDrosehn - 30 Dec 2003

The existing scheduler implementation is design to do just that. Rather than having a ton of forked tasks, the scheduler was a single task which runs events and reschedules events which repeat. The two issues we were concerned about were drift (from serially running lots of little tasks at the same time) and accuracy. There was also some stupid error I made in writing that caused it to behave strangely, but someone could probably identify that problem quite easily.

-- ChristianRatliff - 30 Dec 2003
to top