[MUD-Dev] (fwd) Re: Issues from the digests and Wout's list

[clawrenc at cup.hp.com]

In <9705101606.7zjg at ami-cg.GraySage.Edmonton.AB.CA>, on 05/10/97 
   at 12:39 PM, cg at ami-cg.GraySage.Edmonton.AB.CA (Chris Gray) said:

>[Chris L:]
>:A lot of this I think can be provided by having the parser generically
>:detect when it enters a state dependant condition, and when such
>:occurs, to isntall watchers on all the objects on which that state
>:depends.
>:
>:That way you don't actually have to get into the semantic parsing of
>:potential the state changes -- it can be handled by direct maintenance
>:and checking of the state machine itself.

>Hmm. That means that parsing of user input has to be involved in your
>database consistency stuff, since in a multithreaded environment, the
>events triggered by the watchers could be run at any time, including
>at the same time as a thread trying to parse some later input from
>the same user.

Yup, tho this happens for free.  User commands come in thru a
connection object and are handled by just popping an event on the
queue to parse them.  That parsed event then goes and gets executed. 
The change for an incompleat state (eg Which bag?) is that rather than
the user command being default sent to the parsing object to generate
an event to execute it, it is instead sent to a filter object which
picks the back from the menu choice and then sends a compleated
command to the parser object.

In the case of world state-changes affecting this (eg someone takes
one of the bags), at the time the command filter was instantiated (eg
Bugga does "get bag" and gets a pick lists in response) it would also
install watchers on all the objects on whose state it depended (eg all
the bags).  Now, before Bubba selects a bag, Boffo takes one of the
bags.  The state-change on the bag triggers the watcher, the watcher
informs the filter and the filter responds appropriately.  If Bubba's
selection of the bag he wanted was executing while the SAME bag was
being taken by Boffo, then one or the other of the events would fail
at C&C and be rescheduled, and everything would continue as per
normal.

>Doing this also requires that the parser be able to have a pretty
>comprehensive semantic understanding of what all is going on, in
>order that the watchers it plants be able to know when to affect the
>parse. 

True.  I'd expect to bind this into the verbs directly however.  Thus
"get", "put" etc are dependant on physical availability, while "hit"
and the like are dependant on location (close, near, far, gone).

>Presumeably you don't want to just cancel the parse state if
>anything at all happens to any of the objects involved, since many of
>those changes will be irrelevant, and some will not even be visible
>to the player.

Correct.  There has to be some intelligence here.

>Do you actually do anything like this now, and have you thought
>through any actual situations in detail? Anyone?

I have the command filters (ie menu selections) implemented as above,
but I don't yet have any of the state-change monitoring.  Thus the
discussion.

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