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
- Greetings. :) clawrenc@cup.hp.com
- Greetings. :) Furball
- Greetings. :) Chris Gray
- Greetings. :) clawrenc@xsvr1.cup.hp.com
In <199704070037.AAA637170@out2.ibm.net>, on 04/06/97
at 10:32 AM, Nathan Yospe <yospe@hawaii.edu> said:
>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.
Agreed. As you comment later, we're using remarkably similar design
principles for what are on the face of it very different approaches.
>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.)
Precisely. I suspect that once you get down to the sort of threaded
interactive, self-generating event driven systems (and various other
picks of multisyllabic adjectives) that we are talking about, that
they're all going to look pretty much the same.
Its either that, or I've just brainwahsed you all into thinking my
way.
>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.
I've debated on this one and decided not to. Base reasons: My
objects are considerably smaller than the OS'es basic page size (not
dealing with OS'es with variable page size support). There is no
reasonably discernable or predictable pattern or spread to the
distribution of the objects in the working set of any given event, and
it can reasonably be assumed that the general case would have every
object resident on a unique page (ignoring page boundary questions).
Given my multi-threaded approach to event handling (ie lots
simultaneously executing events) the working set for the entire server
at any instant is likely to be large.
Cross all the above together, and you end up with a positive feedback
loop on the total working set of the server. Its actively unstable.
The native tendency is going to be for the server to blow the working
set of pages out to Hades and gone.
I just don't wnat to be there to see it page thrash.
Sooooooo, I do my own DB manipulation and return references instead of
copies everywhere I can (loosely I return a reference which the first
write turns into a copy) to try and minimise the in-memory working set
sIze. The cache sitting on top of that of course works the other way,
keeping the working set fairly large, but that at least can be tuned
without affecting the physical processes of the server.
>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...
Ahh. If you look at my implementation of spoof and watchers (they
each create transient objects), plus the free user programming side,
I've got the worst of both worlds:
High frequency creation and deletion of objects (raising recycling
Q's).
Actively fluid inheritance tree.
>: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?
Bytecoded with a lot of native routines (a lot more than ColdC).
>: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?
What are you defining as a "state"? The external state of an object?
An object's concept of its internal state? That thing which if
changed would trigger watcher?
>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.
Ahh, I think I get what you mean. You mean some sort of enumerated or
flagged "THIS IS A XXX" or "THIS HAS A XXX QUALITY" type indicator. I
don't have any of that at a server level. I have objects. Those
objects have methods and attribues. Methods are code written in the
internal language. Attributes are type-less values stored
persistantly in the objects (ie written out to the DB). If the object
allows (public/private/accessor/etc), attributes can be queried or set
externally, giving an impression of a "state" which can be reacted to
by a watcher.
>: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?
No. I have not been able to think of a good rule for such
invalidations other than the fact that the object that the method is
to be called on doesn't exist any more. I don't even check for that
-- I just let the event finally ripen, attempt execution, and throw
the exception.
Note: The fact that the original caller does not exist any more is not
necessarily a reason to cancelt the event.
>: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.
I don't have a channel concept like that per se. The messages are
loosely of the form:
AuthorityID, CallerID, ObjectID, MethodName, Arguments...
And its just up the the recipient object to do with it or not as it
wishes.
>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.
The CT is not a problem for me either if I code it as above (which is
BTW the "natural way to do it under my system). The problem enters in
with free user programming. The problem is that the programmer of the
spell on the bucket DOES NOT have to code it so that the balloon is
informed everytime the weight of the bucket changes. He could every
easily (and it is almost easier to do it this way, especially for a
newbie programmer), insead program it so that the bucket never
messages the balloon unprompted, and instead the balloon only updates
it weight concept when it is queried externally.
As such, Bubba with the balloon weighs X units. Bubba stands on the
CT. 60 tonnes of neutronium are added to the (remarkably tough)
bucket, and Lo! unless something causes Bubba's (and thus the
balloon's) weight to be queried, Bubba continues to stand on the CT
undisturbed. Now Bubba drops a very heavy anvil, thinking that this
will reduce his weight and allow him to climb onto a thin branch.
Instead, the CT reacts to the state change by querying Bubba's weight,
which causes Bubba to query the balloon for its weight, and suddenly
discover that he should be a red smear on the forest floor below.
My problem is that I can't prevent twit programmers from coding this
sort of junk, I can't think of a decent reason to allow them to, and I
do want a server that as much as possible enforces building an
internally logically consistant world.
--
J C Lawrence Internet: claw@null.net
(Contractor) Internet: coder@ibm.net
---------------(*) Internet: clawrenc@cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...
- 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