Resets and repops

[claw at null.net]

On 27/03/97 at 11:00 PM, Adam Wiggins <nightfall at inficad.com> said:
>[JCL:]

>> An old scenario, much like the Elven forest/Sceptre/Castle Krak
>> scenario we used to bounce ideas off.
>> 
>> The actual scenario was called "Bubba and the Crystalline Tree", and
>> dealt fairly simply with our friend Bubba who managed to climb a
>> crystalline tree.  This was no mean feat as Bubba is a very heavy chap
>> whose weight *should* break the tree, dropping bubba to the ground. 
>> The scenario is:
...

>Heh...well...we have the obvious, ugly solution to this.  Every timer
>pulse (currently .25 seconds, I think)...

True, that's the classic solution.  Problem is that I haveno such
thing as a timer pulse.  I could forge one from a timed event which
just keeps re-generating itself, but I see no reason to break a
perfectly decent event driven model.  The nice thing is that you can
engineer a decent event driven solution as well:

-- The containment methods for the CT install watchers on everything
that gets added to them. -- The watchers trigger on any state change
to the watched object. -- Should the watched object leave the CT, the
watcher deletes itself. -- The watchers monitor the sum weight of the
objects, and report that to the CT on each state change for
appropriate handling. -- Thus *any* action which directly affects an
object in the CT will trigger a watcher, and result in the desired
action. -- Problem: an object whose reported weight is dependant on
the state of a remote object.  (eg the weight of the ballon is
proportional to the total weight of a bucket in the castle.  Add rocks
to the bucket in the castle, and the balloon gets heavier. This is not
so easy to solve if the ballon is written to determine its weight only
when its is queried.)


A related discussion of the DemonWroth which came directly from the CT
illuminates.. Note that I used the term "monitor" back then, where I
now use "watch" or "watcher".

-- <cut>--
I had another look at this specific area over the weekend and came up
with the following:

There are three important processes here:

  1) Determining that an object (no  longer) needs to be monitored.
  2) Determining that a monitored object has changed and thus
triggering the
       monitor.
  3) Determining what changed.

Harking back to the example of the Great God GooGoo and his holy
relics, #1 is pretty easy in that instance.  GGGG knows ahead of time
what objects he needs to monitor, and this can be hardcoded at the
time GGGG is programmed.

In the case of the Crystalline Tree, #1 is not so simple.  Any object
that is located within the CT needs to be monitored, however those
objects could arrive in the CT as the result of a normal entry (moving
from room to room in the normal and predicted manner), or as the
result of a teleport (*Bink!*  Its there!).  Similarly objects could
be removed from the CT in the same manner, requiring that monitoring
stop.

This is fairly elegantly addressable by altering the base container
methods on the CT to install and remove the monitor on the contained
or removed object.  Simple, elegant, guaranteed.  When ever an object
is added to the contents list it gets a state change monitor installed
on it, and when ever it is removed the monitor is removed.

Other watcher relationships might be less elegant.  Instead of a
simple question of containment (eg the CT watched everything within
itself), it could be some more indirect relationship (eg the
DemonWroth watches all character objects (players) that have ever been
in the same room as the PrincessBride, until those objects have been
in the same room as the GGGG).   The the question is coding this with
all the normal rules intact.

One solution is to have the DW spoof the containment methods on the PB
so that every time the PB enters a room a spoof is set on the room
(and removed from the room she left).  The spoof overlays the
containment methods on the room so that it in turn installs monitors
on any objects that enter the room, _and_ spoofs the object to overlay
_its_ containment methods to check for the presence of the GGGG when
ever it enters a room (and remove the monitor and the spoof if it
does).

Diagrammed:

  DemonWroth installs spoof on PrincessBride
    Spoof(PrincessBride) adds features to
PrincessBride.I_am_contained_by
      and PrincessBride.I_am_leaving_container.
      Spoof(PrincessBride).I_am_contained_by spoofs the room the
        PrincessBride is entering.
      Spoof(PrincessBride).I_am_leaving_container removes the same
spoof
        from the old location.
        Spoof(room) adds features to the room.contain_objects.
          Spoof(Room).contain_objects installs monitors on any objects
            which enter the room (call it "thing").
            Monitor(thing) reports back to the DemonWroth.
          Spoof(Room).contain_objects spoofs the object (thing) that
just
            entered the room, adding features to
thing.I_am_contained_by.
            Spoof(thing).I_am_contained_by checks every room the thing
              enters to see if the GGG is there, and if so removes
itself
              (the spoof), and the monitor that reports back to the
              DemonWroth
--<cut>--

None of this really handles the problem of the indirect state changes
however.  I can't think of an event driven solution to that sort of
bad (non-localised) programming.

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