March 1997
- Linear Quadtrees Carter T Shock
- Linear Quadtrees gzhang1234@yahoo.com
- q-tree stuff Chris Gray
- q-tree stuff Carter T Shock
- q-tree stuff coder@ibm.net
- Issues from the digests and Wout's list Alex Oren
- Issues from the digests and Wout's list coder@ibm.net
- Issues from the digests and Wout's list coder@ibm.net
- Issues from the digests and Wout's list coder@ibm.net
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list coder@ibm.net
- Issues from the digests and Wout's list Chris Gray
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Miroslav Silovic
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Miroslav Silovic
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list Caliban Tiresias Darklock
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Caliban Tiresias Darklock
- Issues from the digests and Wout's list Miroslav Silovic
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Caliban Tiresias Darklock
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Caliban Tiresias Darklock
- Issues from the digests and Wout's list coder@ibm.net
- Issues from the digests and Wout's list Miroslav Silovic
- Issues from the digests and Wout's list Jon A. Lambert
- Issues from the digests and Wout's list Ling
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list Chris Gray
- Issues from the digests and Wout's list Ling
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Chris Gray
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Jon A. Lambert
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list S001GMU@nova.wright.edu
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list Travis Casey
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list Jon A. Lambert
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list Ling
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list Orion Henry
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Ling
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Chris Gray
- Issues from the digests and Wout's list Jon A. Lambert
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list Jon A. Lambert
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list Chris Gray
- Issues from the digests and Wout's list Chris Gray
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list Jeff Kesselman
- ListMail dupes coder@ibm.net
- Threads, IO handling, and Event Queues Nathan Yospe
- Threads, IO handling, and Event Queues Chris Gray
- Threads, IO handling, and Event Queues coder@ibm.net
- Threads, IO handling, and Event Queues Carter T Shock
- Threads, IO handling, and Event Queues Nathan Yospe
- Threads, IO handling, and Event Queues claw@null.net
- Threads, IO handling, and Event Queues coder@ibm.net
- mud grammar (was Just a bit of musing) Carter T Shock
- mud grammar (was Just a bit of musing) Nathan Yospe
- mud grammar (was Just a bit of musing) Chris Gray
- mud grammar (was Just a bit of musing) claw@null.net
- mud grammar (was Just a bit of musing) Chris Gray
- mud grammar (was Just a bit of musing) claw@null.net
- mud grammar (was Just a bit of musing) Chris Gray
- mud grammar Carter T Shock
- mud grammar Nathan Yospe
- mud grammar Alex Oren
- mud grammar Nathan Yospe
- mud grammar Adam Wiggins
- mud grammar Chris Gray
- Just a bit of musing (VRML) Dmitri Kondratiev
- Just a bit of musing (VRML) claw@null.net
- Room coding Nathan Yospe
- Room coding Furball
- command parsing Chris Gray
- command parsing Adam Wiggins
- command parsing claw@null.net
- Room coding S001GMU@nova.wright.edu
- Room coding Chris Gray
- Resets and repops Furball
- Resets and repops claw@null.net
- Resets and repops Jon A. Lambert
- Resets and repops claw@null.net
- Resets and repops Nathan Yospe
- Resets and repops Jon A. Lambert
- Resets and repops Nathan Yospe
- Resets and repops claw@null.net
- Resets and repops Adam Wiggins
- Resets and repops Nathan Yospe
- Resets and repops Adam Wiggins
- Resets and repops Nathan Yospe
- Resets and repops Chris Gray
- Resets and repops Chris Gray
- Resets and repops Adam Wiggins
- Resets and repops Travis Casey
- Resets and repops Chris Gray
- Resets and repops Adam Wiggins
- Resets and repops Shawn Halpenny
- Resets and repops Jeff Kesselman
- Resets and repops Chris Gray
- Resets and repops Nathan Yospe
- Resets and repops Jon A. Lambert
- Resets and repops Nathan Yospe
- Resets and repops claw@null.net
- Resets and repops claw@null.net
- Resets and repops claw@null.net
- Resets and repops claw@null.net
- Resets and repops Nathan Yospe
- Resets and repops Adam Wiggins
- Resets and repops claw@null.net
- Resets and repops Adam Wiggins
- Resets and repops claw@null.net
- Resets and repops Nathan Yospe
- Resets and repops claw@null.net
- Resets and repops Jon A. Lambert
- Resets and repops Furball
- Resets and repops Chris Gray
- Resets and repops Adam Wiggins
- Resets and repops claw@null.net
- Resets and repops Adam Wiggins
- Resets and repops claw@null.net
- Resets and repops Chris Gray
- Resets and repops claw@null.net
- Resets and repops Adam Wiggins
- Resets and repops claw@null.net
- Resets and repops Adam Wiggins
- Resets and repops claw@null.net
- Resets and repops S001GMU@nova.wright.edu
- Resets and repops coder@ibm.net
- Resets and repops S001GMU@nova.wright.edu
- Resets and repops clawrenc@cup.hp.com
- Resets and repops S001GMU@nova.wright.edu
- Resets and repops Chris Gray
- Resets and repops Nathan Yospe
- Resets and repops claw@null.net
- Resets and repops Nathan Yospe
- Resets and repops Adam Wiggins
- Resets and repops Nathan Yospe
- Resets and repops Adam Wiggins
- Resets and repops Nathan Yospe
- Resets and repops Chris Gray
- Resets and repops Nathan Yospe
- Resets and repops Chris Gray
- Resets and repops Adam Wiggins
- Resets and repops Chris Gray
- Resets and repops claw@null.net
- Resets and repops lhulbert@czn.com
- Resets and repops claw@null.net
- Resets and repops Chris Gray
- Resets and repops claw@null.net
- Resets and repops Adam Wiggins
- Resets and repops Chris Gray
- Resets and repops Chris Gray
- Resets and repops claw@null.net
- Resets and repops claw@null.net
- Resets and repops claw@null.net
- mud grammar claw@null.net
- mud grammar Nathan Yospe
- mud grammar claw@null.net
- List software claw@null.net
- List software Nathan Yospe
- List software Chris Gray
- List software claw@null.net
- List software claw@null.net
- I got your message..! MAYA DASWANI
- 3D graphics claw@null.net
- Sorry for the dups (again) coder@ibm.net
- mud grammar Jon A. Lambert
- mud grammar claw@null.net
- mud grammar Nathan Yospe
- mud grammar coder@ibm.net
- mud grammar Nathan Yospe
- mud grammar Chris Gray
- mud grammar claw@null.net
- EVOLUTION response claw@null.net
- EVOLUTION response Jon A. Lambert
- EVOLUTION response claw@null.net
- Garbage Collector Artur 'Revinor' Biesiadowski
- A perspective out of time - the mudreport document Nathan Yospe
- A perspective out of time - the mudreport document claw@null.net
- Old missing posts from old list coder@ibm.net
- Execution Chris Gray
- Mixture Furball
- Resets and repops (a really short post) claw@null.net
- Resets and repops (a really short post) Nathan Yospe
- Resets and repops (a really short post) claw@null.net
- Resets and repops (a really short post) Adam Wiggins
- Resets and repops (a really short post) claw@null.net
- Resets and repops (a really short post) Nathan Yospe
- Resets and repops (a really short post) Nathan Yospe
- Resets and repops (a really short post) <= hah! Chris Gray
- VT100 codes ... Khanone@aol.com
- VT102 codes Adam Wiggins
- VT102 codes Adam Wiggins
- VT102 codes Adam Wiggins
- Dupes coder@ibm.net
- Efficiency Chris Gray
- Event Handling Nathan Yospe
- Event handling Shawn Halpenny
- Event handling Vadim Tkachenko
- Event handling Maddy
- A brief introduction.. ok, you got me: an introduction Greg Munt
- A brief introduction.. ok, you got me: an introduction Adam Wiggins
- A brief introduction.. ok, you got me: an introduction coder@ibm.net
- Greetings. :) Michael Hohensee
- Greetings. :) claw@null.net
- Greetings. :) Nathan Yospe
- Greetings. :) Michael Hohensee
- Greetings. :) coder@ibm.net
- Greetings. :) Nathan Yospe
- Greetings. :) Chris Gray
- Greetings. :) coder@ibm.net
- Greetings. :) Chris Gray
- Greetings. :) Nathan Yospe
- Greetings. :) Jeff Kesselman
- Greetings. :) Chris Gray
- Greetings. :) Greg Munt
- Greetings. :) Jon A. Lambert
- Greetings. :) Nathan Yospe
On Sun, 6 Apr 1997, Chris Gray wrote:
:[Nathan Y asks some questions of Chris L, based on Chris's replies to
:Michael H's questions (or something like that!). I'm going to jump in
:with my replies, which will likely be similar, but different enough,
:from Chris L's.]
:
::This code would be what, interpreted, partial (bytecode) compile, partial
::(bundled pointer) compile, or full (dynaloaded) compiled?
:
:I believe that as much as possible of Chris L's MUD code will execute
:interpreted.
Not from what I remember...
:I don't know the details. My system is similar, but I might
:have more native-code help underneath. Think in terms of LPMud efuncs
:and simul-efuncs (did I get those right?) At some point, everything really
:gets done by native code (efuncs), but is driven at the upper level by
:interpreted funcs. The question then becomes one of what level the
:changeover happens. i.e. what level of support functions are done at the
:native level? For example, I have a fairly complex 'Parse' native code
:function that handles input commands and calls out to interpreted code
:for specific commands. A difference is that I call it from interpreted
:code that is triggered for input lines, whereas I believe LP calls it
:automatically, with no possibility of intervention at that level.
Not sure what you mean by "input lines". Does this mean runtime determined
variables in text form? This actually sounds frighteningly close to my
virtual and real functions/classes. The difference, of course, being that
as much as possible of my code is real, and soft becomes real in a short
order of time.
::What exactly do your states look like, if you don't mind answering? My
::'states', insomuch as I have them, are themselves compound objects. The
::only other approach I am really familiar with is *shudder* Merc style
::"long state_holder" with the "#define A 1; #define B 2; #define C 4;"
::bit container method... and I'm sure you use nothing like that.
:
:No, nothing like that. I think Chris L. defines properties as belonging
:to classes (i.e. each class member will have the property with some
:value), and then inherits from that class to give the property to more
:objects.
It'll be interesting to see his reply.
:Mine is less structured - each 'thing' is just a list of property/
:value pairs. If a given property exists on the thing, then its value is
:returned on a query. If the property doesn't exist, the ancestor chain
:is checked, and if it still isn't found, the database returns a default
:value based on the type of the property (my system is strongly typed).
:So, you do something like:
:
: public male CreateBoolProp()$
: public banana CreateThing(nil)$ /* no ancestors */
: banana@male$ /* yields the default 'false' */
: banana@male := true$
: banana@male$ /* now yields 'true' */
: public age CreateIntProp()$
: banana@age$ /* yields the default 0 */
Interesting. Quite interesting. So CreateBoolProp()$ creates a boolean
property... um... which seems to be applied to every object in existance?
What if you have a property list that goes into the thousands? Erm. Hmm.
Still... an interesting system. I guess I should post up my method of
dealing with properties. For the above, I have... well... OK, near as can
get to what you have...
class gender inherits BoolProperty{
@ functions
bool male(){ return property; }
bool female(){ return !property; }
String sex(){ property ? (return "male";) : (return "female";); }
@ data
bool property;
}
class banana{
gender bananaSex(); // default const while data member exists with same
// name... cannot define as non const.
void setSex(); // toggle gender
@ data
gender bananasex = false;
}
banana.bananasex().male(); // yields false
banana.setSex();
banana.bananasex().male(); // yields true
And the rest requires an explicit modification to the banana class. Of
course, the modification could be made in the Virtual class, which all
virtual objects inherit, or in the hardcoded Physical, Location, Doorway,
or Universal classes... but that requires a recompile. The idea is,
anything fundamental to the entire universe _should_ require a recompile,
in my formula, because otherwise a) it introduces a violation of
encapsulation that can be made by anyone, and b) it usually indicates
improper design, under my paradigm.
::OK, yours bounce too... but after the entire message has been passed, even
::if there is no channel for dealing with the input. I really am surprised
::how many parallels exist here... considering that we are running radically
::different systems, and the supposedly similar systems to my own have no
::parallels whatsoever.
:
:Chris L's system is quite flexible there. Maybe he'll repost some of
:the previous examples (hmm - didn't you already see some?). In mine, I
:can sort of fake it, but its a bit more explicit:
:
: public someTrigger CreateActionProp()$
: public someObject CreateThing(someParent)$
: public proc doAction()void:
: <code to execute>
: corp;
: someObject@someTrigger := doAction$
: inside some code that wants to execute 'someTrigger' on an arbitrary
: object in variable 'theObject':
:
: thing theObject;
: action theAction;
: ...
: theAction := theObject@someTrigger; /* database lookup */
: if theAction ~= nil then /* not the default 'nil' */
: /* this object can respond to the trigger */
: call(theAction, void)();
: else
: /* this object cannot respond to the trigger */
: <some kind of default activity>
: fi;
Interesting. Not sure how I would equate this. I have things like this:
location.SendImpulse(Heat(100), Coordinate(0,3,7,9,2,1));
and
target.SendImpulse(Pressure(80, Surface(1,30)), Coordinate(0,0,0,12,1,3));
::Now, to the crystal tree...
::
::There is a bucket with a sympathetic spell to something atop the tree,
::correct? And the tree can only support so much weight, so adding water to
::the bucket eventually overloads the tree and the tree crashes down. (nice
::liquid problem, that... or fluid, at least... crystal units begin to
::approximate sand) Bubba is a physical object, that exerts mass reaction to
::gravity... in other words, he keeps track of the theoretically static
::value of his mass. He has in his possesion an object that will be asked to
::increase mass by the bucket, thanks to the spell on the bucket. When the
::object agrees to increase mass, this is passed as a dynamic impulse to
::bubba, who passes it in turn to his location... a tree that cares about
::such state changes, and doesn't like them one bit. It collapses. Unless I
::missed something here, this was never a problem with my impulse passing
::method, as the only way for the bucket to increase the sympathetic objects
::mass was by transmitting an impulse to it, and impulses always go merrily
::down the line.
:
:This sounds interesting. Can we see a bit more detail here?
OK, once we have the bucket, a standard, no frills Item, we add a spell to
it. Say the spell is to a particular stone. Say it is a permanent spell,
for simplicity, and that it is in place at startup.
So, first we attatch the spell to the bucket, with a trigger to transmit
weight changes. We have a call to create (or choose) a stone when the
bucket is created.
#ITEMS
> bucket{
N bucket~
// . . . all the other stuff . . .
P MassSpell(mass()) <void massUpdate()>
I stone
}
#PROGRAMS
void bucket:MassSpell(int newMass){
stone.SetState(mass, newMass);
};
From this, there is a series of messages passed, that ultimately reaches
the tree. This last impulse schedules an immediate event for the tree to
fall down.
__ _ __ _ _ , , , ,
/_ / / ) /_ /_) / ) /| /| / /\ First Light of a Nova Dawn
/ / / \ /_ /_) / \ /-|/ |/ /_/ Final Night of a World Gone
Nathan F. Yospe - University of Hawaii Dept of Physics - yospe@hawaii.edu - Greetings. :) clawrenc@cup.hp.com
- Greetings. :) Furball
- Greetings. :) Chris Gray
- Greetings. :) clawrenc@xsvr1.cup.hp.com
- Greetings. :) Shawn Halpenny
- Greetings. :) Jeff Kesselman
- Greetings. :) Shawn Halpenny
- Greetings. :) Jeff Kesselman
- Greetings. :) Shawn Halpenny
- Greetings. :) Jon A. Lambert
- Greetings. :) Jeff Kesselman
- Greetings. :) Shawn Halpenny
- Greetings. :) Jon A. Lambert
- Greetings. :) clawrenc@cup.hp.com
- Greetings. :) Jeff Kesselman