Overall functioning of the package
==================================
The watcher should watch for events sent to it and act accordingly.

It's done to force some stuff to be executed without multi-threading (sometimes,
having things running all at the same time totally independent is not what you
want).

At its start, it should set its PID in a global property. Now that it's PID is
available, other scripts can send events to watcher.

The watcher can only understand struct-type events. It's also expecting this
struct to have a member called 'type', which is supposed to be an integer.

By checking the event's type against pre-defined types, the watcher decides
what to do with that struct and everything gets done.

The watcher heavily relies on the reminder script. They work together as a 
team: one supporting the lazyness of the other :-}. One does things (the 
watcher) and the other one reminds the "doer" of things.

The reminder will also write its PID in a global property so it becomes 
available to other scripts. And it'll also watch for events. Those events will
be also struct-typed and they need a 'type' member too. Those events differs
beause they need two more members: 'when' and 'after'. The 'when' member should
be set to the time the event was created. The 'after' member should be set to
the number of seconds that should be waited before the reminder reminds the
watcher of this event.

Example of usage: poisoning.

	After the player P does something to get poisoned, the system sends an
	event to the watcher with this information:

		type=>poison_set
		level=>2
		ps=>[P's serial]
	
	The watcher script looks at the type, sees if it can or not handle it (in
	this example I'll be supposing it can handle poison_set events). Then,
	the watcher sets the player specified by the serial 'ps' to be poisoned and
	that this poison is a level 'level' poison, which is 2.

	The script that sent the event to the watcher will also send some events to
	the reminder. Let's suppose this level 2 poison causes the player four 
	damages of 1d5 damage each and that they should be spaced by 4 seconds. The
	poison script should, then, send all those events to the reminder:

		type=>poison_dmg
		when=>[now]
		after=>0
		dmgdice="1d5"

		type=>poison_dmg
		when=>[now]
		after=>4
		dmgdice="1d5"

		type=>poison_dmg
		when=>[now]
		after=>8
		dmgdice=>"1d5"

		type=>poison_dmg
		when=>[now]
		after=>12
		dmgdice=>"1d5"

The reminder is always looking at its internal list of reminds (the reminder 
queue) to remind the watcher. If there is anything it should remind the watcher
of, it'll. If none, it'll wait for an event.

To help reminder's efficiency, its reminding list should be sorted according to 
the sum of the 'when' and 'after' fields of each event in that list.

Note that the reminder queue should be inside a global property. That is
necessary for spells such as cure. For example:

	Six seconds passed, which means that the first two events of the previous
	poison script were already sent to the watcher and the due actions were
	already taken. However, the last two weren't.

	The player, then, uses bandages and gets cured. Now the cure script will
	send an event to the watcher. It should be like this:

		type=>cure
		level=>3
		ps=>[P's serial]
	
	The watcher, after seeing that 'type' is 'cure', should do something so
	that it doesn't get reminded to apply poison damage to that player. He
	will, then, loop through the reminder queue and erase all the ones of type 
	equal to 'poison_dmg'. Of course that this should only be done after 
	checking the poison level against the cure poison level.

While the watcher is modifying the reminder queue, the reminder should 
stop working on it.

It's possible to freeze the reminder script. If you set the global property 
defined in the constant REMINDER_SET_FROZEN_PROP to 1, the reminder will stop 
waiting for events until you set that property to 0 again (note that the 
reminder always start unfrozen).

When that property is set to 1, as soon as the reminder sees it, it'll set the 
property that has its name defined in the constant REMINDER_IS_FROZEN_PROP to 
1. That is necessary because the reminder may be in the middle of a process
and cannot freeze right in that moment.

Always wait until the property REMINDER_IS_FROZEN_PROP is set to 1 before 
supposing the reminder is frozen. When you set REMINDER_SET_FROZEN_PROP to 
something different from 1, the reminder will set REMINDER_IS_FROZEN_PROP to 0.

Both REMINDER_SET_FROZEN_PROP and REMINDER_IS_FROZEN_PROP constants are defined
in ":watcher:include/watcher".

**NOTES**
1. All the identifiers used in the examples were only chosen for the sake of 
simplicity. There is no guarantee that their names match the names used in the 
real code of this package.
2. You should not use "type", "when" and "after" as members of your event.
3. The members "when" and "after" of an event are not removed in the reminder
script before sending the event to the watcher script.
4. Waiting for the reminder script freeze itself may take some miliseconds.
Always expect to wait 50ms before getting the freezing confirmed.
5. Support for miliseconds value for the 'after' member of a reminder event
will be added in the future.

Reminder's start up
===================
Before starting to look for events, the reminder does some initial start up.

It, first, loads its last used reminder queue. After that, it will set all 
the 'when' field of all events to its argument, also called 'when'. This 'when'
argument should be configured in the start.src script inside the watcher 
package. It's currently set up to the result of a ReadMillisecondClock() call.

After that, everything is pretty much set and it starts doing what was 
explained above.

The chat event
==============
The chat event should be used for requests performed by the chat system. The 
chat system should only use the watcher in cases of join and leave quests.

The chat event is expected to have those members:

	- type
	- subtype
	- ps
	if subtype == WE_JOIN
		- name
		- passwd

Description of memebers:

	type
		Should be WE_CHAT.
	subtype
		Should be WE_JOIN or WE_LEAVE.
	ps
		The player serial the watcher should operate on.
	name
		The chat room name the player will join if subtype is WE_JOIN.
	passwd
		The password the player typed to be used in the join process of chat
		room named 'name' if subtype is WE_JOIN.

Error checking in the watcher
=============================
The watcher doesn't do any error checking. It even doesn't check if the event
has a 'type' member. There is no default instructions to be executed if the
type of an event is not identified either.

Perform all the error checking before sending the event.

The reminder doesn't do much error checking either.

Possible common questions
=========================
1. How to check if both reminder and watcher scripts are running?
A: Check for the global properties storing their PID.
