[MUD-Dev] C&C and Event Rescheduling

clawrenc at cup.hp.com clawrenc at cup.hp.com
Fri Sep 12 14:47:16 New Zealand Standard Time 1997


In <199708171721.MAA14449 at dfw-ix11.ix.netcom.com>, on 08/17/97 
   at 10:22 AM, "Jon A. Lambert" <jlsysinc at ix.netcom.com> said:

>Perhaps there is another way?  Someone requested (Shawn?) that I post
>an example of a mud language which handled transactions. So here be
>it:

>object Dragon class BigMutha {
> var fatigue_points;
> var location;
> method event Move(var direction) {
>  if Dragonden.ExitStatus(direction) == OPEN {
>   Dragonden.RemoveObj(this);
>   Dragonden.GetExitLocation().AddObject(this);
>   FatigueMe(5);
>   EvaluateSituation(10);
>  }
>  else 
>   SendOut("The Door is Closed");
>   EvaluateSituation(10);
>   throw #EVENTFAIL;
>  }
> }
> method FatigueMe(var points) {
>  fatigue_points = fatigue_points - points;
>  if fatigue_points < 0 {
>   fatigue_points = 0;
>   SendOut("Your too tired to move");
>      EvaluateSituation(10);
>   throw #EVENTFAIL;
>  }
> }
> method event EvaluateSituation() {
>  ...Insert some clever code here 
>  which might at some point select...
>  Move(20,"east");
> }
>}

>The important points are the different types of methods.  Event
>methods form a logically consistent transaction and may call any
>number of methods of any type.  Commit of the transaction is done at
>the end of the event's method.  Also when 
>EvaluateSituation() is called above a new event is logged and it is
>not executed immediately.  The next statement is. 

>Event methods have as their first implicit parameter a timing value. 
>In the above case Move(20,"east") will occur in 20 tenths of a second
>(I hope).

>Comments?

A greviously long quote, but needed I think.

What determines if a method call will be made as a nested transaction,
or as a seperate event?  The problem here is taht a method/transaction
which may normally be considered logically atomic (move character to
next room for example), may have logical dependencies in a specific
event context (transactions which depend on correct order of
processing of nested transactions).  

eg:

  "Move" is an event method as above.
  The code reads:

    Move (east);
    FillBucket (water);
    Move (east);
    EmptyBucket (Fire);

Without each Move only being done and compleated prior to the next
calls, the fire may or may not get doused.

--
J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...




More information about the MUD-Dev mailing list