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
On 22/03/97 at 12:20 PM, cg@ami-cg.GraySage.Edmonton.AB.CA (Chris
Gray) said: >But isn't it a bit unrealistic to be able to do that? I
was thinking >about this stuff this morning, and it occurs to me that
one of the >things I would want to do is to be careful about
identification. In >my system all database entries have a unique ID. I
would use that as >a handle for things. You can put a name for it into
your private >symbol table. Then, you can refer to it, unambiguously,
by that name. >So, the 'scry' for me, would end up not using 'elven
archwizard', but >some made-up name by which this player refers to the
NPC. Such a name >can only be made when you have some other
unambiguous way of >referencing the archwizard, such as by being in
the same room as him >and doing the naming. So, having this link to
the elven archwizard >can be considered enough to keep that NPC
active. If you don't have >some kind of unambiguous reference like
that, then the above command >seems to me to require some sort of scan
of the entire world, in >order to find something that meets that
description. Now, you may >want to allow that, but for most uses, I
think an unambiguous >reference would be preferable.
There's a problem with this view: Some names are unique (or at least
very limited) due to their adjectival tags, not their nouns. The
"elven archwizard" can be such a case, especially if the game only
allows one to exist at any moment.
Consider the scenario I posted a while ago concerning the Orcs, the
breeder Orcs, the variant production of breeder/worker/fighter/noble
Orcs by the breeders dependant on population density, mortality rate,
and invasion status, and more importantly, the competition by the
noble Orcs to become King Orc (with the guarantee that there is only
ever one KO).
Thusly: The "King Orc" as a tag always uniquely identifies a single
Orc, or is unable to indentify any Orc (ie the KO is recently killed
and the nobles are fighting for kingship). Given even a loosely
educated player, they will know of the existance of a "King Orc", even
if they have never met the chap. As such, doing a "scry king orc" or
similar becomes a reasonable command. They know he exists, they don't
know where, but they hope they can locate him on the basis of his
uniqueness.
The problem this presents to a MUD server is whether or not you
maintain a global namespace for such tags (especially such fluid
tags), and if not, how you proceed with the search. (What if the KO
is located in a hidden/unknowable location?)
>I don't have a
>gut feel for the speed of a 100% in-memory MUD, since mine has a disk
>based DB with lots of caching, but what I've observed is that DB
>access is the big bottleneck.
Ergo: You need a bigger cache.
>ChrisL, what have you observed on this?
Cache size is critical. My attempt in general is to make the cache
large enough that I can keep the entire working set of the MUD at any
instant in memory -- where working set is defined as comprised of any
object which has been accessed within the last 20 seconds or so (it
gets better when you can start hitting multiple minutes).
Yup, its memory expensive -- but its cheaper than everything in-RAM.
Yup, it looks like I will be going back to a three level cache.
>If a system is 100% in-memory, then links from one entity to another
>can be just pointers, but with a disk-based system that's harder.
For me every object has a guaranteed unique ObjectID (guaranteed for
the entire life of that database). As such inter-object references
merely become ObjectID's. Reference speed is of course slower.
This is one of the reasons there was so much interest on the list last
year in persistant stores, and specifically Texas with its Pointer
Swizzling, and Object Store (commercial, rather similar in principle
to Texas). It is an area I intend to revisit. I still have a very
ugly nagging feeling that all the work I've been putting into the DB
layer lately (adding native transactions and rollbacks) will be wasted
once I find or write a decent persistant store and see how much better
a solution that is.
>Do
>any of you convert DB-refs to pointers on the fly when objects are
>loaded?
Not quite. I have a layer that sits immediately over the DB cache and
handles all the tracking of the requested objects, interested party
lists etc. That layer attempts to short-circuit references between
objects which are already in cache, but frankly, the current short
circuit is more expensive than the lookup would be.
>The world complexities we've been talking about would seem to require
>100's or 1000's of active NPC's.
My original target was single digit millions of active objects, where
an active object is defined as any object which has an ongoing event
stream. My current revised view is hundreds of thousands of active
objects on a < US$3,000 machine.
Note: I haven't even attempted anything over a thousand or so (almost
all duplicate) on my already extremely over committed machine.
>Also, the code being discussed is a
>lot more complex than what I'm currently running. Is my system just
>hopelessly slow, or is there something wrong with my assumptions
>here?
>I guess I can barely imaging this kind of thing working with a 100%
>in-memory system, running 100% native code (i.e. very little
>scripting or whatever you want to call it).
That's exactly what MOO and almost all Tiny-* MUDs do, and some of
them have databases measuring up in the scores of Megs. (Have a look
at the last LambdaMOO dump some time)
>Mine is 0% true in-memory
>and 100% scripting (fairly efficient scripting language, however), so
>maybe this is why I'm slow. Comments?
Without running a profiler over the code, I can't really comment.
However I would immediately suspect your cache management along with
any blocking you do on disk IO.
>:Amusing. Could even toss player notes onto a given memory, thus: :
>:> note silke this asshole tried to steal my hat!
...
>...Is it
>realistic to provide this kind of aid in the game? Handy, yes. This
>is one of the reasons why I would like to go to a 100% 3D graphic
>game. You can then avoid a lot of the stuff that is needed in text
>games and simply leave things like noticing, remembering, etc. up to
>the human player. You don't have to come up with text descriptions
>dependent on the local conditions -
>you just display the world according to those local conditions, and
>the visual acuity of the player if you want, and let the player sort
>it all out. Much more realistic. Is it playable, though?
The probme here is ensuring that all your character's graphics are
reasonably unique. Most 3D games build bodies from stock libraries
(here a leg, there a leg, throw in an arm or two, a torso, one of
three colours of hair etc) which leaves the resultant bodies all
looking very much the same.
cf Meridian59 and its name tag haloes for all the characters. Its a
*LOT* cheaper than having 500 unique bodies.
>I *really* like it when unexpected, but consistent, things happen. Too
>bad that in my simple system, it has only sorta happened once. Sniff!
Yeah, but this is a funny world we've got here, where ideas and
potential often count for more than what's actually done with them.
Set up a system where your players *can* do some neat things, and lord
knows they may well just stick to endlessly killing fidos. Set up the
system so tht nothing is flexible, and some user will come along and
figure out how to program it...
Them's the breaks.
--
J C Lawrence Internet: claw@null.net
----------(*) Internet: coder@ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith... - 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
- 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