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
On Sun, 6 Apr 1997 coder@ibm.net wrote:
:On 01/04/97 at 09:47 AM, Michael Hohensee <michael@sparta.mainstream.net>
:said: >On Mon, 31 Mar 1997 claw@null.net wrote:
:>> Hehn. I actually make no distinction among players, mobiles, rooms,
:>> objects, utility objects, etc. There are just no unique object types.
:>> They're all the same to the server.
:>
:>Doesn't that waste memory?
:
:No really. I don't run in memory. I run off a heavily cached disk-based
:DB, so there is no in-memory class structure.
I think we're hitting upon a fundamental philosophical difference between
the server approach and the codebase approach. I've noticed that my
internal language is resulting in my system, in some respects, drifting
more and more toward what you describe, to the point that, if I yanked
every existing object, I might have a crude and clunky version of your
server (with a seriously different sort of threading and event scoping...
the event thread imbedment in layered containment is a bit lower level
than my descriptions, but the descriptions reflect my use of them, not
their potential application.) Nevertheless, I decided to, rather than deal
with writing a caching/disk swapping system, rely instead on the OS
swapping, and on discrete object referencing. This mainly follows the
expectation that, while there is potential for the creation of new
objects, they will not actually _be_ created in large quantities, and all
new objects will be translated into hardcoded versions on the next
recompile and reboot, so no more than a week (they take the system down
once a week) will pass in which these softcoded objects might exist. The
softcoded objects are considerably more reluctant to swap cleanly under
the system swapping.
:Part of the key here is that my server actually knows nothing about the
:game it is representing, or in fact anything about any games at all.
:Truth to tell, my server has no concept that it has anything to do with
:games at all (that was one of the design criteria). What the server does
:know about is its databse, how to submit queries to that database, and
:that's pretty well all it knows. Everything else, all the game stuff, the
:command parsing etc happens as code written inside of database records.
This code would be what, interpreted, partial (bytecode) compile, partial
(bundled pointer) compile, or full (dynaloaded) compiled?
:This is probably better understood from the inside oot, rather than trying
:to look at the server side:
: Everything is an object.
: Objects are defined in a database.
: Objects have Unique IDs.
: Objects may contain methods, attributes and verb templates.
: Objects may inherit from other objects (multiple inheritance).
: Methods may call other methods during their execution.
: Everything that happens is part of an event.
: An event is a grouped set of state-changes which occurs to the DB
: atomically as of a known time.
: An event may log future events. (ie A method, should its event
: succeed, may log future events)
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.
:Essentially what happens from there is that the server determines that
:there is an event to be executed, and calls a specified method on a
:specified object with particular arguments. That method then executes
:from there, calling other methods on other objects etc as needed. At some
:point the event terminates, all the changes to the DB are commited
:atomically, and the server goes back to doing nothing.
Can you kill an event if it is invalidated prior to ripening?
:Internally the DB, pr at least object ineractions, may be viewed as a
:message passing system. Methods send messages to other methods, which in
:turn acknowledge/respond with messages (possibly after calling other
:methods).
Hmmm. I wonder... this sounds an awful lot like my impulse system, except
that impulses have to travel through existing channels in the target
object, or they bounce.
: An object consists of an inheritance tree (multiple inheritance),
: methods (code), attributes (values), and verb templates.
: Verb templates conditionally match and auto-parse user commands,
: matching them to methods on the defining object (see ColdX).
: Any object's method may call any other object's method, whether or
: not it knows that method exists or is defined on the target
: object.
: Such a call is actually a message, and may be handled in any manner
: by the receiving object. As such, it is up to the receiving object
: to respond appropriately to the message with its own message back to
: the caller.
: In this manner the receiving object can reply that it doesn't support
: the method called for, does support it but its internal security
: processes prevent it being called, a standard return value from the
: call, etc.
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.
:>I did that for a while, but I couldn't see
:>why a jar needed to have a sex value...
:
:The difference is that I don't require anything to have a sex value. If
:someone wants to insert one at the appropriate place in the inheritance
:tree, then a bunch of objects will suddenly gain one (can be done at
:runtime). You could ask a jar on my system for its sex, and it could well
:respond with a stated value, a "Huhh what?", raise an exception, or do
:anything number of things. The real point is that I don't prevent
:anything from _asking_ the sex of anything else.
I suppose I do, in a sense... you cannot ask the sex of something
without that attribute object in hardcode, and the dead code produced by
attempting to do so in softcode is simply trimmed by the pip2C++
translater.
:>I treat liquids as independant objects. I've got an update pulse
:>(modeled after dikumud pulses) that will have the liquid check to see if
:>it is in a watertight container. If it isn't, some of it "leaks" out.
:>The liquid object has an "amount" variable, and this is decreased when
:>some leaves the container. I've also got one function for moving things
:>around, and it checks to see if the liquid has all been spilled (move
:>whole object to outer container) and checks to see if there is a liquid
:>of similar type in the outer container (sum the amount variables, and
:>recycle one object.)
:
:Ahh, minus the update pulses (mine is a totally event driven server) I
:pretty much do the same here with my mana flows (mana flows about the land
:much like a liquid (actually more like a gas)). An area I'd really like
:to crack is liquid flow such that free liquids would puddle, flow in
:streams, form rivers etc.
I think I might be able to help you here. Give me a while to strip out all
of my prejudices on the basis of my code, and I'll get back to you with
how I do it, generically. Right now, fluidity is inherent in all
materials, in my code, in several forms, and I have state changes for
several materials. In the context of my code, an object with physical
attributes has a material composition. If it is made of multiple
significantly diverse materials, the object is composed of layered
component objects. A material responds to external states (static
impulses) by recalibrating state change events every time external
conditions change (this is also the key to my solution of the crystaline
tree... I'll explain later, as that tree is a perfect example of this) A
liquid, in response to gravity, a static impulse, schedules an incomplete
interuptable event for a later date in which it has traveled downhill,
possibly also fusing (I allow several degrees of chemical and non
chemical fusion of substances... water on dust becomes mud, dirt on
pressure becomes dust, water motion creates pressure on dirt, etc), but
this state change is marked on scheduling with an alert. Any reference to
the water, or the traversed region, in the time of traversion, generates
an instant event evaluating current state, and displays that. The only
problem: if there is a static impulse condition on, say, something that
might be worn away by the water, the calculation of water movement will
note this (or, should something come to exist within the region while the
water flows, this will create an interupt/immediate event recalibration)
and the event that places the water in the critical position and wreaks
havok will be scheduled instead of the normal later date position of the
water. This allows such things as redirecting streams to use water flow to
undermine an enemy fortification. Yes, creating water flow does involve a
source/rate and destination... rate handled for you on destination. So...
that fountain of midgaard would probably, if not designed with an outflow
or autostop, result in the mud puddle of midgaard. Especially with the
pressure impulses created by all the feet passing by on the hard dirt. (I
assume dust due to pressure up to a certain equilibrium, then the
reverse... but mud keeps the equilibrium from occuring... so the mud would
keep getting deeper... and the nearby stores or whatever they were would
start to cake with it after a time.)
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.
__ _ __ _ _ , , , ,
/_ / / ) /_ /_) / ) /| /| / /\ 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. :) 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
- 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. :) Nathan Yospe
- Greetings. :) Jeff Kesselman