[MUD-Dev] Re: atomic functions

[J C Lawrence]

On Wed, 6 May 98 22:59:33 MST 
Chris Gray<cg at ami-cg.GraySage.Edmonton.AB.CA> wrote:

> [J C Lawrence:] 

>> What if this event daisy chain didn't start from a user command,
>> but was generated by a mobile attempting its normal business of
>> wandering the land?  If the event chain dies with that failed event
>> the mobile itself "dies" -- there are no more events to "animate"
>> it.

> Why must it die? 

There's some underlieing logic going on that mandates this: (I expect
you know this already from the discussions on this area a little over
a year ago).

Events are the ONLY things that are capable of logging new events.
Translation: A successfully executed event is the only thing capable
of causing another event to be executed in the future.

An object is "animated" because of an by an event chain.  Somewhere
back when, there was an "original" event which started the ball
rolling.  That event ran, compleated, and logged a new event.  That
one ran compleated, and logged a new event.  And in this manner, ad
infinitum thru time until the present, the events have daisy-chained,
each one created by the one before, jerk-stepping the mobile thru
virtual reality in seeming animation.  

What would happen if one of those events utterly failed to compleat?
The mobile would die.  Nothing would log a "new" event for that
mobile; nothing would animate it.  There would be no executing events
to log future events to keep the process of change going.  It would
just sit there, utterly dead, until something _external_ came along
and changed it.

Yes, you could do multiple and parallel event chains as you discuss
below.  But what happens if the "master" chain dies?  Do you have a
watchman chain whose only purpose is to ensure that there is a valid
running master chain?  What if the watchman dies?  

This is thorny problem -- solvable, but not elegant.

> From a naive point of view, you want it to stop digging the canal
> because something prevented it from continuing. The digging event
> chain doesn't have to be the only event chain that exists for the
> NPC. It could have a normal chain, that, because it is currently
> digging, doesn't do things like wandering away, but can still do
> things like poses, simple interactions with PC's, etc. The question
> then becomes that of how the main chain knows that the dig chain has
> terminated.

True.  I do this by keeping state variables in the mobile object
(acutally they are activity masks and are thus used to limit possible
simultaneous action).  Thus the digging chain, as you say, runs in
parallel with the "main" chain.  The main chain keeps popping to life,
checks for validity and mostly finds that its inapplicable due to the
digging chain and goes back to sleep by logging a new future event.

> Alternatively, and perhaps simpler, would be to not have a specific
> chain of events for digging, but have a "current background
> activity" function reference attached to the NPC. In its normal (and
> hopefully never failing) chain of activity events, it calls that
> function periodically, and if the function indicates failure, can
> cancel the function by removing the reference to it. Didn't we talk
> about this a while back, including things like having various
> priorities attached to such automated activities?

Yes, yes, I think this came up in the extensive discussion of
attempting to discern a concept of the "intent" state of a player by
noting simple characterisitics of his play style.  Yes....This could
be interesting.  Yes, The character and number of parallel event
chains can effectivly function as the intent stack (see earlier
thread) of the mobile...

--
J C Lawrence                               Internet: claw at null.net
(Contractor)                               Internet: coder at ibm.net
---------(*)                     Internet: claw at under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...

--
MUD-Dev: Advancing an unrealised future.