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
I changed the topic to the suggested "PDMud". So sue me, this thread
sorely needed a name change. :)
On Tue, 20 Oct 1998, Jon Leonard wrote:
> On Tue, Oct 20, 1998 at 11:58:27AM +0200, Niklas Elmqvist wrote:
> > On Mon, 19 Oct 1998, Jon Leonard wrote:
> > > That said, I think some sort of byte-code machine makes a lot of sense
> > > as an option. Which buzzwords do we want to start with?
> >
> > Umm, do I get to pick? :)
>
> If no one else has an opinion, yup. :-)
>
> > Efficient and garbage collected are two, and
> > threaded should not be too hard to tack on... And a stack-based VM like
> > the JVM sounds pretty good.
>
> I asked because I don't think it's obvious. My current interpreter is
> neither threaded nor stack-based. (It isn't efficient, either, but let's
> ignore that.)
Hehe.
I am not entirely sure about the focus for the virtual machine (and it's
language). As I see it, we basically have two options:
1) Use the VM (and language) to implement game systems as well as a "quest
and world programming language" (ala LPC or ColdC).
2) Use the VM (and language) as a "quest and world programming language".
Period.
One way to look at it is to ask ourselves this question: "Do we want to be
able to implement stuff like network code, DB handlers and event managers
with our VM?" If no, we'd go for option 2) and stick to putting this kind
of low-level/engine-specific code into dynamically loaded (there's that
word again :) modules. If yes, go for 1) and design an all-out .
Personally, I am all in favor of # 2. I believe that an internal language
for a MUD should be tailored for use when programming the behavior of the
MUD world, not the MUD engine. The engine is "nothing" more than a sandbox
for the VM (cf JVM in browsers) which provides engine primitives such as
event managing, data channels, security, etc.
> The issues for these buzzwords as I see them:
>
> Efficient: May make the VM harder to understand.
Right. Could maybe be done later. The optimizing step is "just" a filter
through which you pass the bytecodes before emitting them, after all.
> Garbage collected: Some languages prefer the malloc/free model, and some
> run with static allocations. These don't benefit from a garbage
> collector (but would benefit from resource tracking: At end of
> thread, collect any malloced but unfreed space, etc.), and would
> pay a performance penalty if it were enabled. Similarly, type
> taging for tracing pointers or some replacement technique is
> required. (And anything better than reference counting can be
> fairly hard to follow.)
>
> Threaded: If we want the VM itself to be multithreaded, then we need
> locking for various parts of the VM. There's a real performance
> cost there. I'd like at least a compile time option to turn it
> off for uniprocessor machines.
Well, with a stack-based approach (can't speak for anything else as I am
quite new to compiler design and have only come in touch with stack-based
VMs) it's fairly easy to suspend execution of a Thread (an object which
contains thread-specific things such as the PC, stack frame, etc) in favor
of another in a single-threaded VM.
But since I am no expert at compiler/VM design (as you may have noticed),
merely interested, I will leave these weightier decisions to others.
> Being able to run multiple threads of the bytecode is a must.
> This can be implemented using something like cooperative multitasking,
> or even just forcing each bytecode operation to complete before
> doing something else (interrupt, other thread, etc.).
Right. Cooperative multitasking is IMHO a little dated, and I (if I did
this myself) would allow each bytecode operation to finish before
switching to another Thread.
> Stack-based: This does pointless, inefficient things to continuation-passing
> languages. It also doesn't map well into superscalar hardware, but
> I don't forsee doing custom hardware for the bytecode.
Well, as I said, stack-based is all I know, and the fact that the Java
people used it says something, does it not? :)
> I'd recommend going for efficient, possibly GC'd, threaded in the bytecode
> model, and stack based. (Leaving open the possibility of alternate VMs if
> we get tired of the first one.)
I agree. The GC-part is not a must, but would be nice. However, if we do
want it, it should be something we add from the beginning, yes?
[environment for the language module: functions, callbacks, etc.]
> I think some C++ charateristics are incompatable with what we want to do:
>
> 1) The C++ object model is unique to C++, and using C++ objects from another
> language requires writing wrappers that use C bindings. C++ naming
> conventions aren't even consistent between compilers, and prevent
> other languages calling objects directly.
Yes, I guess this is a problem, but only if we want to allow other
languages to use our objects. We can solve the naming scheme
incompatibilities between compilers by exporting factory functions from
the code modules which are marked #extern "C". You would have to do this
anyway if you want to use dlsym() on the factory function's real name
instead of the mangled name.
> If we're going to have C bindings for things, (necessary for
> supporting in-game languages like Perl, Python, TCL, etc.) then
> I don't see the point in building separate C++ interfaces.
Hmm. You have a point.
> 2) The C++ object model doesn't lend itself to mix and match components,
> in that it can require a recompile to change between logically
> equivalent interfaces ("fragile base class problem"). This
> prevents dynamic loading of modules, at least in some combinations
> that I want to use.
Hmm, I'm not entirely sure what you are refering to, but I think external
inheritance solves this. As long as you keep the base class (which should
be nothing more than an empty shell) the same, you can inherit from this
in the independant code modules and redefine it before reloading the
module and creating the object. No recompilation of the core executable is
necessary in this case, I assure you.
Of course, there is always the aspect of not having to change the base
class. This comes to down to good design and adequate interface, though.
> If there are good workarounds for these kinds of problems (and the consensus
> is that people want to use C++), then I'll ignore my distaste for C++
> (I've been burned more than once by C++isms on large projects) and use it.
Maybe this is a good time to survey how many people on this list are ready
to pitch in on a project like this and contribute? Oh, and the list will
be the perfect forum to tell our war stories as well as bounce some ideas
and design issues before implementing them.
Btw, I've been with the list for a while and am surprised nothing like
this has happened before(?). It seems like an almost logical step.
> I have no objections to modules being written in C++ (or some other language),
> but I prefer interfaces using C calling conventions. (extern "C" in C++)
Well, how would you go about using C++ objects in a C++ module loaded by a
C program? Never mind, I assume you have the answer :)
> A proposed basic module interface:
>
> With the exception of a bootstrap module, all modules can be loaded with
> dlopen.
Right. But would not the base server require some functionality besides
module handling? Off the top of my head (well, I've designed something
similar before), I come up with the following list:
- event manager
- decoupled message chain/channel system or something similar
- module handler (loading/unloading of code modules)
I was about to add "virtual machine" to the list, but maybe even this
could be loaded as a module?
[snip]
> All modules should have in the exported structure functions for
> initializing, shutting down, getting the module's name, and getting the
> version.
Right, and maybe a short descriptive string or something.
> If a module serves a standard purpose, it should export functions that
> match the definition for modules that do that. A module may serve
> serveral purposes, in which case it should export the appropriate functions
> for all of them.
>
> Modules may interact by other means as well. This can be because they were
> compiled together, negotiated an additional interface, or whatever.
Okay, this is where my brain twists in on itself. How do modules
communicate with each other? How are they tied together? Me, I'd like the
modules to be completely decoupled, but I'm perverted in that sense :)
[snip (hypothetical) example]
> Modules involved:
> Boot
> Location manager
> Language
> Database manager
Right, this mirrors my thoughts pretty closely. I am, however, very
interested in how inter-module communication is carried out in this
example. Using a message/request-passing system, you would get something
like this (still hard-coded Diku mode):
The player enters "north" and the TelnetModule emits a request with this
message along with socket information. The ParserModule captures the
request, parses the text and then sends a new message to the request chain
about the parsed command. This one is picked up by the
CommandExecutorModule (kof) which moves the player to the new room and
requests a description text to be sent to the player. The DatabaseModule
captures this, sends a description message, etc...
Ok, maybe a little low-level/low-tech and maybe not very illustrative.
Comments? Better ways of doing this?
> In-game entities involved:
> A player
> A room
> A script
>
> Sound feasable?
Yes, very.
> I wouldn't assume that modules can't know what other modules are present.
> The environment should probably provide functions to tell if a given
> module is present, and also to list all present modules. Something in
> the code needs to know this, after all.
Hmm... Yes, the module handler knows the names, filenames and pointers to
the dynamically loaded code modules, but do the individual modules know
this? Can you figure out what a module does just by looking at its name?
Maybe there could be several different implementations of the same kind of
module? What if someone creates a replacement for the "standard"
MagicModule and wants it to work seamlessly by capturing all magic-related
requests and just not handling all of them (or handling *more* of them)?
Having the modules know nothing about other modules is IMHO the most clean
solution.
Admittedly, you need *some* kind of coordination between modules. The
ParserModule must know the acceptable commands supported by the
other modules (or does it? Maybe this could be polled by a message from
the ParserModule: "Okay, send me your command grammars along with a way of
packaging this into a request you can capture.").
> I like the "request to be notified when X happens" primitive. Message
> chains are a possible way to implement this, but not the only way.
Roger. But I like it in the way that it is completely decoupled (there's
that word again ;).
> I'm not sure about the need for default handlers, and I can think of cases
> where more than one thing needs to get notified when something happens.
Okay, my thought was on having the default handlers take care of requests
which are not captured by any of the modules attached to the message
chain. That is, if no one took care of a "MegaBoom Spell" Command request
(due to some glitch in the ParserModule versus the MagicModule), the
default handler would silently take dispose of the request and emit an
error message in the log or something.
> I'll happily contribute a website, server space, accounts, etc. on
> frost.slimy.com. (160 Kbit network connection, 600 MHz Alpha)
> Somewhere else might be better. (Kanga.nu would be easiest to find,
> for example.) There's nothing stopping us from having different modules
> living on different servers, with links and mirroring to make it easy to
> find stuff.
Yes, but the main server/core/driver (maybe a convention would be in order
here) should reside somewhere nice. Slimy sounds just like what we need
(SlimyMUD? :).
> I prefer having everything on my machine, but it really doesn't matter much.
Fine by me. My own server (486DX-100) is not anywhere powerful enough :)
(Although I do have a T1 to the net -- in Sweden).
> > GNU Mud anyone?
>
> Naming it GNU Mud is at least misleading if it's not GPL'd, and as much
> as I like the Gnu Public License, it doesn't fit this project.
>
> I want code that I or anyone else can modify, experiment with, and even
> build commercial servers out of, without having to worry about what's
> permitted. GPL may not necessarily prohibit running commercial services,
> but it might wind up forcing release of client source code (including
> signatures to prevent cheating clients?) and be otherwise unpalatable
> to commercial interests.
Ahh, you're right. Well, it sounded neat and official.
> Public domain may wind up being the right license -- PDMud?
Henceforth, this project is named PDMud -- for the moment, at least. Being
on the other side of the Atlantic and posting when you guys are asleep (?)
and not able to reply does have *some* advantages.
> Jon Leonard
-- Niklas Elmqvist (d97elm@dtek.chalmers.se) ----------------------
"Nanny Ogg looked under her bed in case there was a man there.
Well, you never knew your luck."
-- Terry Pratchett, Lords and Ladies - 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
- 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