October 1998
- Storytelling vs. Simulationist (Was Room descriptions) ApplePiMan@aol.com
- Storytelling vs. Simulationist (Was Room descriptions) Brandon J. Rickman
- Storytelling vs. Simulationist (Was Room descriptions) Adam Wiggins
- Storytelling vs. Simulationist (Was Room descriptions) ApplePiMan@aol.com
- Storytelling vs. Simulationist (Was Room descriptions) Adam Wiggins
- Storytelling vs. Simulationist (Was Room descriptions) ApplePiMan@aol.com
- Storytelling vs. Simulationist (Was Room descriptions) ApplePiMan@aol.com
- Storytelling vs. Simulationist (Was Room descriptions) Caliban Tiresias Darklock
- Storytelling vs. Simulationist (Was Room descriptions) Peck, Matthew x96724c1
- Storytelling vs. Simulationist (Was Room descriptions) ApplePiMan@aol.com
- Storytelling vs. Simulationist (Was Room descriptions) Peck, Matthew x96724c1
- Storytelling vs. Simulationist (Was Room descriptions) ApplePiMan@aol.com
- Storytelling vs. Simulationist (Was Room descriptions) Caliban Tiresias Darklock
- Storytelling vs. Simulationist (Was Room descriptions) Caliban Tiresias Darklock
- Storytelling vs. Simulationist (Was Room de scriptions) Koster, Raph
- Storytelling vs. Simulationist (Was Room descriptions) Adam Wiggins
- Storytelling vs. Simulationist (Was Room descriptions) Travis S. Casey
- Storytelling vs. Simulationist (Was Roomdescriptions) ApplePiMan@aol.com
- Storytelling vs. Simulationist (Was Room de scriptions) Koster, Raph
- simulation vs. storytelling is a fallacious distinction James Wilson
- simulation vs. storytelling is a fallacious distinction ApplePiMan@aol.com
- simulation vs. storytelling is a fallacious distinction James Wilson
- simulation vs. storytelling is a fallacious distinction ApplePiMan@aol.com
- [DESIGN] To kill or not to kill? (non-violent conflict) The Wildman
- [DESIGN] To kill or not to kill? (non-violent conflict) Richard Woolcock
- [DESIGN] To kill or not to kill? (non-violent conflict) Marian Griffith
- [DESIGN] To kill or not to kill? (non-violent conflict) The Wildman
- [DESIGN] To kill or not to kill? (non-violent conflict) Robert Woods
- [DESIGN] To kill or not to kill? (non-violent conflict) Marc Hernandez
- Quest engines Koster, Raph
- Quest engines ApplePiMan@aol.com
- Quest engines Michael.Willey@abnamro.com
- Quest engines Hal Black
- [Off-Topic] Patents (Was Storytelling vs. Simulationist) ApplePiMan@aol.com
- Psychopaths Ola Fosheim Grøstad
- Psychopaths Koster, Raph
- Storytelling patents (Storytelling vs. Simulationist) Ola Fosheim Grøstad
- [DESIGN] To kill or not to kill? Michael.Willey@abnamro.com
- [DESIGN] To kill or not to kill? The Wildman
- [DESIGN] To kill or not to kill? Michael.Willey@abnamro.com
- [DESIGN] To kill or not to kill? The Wildman
- [DESIGN] To kill or not to kill? Michael.Willey@abnamro.com
- [DESIGN] To kill or not to kill? The Wildman
- Spoofing (Psychopaths) Ola Fosheim Grøstad
- Spoofing (Psychopaths) Koster, Raph
- Spoofing (Psychopaths) Ola Fosheim Grøstad
- Spoofing (Psychopaths) Richard Bartle
- Spoofing (Psychopaths) Richard Bartle
- Spoofing (Psychopaths) Ola Fosheim Grøstad
- [DESIGN] To kill or not to kill? Michael.Willey@abnamro.com
- [DESIGN] To kill or not to kill? The Wildman
- Terrain/Landmass & GIF/BMP quzah [sotfhome]
- Terrain/Landmass & GIF/BMP Adam Wiggins
- Terrain/Landmass & GIF/BMP Chris Gray
- Terrain/Landmass & GIF/BMP quzah [sotfhome]
- Terrain/Landmass & GIF/BMP Hal Black
- Terrain/Landmass & GIF/BMP John Bertoglio
- Terrain/Landmass & GIF/BMP Petri Virkkula
- Terrain/Landmass & GIF/BMP Caliban Tiresias Darklock
- Terrain/Landmass & GIF/BMP Niklas Elmqvist
- Terrain/Landmass & GIF/BMP quzah [sotfhome]
- Terrain/Landmass & GIF/BMP Marc Hernandez
- Terrain/Landmass & GIF/BMP quzah [sotfhome]
- Terrain/Landmass & GIF/BMP Chris Gray
- Terrain/Landmass & GIF/BMP quzah [sotfhome]
- Terrain/Landmass & GIF/BMP Dominic J. Eidson
- Current Projects Alex Stewart
- Current Projects Caliban Tiresias Darklock
- Current Projects Robert Woods
- Current Projects James Wilson
- Current Projects Peck, Matthew x96724c1
- Current Projects Robert Woods
- Current Projects T. Alexander Popiel
- Current Projects Travis S. Casey
- Current Projects Joel Kelso
- Current Projects The Arrow
- Current Projects Ryan Prince
- Current Projects Wilburn, E.J.
- Current Projects Michael.Willey@abnamro.com
- Current Projects David Bennett
- Current Projects chris@realm.zfn.uni-bremen.de
- Current Projects Andrew Wilson
- Current Projects Holly Sommer
- Current Projects Scatter
- Current Projects Michael.Willey@abnamro.com
- Current Projects Niklas Elmqvist
- Red Black Tree ? Valerio Santinelli
- Red Black Tree ? T. Alexander Popiel
- Red Black Tree ? Caliban Tiresias Darklock
- Red Black Tree ? T. Alexander Popiel
- Red Black Tree ? Caliban Tiresias Darklock
- Red Black Tree ? Ben Greear
- MUVE vs. MUD [was Current Projects] Alex Stewart
- Laws of Online World Design Koster, Raph
- Laws of Online World Design Jon A. Lambert
- Laws of Online World Design Ling
- Laws of Online World Design Adam Wiggins
- Laws of Online World Design Michael.Willey@abnamro.com
- Laws of Online World Design J C Lawrence
- Laws of Online World Design ApplePiMan@aol.com
- Laws of Online World Design J C Lawrence
- Laws of Online World Design ApplePiMan@aol.com
- Laws of Online World Design manta@pobox.com
- Laws of Online World Design J C Lawrence
- Laws of Online World Design James Wilson
- Laws of Online World Design J C Lawrence
- Laws of Online World Design ApplePiMan@aol.com
- Laws of Online World Design J C Lawrence
- Laws of Online World Design ApplePiMan@aol.com
- Laws of Online World Design Koster, Raph
- Laws of Online World Design Ola Fosheim Grøstad
- Laws of Online World Design Koster, Raph
- Laws of Online World Design J C Lawrence
- Laws of Online World Design Ola Fosheim Grøstad
- Laws of Online World Design Ola Fosheim Grøstad
- Laws of Online World Design J C Lawrence
- Laws of Online World Design Darrin Hyrup
- Laws of Online World Design Koster, Raph
- Laws of Online World Design Darrin Hyrup
- Laws of Online World Design J C Lawrence
- Laws of Online World Design Hans-Henrik Staerfeldt
- Laws of Online World Design Koster, Raph
- Laws of Online World Design Richard Bartle
- Laws of Online World Design Richard Bartle
- Laws of Online World Design Vadim Tkachenko
- MUVE vs. MUD [was Current Projects] Richard Bartle
- META: Review of FAQ's Bio Section Ling
- META: Review of FAQ's Bio Section Chris Gray
- META: Review of FAQ's Bio Section Benjamin D. Wiechel
- META: Review of FAQ's Bio Section Ling
- META: Review of FAQ's Bio Section J C Lawrence
- META: Review of FAQ's Bio Section Adam Wiggins
- META: Review of FAQ's Bio Section Michael.Willey@abnamro.com
- Advance book review Koster, Raph
- (CDMag) Sosaria Cracked: Why OSI's great social experiment is doomed J C Lawrence
- Ethics & Identity Scatter
- DNS adventure J C Lawrence
- DNS adventure Chris Gray
- DNS adventure Caliban Tiresias Darklock
- DNS adventure Adam J. Thornton
- DNS adventure Vadim Tkachenko
- DNS adventure J C Lawrence
- Trusting the Client (Laws of Online World Design) mark@erdos.Stanford.EDU
- Trusting the Client (Laws of Online World Design) Ola Fosheim Grøstad
- Trusting the Client (Laws of Online World Design) J C Lawrence
- Trusting the Client (Laws of Online World Design) Hal Black
- Trusting the Client (Laws of Online World D esign) Koster, Raph
- Trusting the Client (Laws of Online World Design) Jon Leonard
- Trusting the Client (Laws of Online World Design) J C Lawrence
- Trusting the Client (Laws of Online World Design) Adam J. Thornton
- Trusting the Client (Laws of Online World Design) Marc Hernandez
- Trusting the Client (Laws of Online World D esign) Wilburn, E.J.
- Trusting the Client (Laws of Online World D esign) Jon Leonard
- Trusting the Client (Laws of Online World D esign) Vadim Tkachenko
- Trusting the Client (Laws of Online World D esign) Steve Sparks
- Trusting the Client (Laws of Online World Design) Jon Leonard
- Trusting the Client (Laws of Online World Design) Steve Sparks
- Trusting the Client (Laws of Online World Design) Jon Leonard
- Trusting the Client (Laws of Online World Design) Steve Sparks
- Trusting the Client (Laws of Online World D esign) Vadim Tkachenko
- Trusting the Client (Laws of Online World D esign) Steve Sparks
- Trusting the Client (Laws of Online World D esign) Vadim Tkachenko
- Trusting the Client (Laws of Online World D esign) Steve Sparks
- A Query Regarding Economies in a Text Environment Brandon A Downey
- A Query Regarding Economies in a Text Environment J C Lawrence
- A Query Regarding Economies in a Text Environme nt Koster, Raph
- Trusting the Client (Laws of Online World Design) Chris Gray
- Trusting the Client (Laws of Online World Design) J C Lawrence
- Trusting the Client (Laws of Online World Design) Jon Leonard
- Trusting the Client (Laws of Online World D esign) Wilburn, E.J.
- Trusting the Client (Laws of Online World D esign) J C Lawrence
- [Tech] socket slowdown solved Chris Gray
- [Tech] socket slowdown solved J C Lawrence
- ADMIN: unsubscriptions J C Lawrence
- Trusting the Client (Laws of Online World Design) Chris Gray
- Network float format (RFC 1014) J C Lawrence
- Bruce Sterling on Virtual Community goals J C Lawrence
- Bruce Sterling on Virtual Community goals Koster, Raph
- Bruce Sterling on Virtual Community goals Jon Leonard
- Bruce Sterling on Virtual Community goals J C Lawrence
- Bruce Sterling on Virtual Community goals Jon Leonard
- Bruce Sterling on Virtual Community goals Elis Pomales
- Bruce Sterling on Virtual Community goals Darrin Hyrup
- Bruce Sterling on Virtual Community goals Bruce Mitchener, Jr.
- Bruce Sterling on Virtual Community goals Darrin Hyrup
- Bruce Sterling on Virtual Community goals Niklas Elmqvist
- Bruce Sterling on Virtual Community goals J C Lawrence
- Bruce Sterling on Virtual Community goals Wilburn, E.J.
- Bruce Sterling on Virtual Community goals J C Lawrence
- Bruce Sterling on Virtual Community goals Chris Gray
- Bruce Sterling on Virtual Community goals Jon Leonard
- Bruce Sterling on Virtual Community goals Jon A. Lambert
- Bruce Sterling on Virtual Community goals Jon Leonard
- Bruce Sterling on Virtual Community goals Niklas Elmqvist
- Bruce Sterling on Virtual Community goals Jon Leonard
- Bruce Sterling on Virtual Community goals Jon A. Lambert
- Bruce Sterling on Virtual Community goals Joel Kelso
- Bruce Sterling on Virtual Community goals Marc Hernandez
- Bruce Sterling on Virtual Community goals Bruce Mitchener, Jr.
- Bruce Sterling on Virtual Community goals Adam J. Thornton
- Bruce Sterling on Virtual Community goals J C Lawrence
- Bruce Sterling on Virtual Community goals Jon A. Lambert
- Bruce Sterling on Virtual Community goals Jon A. Lambert
- Bruce Sterling on Virtual Community goals Marc Hernandez
- Bruce Sterling on Virtual Community goals Jon A. Lambert
- Bruce Sterling on Virtual Community goals Chris Gray
- Bruce Sterling on Virtual Community goals J C Lawrence
- Bruce Sterling on Virtual Community goals Jon Leonard
- Bruce Sterling on Virtual Community goals J C Lawrence
- Bruce Sterling on Virtual Community goals Jon Leonard
- Bruce Sterling on Virtual Community goals ApplePiMan@aol.com
- Bruce Sterling on Virtual Community goals J C Lawrence
- Bruce Sterling on Virtual Community goals Chris Gray
- Bruce Sterling on Virtual Community goals Jon Leonard
- Bruce Sterling on Virtual Community goals Chris Gray
- Bruce Sterling on Virtual Community goals Jon A. Lambert
- Bruce Sterling on Virtual Community goals Chris Gray
- Bruce Sterling on Virtual Community goals Chris Gray
- Bruce Sterling on Virtual Community goals Jon A. Lambert
- Bruce Sterling on Virtual Community goals Chris Gray
- Bruce Sterling on Virtual Community goals Chris Gray
- Bruce Sterling on Virtual Community goals Bruce Mitchener, Jr.
- Bruce Sterling on Virtual Community goals Adam J. Thornton
- Bruce Sterling on Virtual Community goals Chris Gray
- Bruce Sterling on Virtual Community goals Jon A. Lambert
- Bruce Sterling on Virtual Community goals Chris Gray
- Bruce Sterling on Virtual Community goals Chris Gray
- Bruce Sterling on Virtual Community goals Chris Gray
- OT: TTYQuake Niklas Elmqvist
- OT: TTYQuake Adam Wiggins
- OT: TTYQuake Adam J. Thornton
- Trusting the Client (Laws of Online World Matthew R. Sheahan
- Trusting the Client (Laws of Online World Vadim Tkachenko
- Trusting the Client (Laws of Online World J C Lawrence
- FW: Book? Koster, Raph
- GameStorm Matthew R. Sheahan
- GameStorm J C Lawrence
- Trusting the Client (Laws of Online World Jon A. Lambert
- Trusting the Client (Laws of Online World D esign) Koster, Raph
- Trusting the Client (Laws of Online World D esign) quzah [sotfhome]
- Trusting the Client (Laws of Online World D esign) Steve Sparks
- Trusting the Client (Laws of Online World D esign) Koster, Raph
- Trusting the Client (Laws of Online World D esign) Vadim Tkachenko
- Trusting the Client (Laws of Online World D esign) Koster, Raph
- Trusting the Client (Laws of Online World D esign) J C Lawrence
- Lengthy Palace study Koster, Raph
- Hacks/Diablo/etc (was: Trusting the quzah [sotfhome]
- PDMud (was Bruce Sterling on Virtual Community goals) Niklas Elmqvist
- PDMud (was Bruce Sterling on Virtual Community goals) Darrin Hyrup
- PDMud (was Bruce Sterling on Virtual Community goals) Adam J. Thornton
- PDMud (was Bruce Sterling on Virtual Community goals) Hal Black
- PDMud (was Bruce Sterling on Virtual Community goals) Ola Fosheim Grøstad
- PDMud (was Bruce Sterling on Virtual Community goals) ApplePiMan@aol.com
- PDMud (was Bruce Sterling on Virtual Community goals) Niklas Elmqvist
- Recursive look Ling
- Recursive look Holly Sommer
- Recursive look David Bennett
- Recursive look J C Lawrence
- Recursive look Marc Hernandez
- Recursive look Bruce Mitchener, Jr.
- Recursive look Michael.Willey@abnamro.com
- Recursive look The Wildman
- Recursive look Adam Wiggins
- Recursive look Koster, Raph
- Recursive look Ling
- Recursive look Adam Wiggins
- Recursive look Marian Griffith
- Recursive look Brandon J. Rickman
- Recursive look Marian Griffith
- Recursive look Brandon J. Rickman
- Recursive look Marian Griffith
- Recursive look Ola Fosheim Grøstad
- Recursive look Nathan F Yospe
- Recursive look Darrin Hyrup
- Recursive look Ola Fosheim Grøstad
- Recursive look Jon A. Lambert
- Recursive look Matthew R. Sheahan
- Recursive look Nathan F Yospe
- Recursive look Michael.Willey@abnamro.com
- Recursive look Chris Gray
- Recursive look Chris Gray
- evil - good realism Vladimir Prelovac
- evil - good realism S. Patrick Gallaty
- evil - good realism Adam Wiggins
- evil - good realism Wilburn, E.J.
- evil - good realism quzah [sotfhome]
- evil - good realism Jon A. Lambert
- evil - good realism quzah [sotfhome]
- evil - good realism Orion Henry
- evil - good realism Vadim Tkachenko
- evil - good realism J C Lawrence
- evil - good realism Chris Gray
- evil - good realism Brandon A Downey
- evil - good realism quzah [sotfhome]
- evil - good realism Vladimir Prelovac
- evil - good realism Vadim Tkachenko
- PDMud (was Bruce Sterling on Virtual Community goals) Chris Gray
- PDMud (was Bruce Sterling on Virtual Community goals) Niklas Elmqvist
- PDMud (was Bruce Sterling on Virtual Community goals) Chris Gray
- PDMud (was Bruce Sterling on Virtual Community goals) Hal Black
- PDMud (was Bruce Sterling on Virtual Community goals) Felix A. Croes
- PDMud (was Bruce Sterling on Virtual Community goals) Darrin Hyrup
- PDMud thread summary Jon Leonard
- PDMud thread summary Chris Gray
- PDMud thread summary Darrin Hyrup
- PDMud thread summary J C Lawrence
- PDMud thread summary Hal Black
- PDMud thread summary Vadim Tkachenko
- PDMud thread summary Darrin Hyrup
- PDMud thread summary J C Lawrence
- PDMud thread summary Niklas Elmqvist
- PDMud thread summary Darrin Hyrup
- PDMud thread summary Niklas Elmqvist
- PDMud thread summary Adam J. Thornton
- PDMud thread summary Jon A. Lambert
- PDMud thread summary Jon A. Lambert
- PDMud thread summary ApplePiMan@aol.com
- PDMud thread summary Niklas Elmqvist
- PDMud thread summary J C Lawrence
- PDMud thread summary ApplePiMan@aol.com
- PDMud thread summary Jo Dillon
- PDMud thread summary The Arrow
- PDMud thread summary Niklas Elmqvist
- PDMud thread summary Chris Gray
- PDMud thread summary ApplePiMan@aol.com
- PDMud thread summary Darrin Hyrup
- PDMud thread summary Chris Gray
- PDMud thread summary Jon Leonard
- PDMud thread summary ApplePiMan@aol.com
- PDMud thread summary Steve Sparks
- PDMud thread summary Jo Dillon
- PDMud thread summary Adam J. Thornton
- PDMud thread summary Jon Leonard
- PDMud thread summary Jo Dillon
- PDMud thread summary Jon Leonard
- PDMud thread summary Vadim Tkachenko
- PDMud thread summary Jo Dillon
- PDMud thread summary Niklas Elmqvist
- PDMud thread summary Vadim Tkachenko
- PDMud thread summary Darrin Hyrup
- PDMud thread summary Niklas Elmqvist
- PDMud thread summary Chris Gray
- PDMud thread summary Jon A. Lambert
- PDMud thread summary Adam J. Thornton
- PDMud thread summary Chris Gray
- PDMud thread summary Chris Gray
- PDMud thread summary James Wilson
- PDMud thread summary ApplePiMan@aol.com
- PDMud thread summary James Wilson
- PDMud thread summary ApplePiMan@aol.com
- PDMud thread summary ApplePiMan@aol.com
- PDMud thread summary Adam J. Thornton
- PDMud thread summary Chris Gray
- PDMud thread summary Niklas Elmqvist
- PDMud thread summary James Wilson
- PDMud thread summary Niklas Elmqvist
- PDMud thread summary Chris Gray
- PDMud thread summary Niklas Elmqvist
- PDMud thread summary Jon A. Lambert
- PDMud thread summary Chris Gray
- PDMud thread summary Chris Gray
- PDMud thread summary Alex Oren
- PDMud thread summary Alex Oren
- PDMud thread summary Jon A. Lambert
- PDMud thread summary Bruce Mitchener, Jr.
- PDMud thread summary Jon A. Lambert
- PDMud thread summary Jon A. Lambert
- PDMud thread summary Holly Sommer
- PDMud thread summary Jo Dillon
- PDMud thread summary Adam J. Thornton
- PDMud thread summary Jo Dillon
- PDMud thread summary Adam Wiggins
- PDMud thread summary Jo Dillon
- PDMud thread summary Chris Gray
- PDMud thread summary Chris Gray
- PDMud thread summary Alex Oren
- PDMud thread summary Chris Gray
- PDMud thread summary Alex Oren
- ADMIN: Unsubscriptions J C Lawrence
- DevMUD Event Language Hal Black
- DevMUD Event Language Jon Leonard
- DevMUD Event Language J C Lawrence
- DevMUD Event Language James Wilson
- DevMUD Event Language J C Lawrence
- DevMUD Event Language Chris Gray
- PDMud (was Bruce Sterling on Virtual Community goals) Chris Gray
- PDMud (was Bruce Sterling on Virtual Community goals) J C Lawrence
- PDMud (was Bruce Sterling on Virtual Community goals) Niklas Elmqvist
- PDMud (was Bruce Sterling on Virtual Community goals) James Wilson
- PDMud (was Bruce Sterling on Virtual Community goals) Jon Leonard
- PDMud (was Bruce Sterling on Virtual Community goals) ApplePiMan@aol.com
- PDMud (was Bruce Sterling on Virtual Community goals) Chris Gray
- PDMud (was Bruce Sterling on Virtual Community goals) Chris Gray
- PDMud (was Bruce Sterling on Virtual Community goals) Chris Gray
- PDMud (was Bruce Sterling on Virtual Community goals) Niklas Elmqvist
- Crack.Com deceased, Golgotha source released (sorta) J C Lawrence
- Crack.Com deceased, Golgotha source released (sorta) Bruce Mitchener, Jr.
- Crack.Com deceased, Golgotha source released (sorta ) Koster, Raph
- Crack.Com deceased, Golgotha source released (sorta ) Marc Hernandez
- Crack.Com deceased, Golgotha source released (sorta) Adam J. Thornton
- Crack.Com deceased, Golgotha source released (sorta) Adam Wiggins
- Crack.Com deceased, Golgotha source released (sorta) J C Lawrence
- Crack.Com deceased, Golgotha source released (sorta) J C Lawrence
- Crack.Com deceased, Golgotha source released (sorta) Bruce Mitchener, Jr.
- Game Developers Conference Koster, Raph
- Crack.Com deceased Marc Hernandez
- OT, kinda, but yay :) Koster, Raph
- OT, kinda, but yay :) Jon Leonard
- OT, kinda, but yay :) Nathan F Yospe
- OT, kinda, but yay :) Jon Leonard
- OT, kinda, but yay :) Koster, Raph
- OT, kinda, but yay :) Steve Sparks
- OT, kinda, but yay :) Adam Wiggins
- OT, kinda, but yay :) Chris Gray
- OT, kinda, but yay :) Jo Dillon
- OT, kinda, but yay :) Adam Wiggins
- OT, kinda, but yay :) Jo Dillon
- OT, kinda, but yay :) Jo Dillon
- PDMud (was Bruce Sterling on Virtual Community goals) Petri Virkkula
- Crack.Com deceased, Golgotha source released , (sorta) Holly Sommer
- OT: slashdot Adam Wiggins
- OT: slashdot J C Lawrence
- OT: slashdot J C Lawrence
- Language support Koster, Raph
- PDMud, Gamora and Casbah Bruce Mitchener, Jr.
- PDMud, Gamora and Casbah Caliban Tiresias Darklock
- PDMud, Gamora and Casbah Niklas Elmqvist
- PDMud, Gamora and Casbah Jon Leonard
- PDMud, Gamora and Casbah Darrin Hyrup
- PDMud, Gamora and Casbah Niklas Elmqvist
- PDMud, Gamora and Casbah Adam J. Thornton
- PDMud, Gamora and Casbah ApplePiMan@aol.com
- PDMud, Gamora and Casbah Chris Gray
- PDMud, Gamora and Casbah Darrin Hyrup
- PDMud, Gamora and Casbah Niklas Elmqvist
- UO: Second Age Koster, Raph
- PDMud (was Bruce Sterling on Virtual Community goals) Chris Gray
- PDMud (was Bruce Sterling on Virtual Community goals) Chris Gray
- PDMud (was Bruce Sterling on Virtual Community goals) Bruce Mitchener, Jr.
- Golgotha as it applies to PDMud (was Crack.Com deceased, Golgotha source , released (sorta)) Niklas Elmqvist
- OpenMUD: bus-based communications James Wilson
- OpenMUD: bus-based communications Chris Gray
- OpenMUD: bus-based communications Niklas Elmqvist
- OpenMUD: bus-based communications Niklas Elmqvist
- OpenMUD: bus-based communications ApplePiMan@aol.com
- I wanna do it OO James Wilson
- I wanna do it OO Chris Gray
- DevMUD - thoughts.1 Chris Gray
- DevMUD - thoughts.1 James Wilson
- DevMUD - thoughts.1 Chris Gray
- DevMUD - thoughts.1 Chris Gray
- DevMUD - thoughts.1 James Wilson
On Sun, 25 Oct 1998, Chris Gray wrote:
>Adding things at run-time (new properties ("class members"), new
>actions ("class methods")) is not incompatible with a strongly typed
>language. You just have to have the right view of things, and not
>be glued to the conventions that C++ and Java use. My MUD language
>is strongly typed, but I can do this at run time (in wizard mode):
>(Warning: 'private' does not mean what it does in C++ - it just says
>who can see the newly defined *symbol*.)
yes, that's the other meaning of 'dynamic typing' that I was advocating.
>I don't disagree. In my system, the very nature of the parser requires
>going from compiled code to interpreted code to compiled code to
>intepreted code (and possibly more) to handle nearly any input. What I'm
>trying to avoid is requiring extra overhead for native => native calls
>across module boundaries.
okay. that makes sense.
> >I'm trying to understand, so let me ask if this example is something along
> >your lines:
> >
> >Module 'web_support' is set up to work using an external resource
> >'g_net' which is some subclass of interface 'net_manager'. When 'web_support'
> >is loaded, it needs to find 'g_net' (i.e. resolve its external reference).
> >It asks some broker to give it 'g_net'. (There can be multiple specialized
> >brokers, or one huge one.) The broker determines if 'g_net' is currently
> >available, and if not tries to find a module which claims to provide it.
> >Assuming said module is found, it is loaded and the symbol is provided to
> >'web_support'.
>
>That's a sort-of valid example, I think. I hadn't thought about the idea
>of somehow automatically loading modules to resolve undefined references. I
>was more concentrating on how explictly loaded modules would be tied
>together. If we use 'dlopen' for loading, would a load module needed
>by another be automatically loaded by dlopen? How would *our* loader know
>that a given module exports a 'g_net' before someone has loaded that
>module?
modules would need to register their functionality with the dynamic loader,
so they could be loaded when such functionality is requested. cf. kerneld,
which requires you to run depmod first.
>I had thought that we wanted the various modules to be compiled completely
>independently of one-another. The only header file I had envisioned for
>inter-module stuff was one that defined constants for all of the currently
>existing interface kinds, and provides prototypes for that kind.
see the end of the message for more on this.
> >Using a
> >straight function call doesn't allow someone to write a handler which
> >has its own individual state, e.g.
> >
> >static string s_magic;
> >
> >void inputHandler (/* rep */)
> >{
> > // manipulate s_magic in a non-reentrant way
> >}
> >
> >is BAD in a multi-threaded environment (and inflexible in any case). The
> >alternative is quite appealing:
> >
> >struct input_handler
> >{
> > virtual void handle (/* rep */) = 0;
> >};
> >
> >can be specialized to be thread-safe and have any state it likes:
> >
> >struct my_input_handler
> >{
> > virtual void handle (/* rep */)
> > { /* magic */ }
> >private:
> > string _magic;
> > mutex _lock;
> >};
>
>I understand the C++ syntax you have written (except for "/* rep */" - is
>that just meant to copy the prototype?), but I'm completely failing to
>see what you are getting at. Sorry.
Writing it as a straight function call makes it impossible to extend by
subclassing, whereas using an object makes it possible. Since we don't
necessarily know all the things we are going to want to do in two months,
four months, a year, why limit ourselves by choosing the more inflexible
option?
persistent
>virtual world, all state should either be attached to the entity
>(e.g. player character) doing the action, or be global state attached to
>some other persistent entity in the virtual world.
*blink* why is that inconsistent with a handler having state? suppose I
wanted to write a persistent object that WAS an inputHandler? or do you
mean REALLY global state?
>In either case, the
>through the system's database.
this would assume that there's a distinction between DB objects and in-memory
objects, no? that is an issue which AFAIK hasn't yet been raised or resolved.
> There should be very little static state in
>any modules, and that all has to be protected by mutex's or spinlocks. Or,
>the module could use queuing to serialize accesses. An example of static
>state would
>maintain.
agreed, though I would again write that as fields in some object rather than
as static, so one could have multiple telnet servers running simultaneously.
> >IMO, interfaces should be up to the module programmers. Think of a module
> >as a shared library; to use that shared library, you write a program that
> >#includes the proper headers, and link it against libfoo.so. It's up to
> >you to use libfoo's api according to the headers, and up to the compiler
> >to check your errors. If you want to write a new module with some funky
> >interface, and Bob wants to use said funky interface, that should be as
> >easy as #including your headers and linking against your library (or
> >whatever analogue applies).
>
>If some modules wish to use shared libraries, that is up to them. 'dlopen'
>can take care of that. It is outside our concern. What I think we need is
no no, the analogy is that modules ARE shared libraries.
>ways whereby, e.g. modules that provide user input/output to the system
>can be linked up to modules that provide parsing, scenario code, and
>database operations. That linking up isn't done by name, it is done
>based on the semantic nature of what is needed.
how is this semantic nature determined?
> Hmm. I suppose you could
>use names to indicate that semantic nature. E.g. any module that exported
>a parser would export a public symbol called 'parse', and the dlsym
>facilities could be used to find that at run-time, and connect to it
>from an input provider. However, that is just replacing the set of
>constants in a header file with a set of strings, which would likely
>also be in the header file beside the prototypes needed.
some unix systems will do this automatically (I believe Linux
does) while others require you to roll your own inter-module
linking. rolling your own is thus more portable, and also much
more amenable to nice warning messages and graceful recovery
from link errors. ("Unresolved symbol _Rxsv1_void_foo_1Qvoid",
anyone?)
>In this scheme of the header file containing the prototypes for the
>interface kinds, it is quite easy to add new interface kinds. By
>definition, no module is using or exporting an interface kind before
>that interface kind is defined. OK, so someone needs a new one. They
>add it to the big header file, along with the prototype they intend for
>it. New modules can now be written that communicate using that new
>interface kind. Old modules, which by definition do not use the new
>kind, are not affected. Similar if someone wants old modules to use
>the new kind - they must be modified to use it, and all is still well.
>WOLOG (one of my math profs used that: WithOut Loss Of Generality).
>
>There is no particular reason that the "one big header file" couldn't
>be split up into smaller pieces, if there are specialized interfaces
>that only a couple of modules need. However, there does need to be
>some mechanism (Perl scripts?) to check that no interface kind ID
>(whether a number or a name) is used more than once. We don't want
>a parser calling a database's 'fixup' interface when it is supposed
>to be calling an output filter's 'fixup' interface.
this is not an issue with C++ or suitably name-mangled C.
>James, it seems to me you are thinking of building modules that are
>aware of each other at compile time. I've been trying to avoid that,
>so that only at run-time are they actually attached to one-another.
>But then, I could be missing your point altogether. How about a
>more detailed example?
I guess I don't see the alternative to having modules know about one
another at compile time. Either they refer to some external symbols
(which end up being function pointers or objects with virtual methods)
or ... what? No module refers to any external symbols? All function
calls are done by (a stringified) name?
Here's what worked for me a couple of years ago.
module web_magic contains functions which use network functions such as
gethostbyname. These network functions live in another module, 'net_lib'.
When web_magic is written, something is put at the top which says "I
depend on net_lib". The C++ code for web_magic contains module initialization
code (_init () in most dlopen implementations) which is responsible for
dynamically loading net_lib and linking up the functions web_magic uses
with their bodies in the net_lib module. So, this could look like
<pseudocode>
/* web_magic */
/* some definitions here of function pointers or polymorphic objects
* which we need from other modules, e.g. */
static struct hostent *(*_gethostbyname) (string name);
extern "C" void _init (void)
{
/* use the dynamic loader to pull in the external
* references we need. Perhaps we name netlib.so explicitly */
void *net_lib = dlopen ("net_lib.so", RTLD_NOW);
_gethostbyname = dlsym (net_lib, "gethostbyname");
/* or maybe there's something like kerneld that will find the
* netlib module for us and give us the right reference: */
_gethostbyname = dynaloader->resolve_function ("gethostbyname");
/* or maybe there's even a type-safe loading mechanism */
_gethostbyname = typesafe_dynaloader->resolve_function
("struct hostent *gethostbyname (string)");
}
</pseudocode>
So, 'web_magic' is _aware_ of net_lib at compile time, but is only
linked up with it at load-time.
This is all off the top of my head, BUT something like it did work.
Actually, it was wrapped up in some C++ static initializers so
nobody'd ever have to care about the minutia of dynamic loading on
Win32 versus Irix versus Linux.
>Please, someone jump on me if I'm coming on too strong here. I'm not
>trying to squelch anyone else's ideas and proposals. I'm just espousing
>some thoughts I've had.
you're not coming on strong, at least in this message. and besides, what's
wrong with a little debate? we're not delicate little flowers.
James
- DevMUD - thoughts.1 James Wilson
- DevMUD - thoughts.1 Niklas Elmqvist
- DevMUD - thoughts.1 Chris Gray
- CVS and LXR bruce@portland.puremagic.com
- openmud or pdmud or devmud James Wilson
- openmud or pdmud or devmud Chris Gray
- openmud or pdmud or devmud Darrin Hyrup
- openmud or pdmud or devmud Hal Black
- openmud or pdmud or devmud Jon Leonard
- openmud or pdmud or devmud Adam J. Thornton
- openmud or pdmud or devmud Bruce Mitchener, Jr.
- openmud or pdmud or devmud Adam J. Thornton
- openmud: open issues James Wilson
- openmud: open issues Vadim Tkachenko
- openmud: open issues James Wilson
- openmud: open issues Vadim Tkachenko
- MUD verb handling (Was: DevMUD - thoughts.1) Chris Gray
- MUD verb handling (Was: DevMUD - thoughts.1) Adam J. Thornton
- MUD verb handling (Was: DevMUD - thoughts.1) The Arrow
- MUD verb handling (Was: DevMUD - thoughts.1) Jon Leonard
- MUD verb handling (Was: DevMUD - thoughts.1) Niklas Elmqvist
- Missing the point: OpenMUD, Gamora, Casbah, etc. Bruce Mitchener, Jr.
- Missing the point: OpenMUD, Gamora, Casbah, etc. Jon A. Lambert
- Missing the point: OpenMUD, Gamora, Casbah, etc. Niklas Elmqvist
- Missing the point: OpenMUD, Gamora, Casbah, etc. Darrin Hyrup
- Missing the point: OpenMUD, Gamora, Casbah, etc. Bruce Mitchener, Jr.
- Missing the point: OpenMUD, Gamora, Casbah, etc. Ola Fosheim Grøstad
- Missing the point: OpenMUD, Gamora, Casbah, etc. Bruce Mitchener, Jr.
- Missing the point: OpenMUD, Gamora, Casbah, etc. Ola Fosheim Grøstad
- Missing the point: OpenMUD, Gamora, Casbah, etc. Chris Gray
- Missing the point: OpenMUD, Gamora, Casbah, etc. Bruce Mitchener, Jr.
- Missing the point: OpenMUD, Gamora, Casbah, etc. Ola Fosheim Grøstad
- Missing the point: OpenMUD, Gamora, Casbah, etc. Chris Gray
- DevMUD module configuration Jon Leonard
- DevMUD module configuration James Wilson
- DevMUD module configuration Bruce Mitchener, Jr.
- DevMUD module configuration J C Lawrence
- DevMUD module configuration Chris Gray
- DevMUD module configuration Niklas Elmqvist
- DevMUD module configuration Vadim Tkachenko
- Inheritance model (was PDMud thread summary) Bruce Mitchener, Jr.
- Inheritance model (was PDMud thread summary) Cynbe ru Taren
- Why did it take years? Cynbe ru Taren
- Why did it take years? Adam Wiggins
- Why did it take years? James Wilson
- Why did it take years? Bruce Mitchener, Jr.
- Why did it take years? Niklas Elmqvist
- Why did it take years? Holly Sommer
- Why did it take years? J C Lawrence
- Why did it take years? Jo Dillon
- Why did it take years? Cynbe ru Taren
- Why did it take years? J C Lawrence
- Why did it take years? Adam Wiggins
- Why did it take years? Chris Gray
- Why did it take years? Erik Ostrom
- Gamora: Lessons learned? (fwd) Niklas Elmqvist
- Gamora: Lessons learned? (fwd) Niklas Elmqvist
- resource management (was: Missing the point) Felix A. Croes
- DevMUD: Inheritable modules The Arrow
- DevMUD: Inheritable modules Bruce Mitchener, Jr.
- DevMUD: Inheritable modules Jon Leonard
- DevMUD: Inheritable modules The Arrow
- DevMUD: Inheritable modules Jon Leonard
- DevMUD: Inheritable modules James Wilson
- DevMUD: Inheritable modules Jon Leonard
- DevMUD: Inheritable modules James Wilson
- DevMUD: Inheritable modules Jo Dillon
- DevMUD: Inheritable modules James Wilson
- DevMUD: Inheritable modules Niklas Elmqvist
- DevMUD: Inheritable modules Jon Leonard
- DevMUD: Inheritable modules Niklas Elmqvist
- DevMUD: Inheritable modules Jo Dillon
- DevMUD: Inheritable modules Robert Brady
- DevMUD: Inheritable modules J C Lawrence
- DevMUD: Inheritable modules Darrin Hyrup
- DevMUD: Inheritable modules Jo Dillon
- DevMUD: Inheritable modules Chris Gray
- DevMUD: Inheritable modules Adam J. Thornton
- DevMUD: Inheritable modules James Wilson
- DevMUD: Inheritable modules Jon A. Lambert
- DevMUD: Inheritable modules James Wilson
- DevMUD: Inheritable modules James Wilson
- DevMUD: Inheritable modules Jon A. Lambert
- DevMUD: Inheritable modules Cynbe ru Taren
- DevMUD: Inheritable modules Jon A. Lambert
- DevMUD: Inheritable modules Jo Dillon
- DevMUD: Inheritable modules Vadim Tkachenko
- DevMUD: Inheritable modules Chris Gray
- DevMUD: Inheritable modules Chris Gray
- DevMUD: Inheritable modules James Wilson
- DevMUD: Inheritable modules Adam J. Thornton
- DevMUD: Inheritable modules James Wilson
- DevMUD: Inheritable modules The Arrow
- DevMUD: Inheritable modules The Arrow
- DevMUD: Inheritable modules Thandor
- DevMUD: Inheritable modules The Arrow
- DevMUD: Inheritable modules Thandor
- DevMUD: Inheritable modules Jon A. Lambert
- DevMUD: Inheritable modules Chris Gray
- DevMUD: Inheritable modules Chris Gray
- DevMUD: Inheritable modules Chris Gray
- DevMUD: Inheritable modules Chris Gray
- DevMUD: Inheritable modules Chris Gray
- DevMUD: Inheritable modules Chris Gray
- DevMUD: Inheritable modules James Wilson
- DevMUD: Inheritable modules J C Lawrence
- [DevMUD] driver implementation language Hal Black
- META/ADMIN: CVS for DevMUD security J C Lawrence
- META/ADMIN: CVS for DevMUD security Jon Leonard
- META/ADMIN: CVS for DevMUD security James Wilson
- DevMUD Objectives? Thandor
- DevMUD Objectives? Koster, Raph
- DevMUD Objectives? Ola Fosheim Grøstad
- DevMUD Objectives? Petri Virkkula
- DevMUD Objectives? Thandor
- DevMUD Objectives? Niklas Elmqvist
- DevMUD Objectives? Thandor
- DevMUD Objectives? Darrin Hyrup
- DevMUD Objectives? Travis Casey
- DevMUD Objectives? Chris Gray
- DevMUD Objectives? Chris Gray
- DevMUD Objectives? Hal Black
- DevMUD Objectives? Thandor
- Why modules? (Was: Inheritable modules) Ola Fosheim Grøstad
- Why modules? (Was: Inheritable modules) Chris Gray
- Why modules? (Was: Inheritable modules) Chris Gray
- Why modules? (Was: Inheritable modules) Thandor
- Why modules? (Was: Inheritable modules) James Wilson
- Why modules? (Was: Inheritable modules) Adam J. Thornton
- Why modules? (Was: Inheritable modules) Vadim Tkachenko
- Why modules? (Was: Inheritable modules) Ola Fosheim Grøstad
- Why modules? (Was: Inheritable modules) Vadim Tkachenko
- Why modules? (Was: Inheritable modules) Ola Fosheim Grøstad
- Why modules? (Was: Inheritable modules) Thandor
- Why modules? (Was: Inheritable modules) James Wilson
- Why modules? (Was: Inheritable modules) Jon A. Lambert
- Why modules? (Was: Inheritable modules) Thandor
- Why modules? (Was: Inheritable modules) Jon A. Lambert
- Why modules? (Was: Inheritable modules) Ola Fosheim Grøstad
- Why modules? (Was: Inheritable modules) Vadim Tkachenko
- Why modules? (Was: Inheritable modules) Ola Fosheim Grøstad
- Why modules? (Was: Inheritable modules) Jon A. Lambert
- Why modules? (Was: Inheritable modules) Ola Fosheim Grøstad
- Why modules? (Was: Inheritable modules) Vadim Tkachenko
- Why modules? (Was: Inheritable modules) Jon A. Lambert
- Why modules? (Was: Inheritable modules) Vadim Tkachenko
- Why modules? (Was: Inheritable modules) Vadim Tkachenko
- Why modules? (Was: Inheritable modules) Vadim Tkachenko
- Why modules? (Was: Inheritable modules) J C Lawrence
- MUD-Dev's DevMUD: a word of caution Greg Munt
- MUD-Dev's DevMUD: a word of caution Cynbe ru Taren
- MUD-Dev's DevMUD: a word of caution Ola Fosheim Grøstad
- MUD-Dev's DevMUD: a word of caution Chris Gray
- MUD-Dev's DevMUD: a word of caution ApplePiMan@aol.com
- MUD-Dev's DevMUD: a word of caution Jon A. Lambert
- MUD-Dev's DevMUD: a word of caution Chris Gray
- MUD-Dev's DevMUD: a word of caution Ola Fosheim Grøstad
- MUD-Dev's DevMUD: a word of caution Cynbe ru Taren
- MUD-Dev's DevMUD: a word of caution Ola Fosheim Grøstad
- MUD-Dev's DevMUD: a word of caution Adam J. Thornton
- MUD-Dev's DevMUD: a word of caution Ola Fosheim Grøstad
- MUD-Dev's DevMUD: a word of caution James Wilson
- MUD-Dev's DevMUD: a word of caution Ola Fosheim Grøstad
- MUD-Dev's DevMUD: a word of caution Niklas Elmqvist
- MUD-Dev's DevMUD: a word of caution The Arrow
- MUD-Dev's DevMUD: a word of caution Thandor
- DevMUD: Module message passing The Arrow
- DevMUD: Module message passing Vadim Tkachenko
- Why mudules and some other questions. Ben Greear
- Why mudules and some other questions. Vadim Tkachenko
- Reminiscing Jon A. Lambert