<!-- MHonArc v2.4.4 --> <!--X-Subject: Re: Resets and repops --> <!--X-From-R13: pynjNahyy.arg --> <!--X-Date: from tacitus.globecomm.net [207.51.48.7] by mx5.ibm.net id 859607115.80746-1 Sat Mar 29 03:45:15 1997 --> <!--X-Message-Id: 333c205c39d0002#msgSFO01,schwab.com --> <!--X-Content-Type: text/plain --> <!--X-Reference: 199703280559.FAA260743#out1,ibm.net --> <!--X-Head-End--> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <html> <head> <title>MUD-Dev message, Re: Resets and repops</title> <!-- meta name="robots" content="noindex,nofollow" --> <link rev="made" href="mailto:claw#null,net"> </head> <body background="/backgrounds/paperback.gif" bgcolor="#ffffff" text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000"> <font size="+4" color="#804040"> <strong><em>MUD-Dev<br>mailing list archive</em></strong> </font> <br> [ <a href="../">Other Periods</a> | <a href="../../">Other mailing lists</a> | <a href="/search.php3">Search</a> ] <br clear=all><hr> <!--X-Body-Begin--> <!--X-User-Header--> <!--X-User-Header-End--> <!--X-TopPNI--> Date: [ <a href="msg00254.html">Previous</a> | <a href="msg00257.html">Next</a> ] Thread: [ <a href="msg00251.html">Previous</a> | <a href="msg00257.html">Next</a> ] Index: [ <A HREF="author.html#00255">Author</A> | <A HREF="#00255">Date</A> | <A HREF="thread.html#00255">Thread</A> ] <!--X-TopPNI-End--> <!--X-MsgBody--> <!--X-Subject-Header-Begin--> <H1>Re: Resets and repops</H1> <HR> <!--X-Subject-Header-End--> <!--X-Head-of-Message--> <UL> <LI><em>To</em>: <A HREF="mailto:mud-dev#null,net">mud-dev#null,net</A></LI> <LI><em>Subject</em>: Re: Resets and repops</LI> <LI><em>From</em>: <A HREF="mailto:claw#null,net">claw#null,net</A></LI> <LI><em>Date</em>: Fri, 28 Mar 97 11:01:23 -0800</LI> <LI><em>Reply-to</em>: <A HREF="mailto:claw#null,net">claw#null,net</A></LI> </UL> <!--X-Head-of-Message-End--> <!--X-Head-Body-Sep-Begin--> <HR> <!--X-Head-Body-Sep-End--> <!--X-Body-of-Message--> <PRE> On 27/03/97 at 11:00 PM, Adam Wiggins <nightfall#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#null,net ----------(*) Internet: coder#ibm,net ...Honourary Member of Clan McFud -- Teamer's Avenging Monolith... </PRE> <!--X-Body-of-Message-End--> <!--X-MsgBody-End--> <!--X-Follow-Ups--> <HR> <!--X-Follow-Ups-End--> <!--X-References--> <!--X-References-End--> <!--X-BotPNI--> <UL> <LI>Prev by Date: <STRONG><A HREF="msg00254.html">Re: Mixture</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg00257.html">Re: Resets and repops</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg00251.html">Re: Resets and repops</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg00257.html">Re: Resets and repops</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="index.html#00255"><STRONG>Date</STRONG></A></LI> <LI><A HREF="thread.html#00255"><STRONG>Thread</STRONG></A></LI> </UL> </LI> </UL> <!--X-BotPNI-End--> <!--X-User-Footer--> <!--X-User-Footer-End--> <ul><li>Thread context: <BLOCKQUOTE><UL> <LI><STRONG>Re: Resets and repops</STRONG>, <EM>(continued)</EM> <ul compact> <LI><strong><A NAME="00246" HREF="msg00246.html">Re: Resets and repops</A></strong>, Adam Wiggins <a href="mailto:nightfall#inficad,com">nightfall#inficad,com</a>, Fri 28 Mar 1997, 14:07 GMT </LI> <LI><strong><A NAME="00247" HREF="msg00247.html">Re: Resets and repops</A></strong>, Adam Wiggins <a href="mailto:nightfall#inficad,com">nightfall#inficad,com</a>, Fri 28 Mar 1997, 14:11 GMT </LI> <LI><strong><A NAME="00249" HREF="msg00249.html">Re: Resets and repops</A></strong>, Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Sat 29 Mar 1997, 04:15 GMT </LI> <LI><strong><A NAME="00251" HREF="msg00251.html">Re: Resets and repops</A></strong>, claw <a href="mailto:claw#null,net">claw#null,net</a>, Sat 29 Mar 1997, 05:54 GMT </LI> <LI><strong><A NAME="00255" HREF="msg00255.html">Re: Resets and repops</A></strong>, claw <a href="mailto:claw#null,net">claw#null,net</a>, Sat 29 Mar 1997, 11:45 GMT </LI> <LI><strong><A NAME="00257" HREF="msg00257.html">Re: Resets and repops</A></strong>, claw <a href="mailto:claw#null,net">claw#null,net</a>, Sat 29 Mar 1997, 13:26 GMT </LI> <LI><strong><A NAME="00266" HREF="msg00266.html">Re: Resets and repops</A></strong>, S001GMU <a href="mailto:S001GMU#nova,wright.edu">S001GMU#nova,wright.edu</a>, Mon 31 Mar 1997, 23:04 GMT </LI> <LI><strong><A NAME="00267" HREF="msg00267.html">Re: Resets and repops</A></strong>, S001GMU <a href="mailto:S001GMU#nova,wright.edu">S001GMU#nova,wright.edu</a>, Mon 31 Mar 1997, 23:27 GMT </LI> </ul> </LI> <LI><strong><A NAME="00098" HREF="msg00098.html">Re: Room coding</A></strong>, Nathan Yospe <a href="mailto:yospe#hawaii,edu">yospe#hawaii,edu</a>, Thu 13 Mar 1997, 10:29 GMT </LI> </UL></BLOCKQUOTE> </ul> <hr> <center> [ <a href="../">Other Periods</a> | <a href="../../">Other mailing lists</a> | <a href="/search.php3">Search</a> ] </center> <hr> </body> </html>