[crossfire] Proposal: Unified event system

[Alex Schultz]

These things that exist or are planned all use some event-type constructs:
-the plugin system
-the callbacks from common to server
-the proposed refactoring to have "method-like" function pointers for
objects and/or object types.

All three of those things could be set up to use a unified
event/callback system, which would:
-benefit plugins by making it more flexible
-get rid of ugly stub hacks
-reduce repeated effort on the "method-like" system for objects.

I propose that an event system be implemented that would work well for
all three purposes efficiently:

-Event hooks however can be: global, per-map, per-arch, and per-object.
    -All events can be hooked as a global event
    -Events pertaining to a map or an object in a map can be hooked per-map
    -Events pertaining to objects can be hooked as per-arch or per-object
    Essentially meaning, everything that can be hooked per-object or
per-arch, can be hooked per-map, and everything that can be hooked
per-map can be hooked globally.
    
-Event hooks can be given priority, with 0 reserved for core server
callbacks. Priority stored in an SINT8, so it can range from -127 to
127, and negative means it happens first.
    -This allows useful things such as setting hooks to run after a
player is teleported, or before

-The return type of calling an event depends on the event, and some
events don't return a value; events act as callbacks of sorts, however
multiple callbacks can be assigned to an event.

-For events that return a value, hooks may or may not return a value.
Hooks can be set to active or passive, active ones have a chance of
returning a value whereas passive will not. When an active hook returns
a value, active hooks of lower priority will not be run, though passive
ones still will be.
    -This is to in principal allow hooks that may override the default
return of a callback, while also allowing passive hooks to still run
both before and after.

-Events with no return value only allow passive hooks
    
-For events without return values, hooks may at runtime opt to force
priority 0 (default server internal) or lower, not to run.
    -This is to allow hooks for events without return values, to stop
default server code from running. This achieves the same purpose as only
the first active event that returns a value, running for events that
return a value.
    

I believe this type of event system could make a more solid event
architecture to base the plugin system off of, replace callbacks from
common/ to server/, and act as a base refactoring of type-specific code
on. Does anyone have any objections or suggestions (or better ideas for
a unified event system)?


Alex Schultz