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
On Sat, 22 Mar 1997, Chris Gray wrote:
: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.
I've had situations of both... sending a probe to deliver a message to
Mike the mechanic, for example, is simple... if you happen to know where
Mike's garage is. Of course, there is no guarantee that Mike will be at
work. On the other hand, sending a probe to search the entire galaxy for
Mike... well, you better not expect instant results, and you might have
the probe, going by description alone as it is, making a mistake
(actually, I don't think I would ever allow such a mechanism. Local
searches, yes, but galaxy wide?) On the other hand.. the two are totally
different concepts codewise. Linking to a specific Character, whatever the
type, is simple, if you are familiar with the Character. Linking with an
unknown Character, on the other hand, is a matter of searching through
your storage mechanism, whatever it is. Then again, I've never used a disk
based system. Sleeping threads, and all associated memory, tend to get
swapped out by most flavors of UNIX very quickly. There never seemed much
point, overall, in disk based storage in the face of that. Especially with
such a heavy duty memory manager to worry about... swapping out chunks of
that would be a nightmare, if done by hand.
:[Just scribbles note about this down - added to stack of such.]
:
:Here's a general question for you guys who advise doing everything for
:"real": Do you have evidence that doing this is going to be practical
:in a large-ish MUD in the next few years? 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. ChrisL, what have you observed on this? 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. Do any of you convert DB-refs
:to pointers on the fly when objects are loaded? That would require keeping
:track of where all the pointers are, and also would require conditional
:code of some kind whenever a pointer is followed. In my testing, I've
:found that I can run 50-100 NPC's moving every couple of seconds, on this
:roughly 15 MIP machine. The world complexities we've been talking about
:would seem to require 100's or 1000's of active NPC's. 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?
Well, I've gotten the impression that your system was pretty slow, but...
for myself, I dunno about the others... notice how much effort I put into
making the sucker sleep when not needed. This is not a requirement,
particularly... I'm maybe 90% native code, at a guess, and 100% in
memory... but I like the room to expand, and the scripted (well, semi
scripted... the pointer tabled code segment may grow in time...)
: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). Mine is 0% true in-memory and 100%
:scripting (fairly efficient scripting language, however), so maybe this
:is why I'm slow. Comments?
You mentioned before slow hardware, I think? Though, having seen many LP
drivers, disk and in memory, drag their creeping little feet and consume
mass resources... and they are supposedly bytecode interpreters... well, I
can't see a scripted language doing too well... I'm biased, though. I've
gone through a great deal of trouble trying to construct a highly flexible
native code base.
::Amusing. Could even toss player notes onto a given memory, thus:
::
::> note silke this asshole tried to steal my hat!
::
::And later...
::Silke has arrived from the north.
::> ponder
::> recall Silke
::You seem to remember thinking, 'This asshole tried to steal my hat!'
::> growl
::
::Hmmm. Dang, that could be useful in real life:
::
::A tall man approaches you.
::A tall man says, "Adam! How's it going? Been a long time!"
::> say uhh....
::> recall man
::You think really hard, trying to remember anything you can about the tall man.
::Hmmm, you think his name might be "Phil."
::> ' how's it going phil
::Phil says, "Uh, it's 'Bill'."
::> doh
::> name phil bill
::You will now call him 'Bill'.
:
:This is actually rather telling. This *would* be very useful in real life.
:Politicians have assistants whose job is to provide this information -
:prepping the big-wig on whoever they are going to meet, just before the
:meeting. Such things as tidbits about whatever the big-wig learned on
:previous meetings, what was discussed, etc. For normal folks, however,
:we have to rely on our fallible memories. 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?
*grin* From time to time, I tell myself that, once I finish Physmud++,
with all of its PD design characteristics, flexibility, and text based
language management, not to mention having already cracked the threaded
server/router/world and freeze/unfreeze threads, and hopefully eventually
the disk swapping system (I suspect world structures are gonna undergo a
compression and direct binary dump, with periodic tape backups of the
whole mess. Still working out error protection.) GURU (my graphical
project) should be a breeze when I get back to it.
::Yeah, that's what's cool about a system like this - players, being as
::clever as they are, will come up with tricks along these lines that you never
::thought of when programming it, but still working perfectly within the system
::(because it is all consistant). Not to mention I love concepts which
::are neither good nor bad...they just _are_. What you want to make of
::them is up to you as the player.
:
:I *really* like it when unexpected, but consistent, things happen. Too
:bad that in my simple system, it has only sorta happened once. Sniff!
I've had it happen a few times... not as many as I'd hoped, but then I've
never had Singularity 2 up more than two hours so far.
__ _ __ _ _ , , , ,
/_ / / ) /_ /_) / ) /| /| / /\ First Light of a Nova Dawn
/ / / \ /_ /_) / \ /-|/ |/ /_/ Final Night of a World Gone
Nathan F. Yospe - University of Hawaii Dept of Physics - yospe@hawaii.edu - 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 Nathan Yospe
- 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