[MUD-Dev] Re: Re: Re: World Event Model [Josh Rollyson] (long/technical)

[Christoph Seifert]

Hi,

Josh Rollyson <dinodrac at summit.magenet.com> wrote:
> Josh:
> An alternative to executing the command over and over would be to
> have a flag system, such as 0 to 3.  0 is say pause, the command
> qeue can pause it, 1 is execute, 2 is re-execute, 3 is re-execute if it
> failed
> In this way, the player could keep trying to kick until he was successful...
> all a value of 3 or 2 would do is to re-add the command, in this way
> any command could be easily flagged as re-occuring.  Hence, all you would
> need
> is an 'attempt' command, which would just do it once, otherwise you try
> until
> successful or something along these lines...

I like this idea of having the possibility to re-execute an activity.
The pause flag would be the same as a suspendable flag and 
1 would be a normal activity I guess. 2 - re-execute I would implement
differently with a Suspended member function of the Event class which
could be overwritten by derived event classes - details below.
The re-execute if failed part could be integrated into the Event itself,
which can decide for itself very well, wether the activity was
successful
or not.
Anyway, thanks for this input :-).
I am looking forward to other input and again especially for comments
on the priority handling of events. Added is a draft about suspended 
events which I developed the recent days. Comments for that are welcome
as well of course.

Christoph

Drafts for adding suspended events:

Events here are activities a character can be involved in - other
types of events should not be suspended, but just be overwritten
if the names of the events match.
(note: no suspend or overwrite of other activity events listed on
 other types of event objects like items or rooms)
Events have a set of flags to classify them and a suspendable flag
has to be set in order to make an event being overridden gracefully.
(See previous posting on the event system and the flags used
 for priority handling)

Each new event calls a generic Check function for every event
object involved e.g. character->Check(new_event) and installs
itself on the event objects, if the Check function was positive
for all objects e.g. with character->Add(new_event).
Each event object holds a list of events it is involved in -
regardless of its role. The generic Add function adds the new
event to the front of these lists.
Now the new event is checked against each old event for activity
conflicts before it gets added. If the old event is a locked one
i.e. protected against being overwritten, the new event will be
suspended and checking stops, otherwise the old one will be
suspended - that is calling Suspend function regardless of
suspendable flag set or not. This way of adding new events and
checking from front secures, that clashing activities are not
executed at the same time - more in an example later on.

The Suspend function takes two arguments: higher (priority) event and
lower i.e. suspending and suspended event:
- checks wether lower event can be suspended - if not set finished flag
  on lower event and return
- create or find slot for suspending event in a sorted list and add
  suspended  event to the list of blocked events, increasing suspended
  counter of suspended event by 1 - explanation below, why a counter
  is preferred to a flag (and why an event can be more than once in
  the blocked list)
- call Suspended member function of suspended event - this would allow
  the event to decide what to do if suspended e.g. reset event to
  starting point (following Josh Rollyson's ideas of adding
  a capability of re-executing events). Example: kick should be reset
  as event, as a kick needs some preparation.

An entry on this list looks like A -> B, C : event A pointing
to a list of blocked events including events B and C.

The event scheduler neither executes nor deletes a suspended event
and calls a Release function when an event is finished and gets
deleted. This function removes the entry from the
suspending-suspended list and decreases the suspended counter of
each event blocked by the deleted event by 1. A counter of 0
is the same as event not being suspended. 

Example for one event object a and several activities A, B, ...:

Add event A:

   a: A

Add event B clashing with A:

   a: A, B ;  A -> B

Add event C clashing with A, but not B:

   a: A, B, C ; A -> B, C

Add event D clashing with B, but not A:

   a: A, B, C, D ; A -> B, C ; B -> D

Now finishing A releases both B and C which do not clash with other,
but the clashing D event is still suspended.

Explanation for using a suspended counter instead of just a flag:

Here the example with only suspended flag:

Imagine objects a, b and events A,B,C,D having activity conflicts with
each other
First add A to both objects:

   a: A ; b: A

Then B to object a:

   a: A, B b: A Suspending: A -> B - B got suspended flag set

Then C to object b:

   a: A, B ; b: A, C ; A -> B, C

Then D to both objects:
   a: A, B, D ; b: A, C, D ; A -> B, C; B -> D AND C -> D

The worst case is that B gets finished before C does (or vice versa)
- this way the suspended flag of D would be removed, object a could
do something which object b is not yet ready for leading to a possible
deletion of Event D before C is finished.
This would be a corrupt pointer in the list of suspending events :
C -> D

Example with suspended counter (added in ()): 

Add Event A to both objects:

   a: A, b: A

Add Event B to object a:

   a: A, B ; b: A ; A -> B(1)

Add Event C to object b:
   a: A, B; b: A, C ; A -> B(1), C(1)

Add Event D to both objects (a first):

   a: A, B, D ; b: A, C, D ; A -> B(1), C(1); B -> D(1); C -> D(2)

Now finishing A releases both events B and C, which can
proceed independently as they are on different Event objects.
Now finishing either B or C reduces the suspended counter of
event D to 1 - but only after both events B and C are
finished will event D be released - with suspended counter
being zero.



_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev