[MUD-Dev] C&C and Event Rescheduling

[Jon A. Lambert]

On 12 Sep 97 at 16:04, clawrenc at cup.hp.com wrote:
> 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:
[snipped sample code]
> 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?  

Only that it is flagged (or not flagged) as an event method.

> 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.

Correct.  Such a method might be coded, but correct or intended 
execution is not guaranteed, since in calling "event" methods 
within nested transactions demands that the programmer acknowledge 
the asynchronous and independent nature of the called events.

Two solutions come to mind:

1) Copy the Move event code within the new move method.  I can't
envision coding the above example.  Which is really a macro-event
much like a player entering the commands:

east;fill bucket with water;east;empty bucket on fire

Such a macro command would never be considered atomic in my game. 
Would such cases be exceptional enough that duplicating code is 
sufficient?  If it was not considered atomic in all(?) cases then 
"Move" would not have been implemented as an event.

Although, I'm sure I will stumble onto other examples. 

2) Allow polymorphic determination of which method to call.
    event Move(20,east) or Move(east)    

Requires some code restructing to avoid unneeded duplication. And 
would need some work as I currently don't allow intra-class 
polymorphic methods. 

Note: Event rescheduling is explicit. 

I realize I must also come up with a reasonable representation of the 
dragon's dinner scenario.  :) 

--
Jon A. Lambert

If I'd known it was harmless, I would have killed it myself.