January 2001
- Proper MU* style list Kyndig
- Proper MU* style list Malcolm Tester
- Proper MU* style list Daniel A. Koepke
- Proper MU* style list Richard A. Bartle
- Proper MU* style list Christopher Allen
- Proper MU* style list Koster, Raph
- Proper MU* style list Kerem HADIMLI
- MU* styles Kerem HADIMLI
- Moving away from the skill system Inq Admin
- Moving away from the skill system Hulbert, Leland
- Moving away from the skill system jrb@kc.rr.com
- About.com article on Skotos Christopher Allen
- About.com article on Skotos Matthew Mihaly
- About.com article on Skotos Christopher Allen
- About.com article on Skotos SavantKnowsAll@cs.com
- About.com article on Skotos Christopher Allen
- About.com article on Skotos Matthew Mihaly
- About.com article on Skotos Hans-Henrik Staerfeldt
- About.com article on Skotos Klara
- About.com article on Skotos Jon Morrow
- About.com article on Skotos Matthew Mihaly
- Skill-Trees & Christopher Allen
- Skill-Trees & Phil Hall
- Skill-Trees & Wes Connell
- Skill-Trees & Travis Casey
- Skill-Trees & Christopher Allen
- Skill-Trees & Dmitri Zagidulin
- Skill-Trees & Travis Casey
- Skill-Trees & Travis Casey
- Player statistics Wes Connell
- Player statistics Marc Bowden
- Player statistics Wes Connell
- Player statistics Marc Bowden
- Player statistics Matthew Mihaly
- Player statistics rayzam
- Player statistics Klara
- Player statistics Wes Connell
- Player statistics Koster, Raph
- Player statistics Jake Song
- Player statistics Koster, Raph
- Player statistics Matthew Mihaly
- Player statistics Dave Rickey
- Player statistics msew
- Player statistics Jessica Mulligan
- Player statistics Vincent Archer
- Player statistics Koster, Raph
- Player statistics David Kennerly
- Player statistics Dave Rickey
- Player statistics David Kennerly
- Player statistics Jake Song
- Player Statistics Jessica Mulligan
- Player statistics Jake Song
- CGDC Dinner J C Lawrence
- Skotos Anthony R. Haslage
- Skotos Richard.Woolcock@rsuk.rohde-schwarz.com
- "Men are from Quake, Women are from Ultima" Koster, Raph
- "Men are from Quake, Women are from Ultima" Marc Bowden
- "Men are from Quake, Women are from Ultima" Koster, Raph
- "Men are from Quake, Women are from Ultima" Willowreed@aol.com
- "Men are from Quake, Women are from Ultima" Tess Snider
- "Men are from Quake, Women are from Ultima" Koster, Raph
- "Men are from Quake, Women are from Ultima" Michael Tresca
- "Men are from Quake, Women are from Ultima" Chris Lloyd
- "Men are from Quake, Women are from Ultima" Tess Snider
- "Men are from Quake, Women are from Ultima" SavantKnowsAll@cs.com
- NomicWiki J C Lawrence
- more idiocy from graphical MUD developers Matthew Mihaly
- An Idea... Mud Development Framework Jeremy Lowery
- An Idea... Mud Development Framework David Loeser
- An Idea... Mud Development Framework Bruce
Hiya Jeremy,
Jeremy Lowery wrote:
> <EdNote: Duplicate HTML copy deleted. Formatting
> cleaned up. I'd much rather you did this than me.>
(And I keep having to reformat what I'm replying to in order that
it might hopefully line-wrap correctly.)
<EdNote: bow>
> MDK (Mud Development Kit)
> Jeremy Lowery
>
> Purpose
>
> The MDK's purpose is to provide a scriptable object-
> oriented MUD developing environment.
What is your intent here when you say 'scriptable'?
Do you mean that you want end users to be able to modify the
behavior of the system without having to learn a complicated
programming language?
Or, do you mean that the code should be able to be modified at
runtime?
Or, do you have another meaning entirely?
> The MDK Framework
>
> The MDK system is the framework that is used to develop
> muds. MDK implements a class-object hierarchy, design
> patterns, and polymorphic data-types to support the
> extensible nature of the development environment (DE).
>
> The Object Factory
>
> The object factory manages all objects created in the
> DE. The factory also includes built in support for object
> serialization via standard C++ file streams. The factory
> maintains the file structure of all game objects internally
> in a special resource file named ofrdb.mlib (object factory
> reference database). The factory also needs to keep track of
> all objects created in the game. This is accomplished by a
> unique virtual index number assigned to every single "thing"
> created in game (all of which are objects).
That sets an initial assumption that you'll be working in C++.
Are these objects C++ objects, or some construction of your own?
What happens when (not if) someone puts the wrong data into
ofrdb.mlib?
What are the virtual index numbers used for? (Why are they
virtual?)
Can you have multiple object factories?
> Advantages include:
>
> a.. Item copying identification
What is this?
> b.. System Snapshots
How will you go about maintaining the integrity of the data and
insuring that a snapshot is a fully consistent view of the data
at that point in time?
> The Notifier
>
> The object notifier is a singleton object that processes
> and dispatches object-based messages. Based on the message
> scope and type, the notifier dispatches the message to the
> corresponding target object(s). The notifier also has built
> in security features that allow message destruction before
> processing for invalid message usages. The notifier and
> object factory work closely together to handle object-
> creation and message dispatching. Indeed, they share the
> same object pool.
Why is there only one notifier? What happens in the event of a
distributed system or a cluster of servers?
What type of security features are these? Is this at the
scripting level or the C++ level (or both)? If at the C++ level,
how does the C++ code get information about the environment
within which it is running to make security decisions? (I'm
thinking about MOO with its task-based security system and
ColdCore which has a system of primitives upon which you can
build an object-based security system. I'm not aware of many
other security systems in the MUD world. There is some
interesting stuff out there like the work on E
(http://www.erights.org) and some work based on the Lambda
Calculus (http://mumble.net/jar/pubs/secureos/secureos.html).
> Game Messages
>
> Object interaction is achieved by using the notifier. All
> objects must override member functions that parse system
> messages directed to them by other objects.
There is no way to have a message bound to a bit of code (like a
method), or do I misunderstand what you mean when you say
'parse'?
> In addition to simple object messages, the DE also
> supports message scope resolution for message sending
> objects. These specifiers can be used to send messages
> at a certain game-level scope (More on this a little
> later). All messages are identified by a unique integer
> constant abbreviated MM_ (for mud message). Associated
> with messages is a generic message handling data-type
> identifying message specific data. Unlike most MUD systems,
> the MDK does not explicitly bind client messages to
> character objects. One of the main advantages this
> approach exposes is the use of a common socket-polling
> connection for every kind of game manipulation that is
> possible. Aside from characters playing the game, this
> also allows administrators, builders, and developers to
> have parallel game access, but via different interfaces.
I'm not sure that I understand much of the above paragraph.
> System Messages
>
> The framework can also send messages to game objects.
> Unlike game message, system messages know no boundary.
> Of course, it is the object's responsibility to actually
> do something with the message. Common examples of system
> message include time messages, shutdown messages, client
> disconnection, and persistence messages (i.e. messages
> that tell objects to save themselves on a regular basis
> incase of system failure).
Is there any default handling for some of the messages, like the
one directing an object to save itself? If not, wouldn't this
have the negative effect of distributing the knowledge of
handling data saves through out the code?
For some thoughts on that topic, check out a post by Miroslav
Silovic,
http://www.kanga.nu/archives/MUD-Dev-L/2000Q2/msg00060.php
> The Network
>
> One of the only things that need to be hard-coded into the
> system is the actual game server. Of course, in reality
I'll take exception with the concept of 'hard code' later in this
post.
> it is just another object. It sends messages to other
> objects and receives them just as any other object does
> (via a method called message/object pooling discussed
> later). Not only does the network processes in route
> messages, it also binds client connects to game objects
> (mainly characters). The network then dispatches the
> messages to the object with a special client-specifying
> message. Although this can also be manipulated to include
> other objects such as items or rooms (not just characters).
> All objects that can be manipulated by clients exposes a
> command interface that is used for client manipulation.
> Scripts to manipulate the objects programmatically can
> also use this interface. For example: the Mobile object
> exposes a message-handling interface that includes a talk
> command. In a script, a NPC can use the exact same
> speaking interface that players use to communicate.
>
> Client-Binding
>
> All clients must always be binded to some object that
> exposes a command interface. Even if this object is not
> an in-game representation of something (such as a
> character). Other interface objects may include a
> character loader object, a shopping object, or a
> menu object.
I've come to like how Cold handles this and will be doing
something similar in my current server efforts.
Cold lets you assign a connection to any object. When there is
incoming data, it calls the 'parse' method on that object. From
here on out, it is up to the core to set the policy for what
happens and how that input is handled.
ColdCore builds upon this by providing $connection objects which
handle the actual connection, but which delegate all input to an
instance of an object that implements the $connection_interface
interface. For something like a login screen, there is an
instance of $login_interface. Once a user has logged in, the
object that the $connection delegates to is changed to
appropriate user object, which happens to implement the
$connection_interface interface. This allows us to handle many
other networking tasks, like SMTP, HTTP, POP3, etc simply by
implementing specialized interface objects that understand that
protocol.
> ... Stuff snipped ...
> The Life of an Object
>
> Generally, all objects live the same life inside the
> program. They are created by the Object Factory, load
> their data from disk, sit around processing messages,
> and eventually die. Of course, the most interesting
> part is the message processing. All objects are inherently
I don't know .. I think that the 'eventually die' part of the
object lifetime is Very Interesting. How do you know when an
object can die? How do you handle lingering references to
it/dangling pointers? Do you explicitly manage the lifecycle of
objects? Use refcounting? Full blown garbage collection?
> ... Much snipped ...
I disagreed with a lot of what I snipped, but there wasn't any
simple way to explain why apart from my holding a different set
of beliefs.
As I said above, I'd explain why I don't like 'hard code'. There
are servers around which are almost entirely in 'hard code'. Any
change requires a reboot, but the whole thing is pretty much
written in a single language. However, they aren't very
extensible during runtime.
There are another class of servers which implement a 'driver' or
the base server, like Cold, MOO, Muq, and DGD. On top of this, a
mudlib, or core is written which implement the actual game. The
driver provides a set of abstractions and a set of interfaces
with which the core can communicate. Over time however, it seems
that the evolution has been to move the boundary lower and lower,
so that less and less policy has been hard coded within the
driver and more left up to the core. Also, there are typically
at least 2 implementation systems used when working with one of
these systems. The basic driver is often written in C, while the
core is written in a custom language provided by the driver
(except in Muq's case, where Muq lets the core provide
assemblers, so that many languages can be supported).
In working with Cold, as I've needed to do more and more complex
things, I've often needed to lower the boundary even further so
that the driver was deferring to the core more, but
unfortunately, it was in performance critical areas, and doing so
wasn't entirely possible due to the inability for the driver to
call into the core and get back a result.
To solve this problem and others, I wanted a system that didn't
have a 'driver' or a 'core'. I didn't want to have to switch
languages depending on which level I was working at. I wanted to
be able to soft-code things to prototype them out and then
'convert' them to 'hard code'. I want to see a new type of
server where you can work in the same language from the ground on
up, accessing the same object model. Ideally, I'd be working in
an interpreter for that language to prototype while the server is
running, and then have a mechanism for compiling code that native
code to be linked into the server for greater speed. Because
there is no boundary between 'driver' and 'core', but only a set
of libraries which comprise a server framework, there aren't
arbitrary boundaries to work around in setting up low level
elements of the system. I'm on the path currently towards
creating such a server.
- Bruce - An Idea... Mud Development Framework Jeremy Lowery
- An Idea... Mud Development Framework Bruce
- An Idea... Mud Development Framework Miroslav Silovic
- An Idea... Mud Development Framework Ben Chambers
- An Idea... Mud Development Framework Justin Rogers
- An Idea... Mud Development Framework Ben Chambers
- An Idea... Mud Development Framework John Buehler
- An Idea... Mud Development Framework Bruce
- An Idea... Mud Development Framework Jeremy Lowery
- An Idea... Mud Development Framework Chris Jones
- Server stability (was: Player statistics) Bruce
- Server stability (was: Player statistics) Koster, Raph
- Server stability (was: Player statistics) Bruce
- Server stability (was: Player statistics) Koster, Raph
- Server stability (was: Player statistics) J C Lawrence
- Server stability (was: Player statistics) Valerio Santinelli
- Server stability (was: Player statistics) Tess Snider
- Server stability (was: Player statistics) Bruce
- Server stability (was: Player statistics) Koster, Raph
- Server stability (was: Player statistics) Ben Chambers
- Server stability (was: Player statistics) Chris Jones
- New Muds Corey Crawford
- Dinner scheduling and possible roundtable J C Lawrence
- New Mud Fox McCloud
- MUD-Dev digest, Vol 1 #277 - 13 msgs Dr. Cat
- MUD-Dev digest, Vol 1 #277 - 13 msgs Matthew Mihaly
- MUD-Dev digest, Vol 1 #277 - 13 msgs Jake Song
- MUD-Dev digest, Vol 1 #277 - 13 msgs Jeff Freeman
- Server stability (was: Player statistics) Par Winzell
- Server stability (was: Player statistics) J C Lawrence
- Server stability (was: Player statistics) Bruce
- Server stability (was: Player statistics) Felix A. Croes
- MUD-Dev digest, Vol 1 #277 - 13 msgs J C Lawrence
- MUD-Dev digest, Vol 1 #277 - 13 msgs Jake Song
- MUD-Dev digest, Vol 1 #277 - 13 msgs Bruce
- MUD-Dev digest, Vol 1 #277 - 13 msgs Mark Watson
- ANNC: .NET Frameworks based Mud Codebase Justin Rogers
- ANNC: .NET Frameworks based Mud Codebase Bruce
- ANNC: .NET Frameworks based Mud Codebase szii@sziisoft.com
- ANNC: .NET Frameworks based Mud Codebase Justin Rogers
- ANNC: .NET Frameworks based Mud Codebase szii@sziisoft.com
- Announcing: Pan J C Lawrence
- Announcing: Pan J C Lawrence
- Announcing: Pan Kyndig
- Experience System Differences Alornen
- Experience System Differences Malcolm Tester
- Experience System Differences Hulbert, Leland
- Experience System Differences rayzam
- Experience System Differences Ben Chambers
- Experience System Differences rayzam
- Experience System Differences Ben Chambers
- Experience System Differences Travis Casey
- Experience System Differences Mark Watson
- Experience System Differences rayzam
- Experience System Differences Kindred321@aol.com
- Experience System Differences Hans-Henrik Staerfeldt
- Experience System Differences Brian M. Schkerke
- Experience System Differences Ben Chambers
- Experience System Differences Malcolm Tester
- Experience System Differences Warren Powell
- speaking of symposia... Robert Zubek
- MUD-Dev digest, Vol 1 #281 - 18 msgs Dr. Cat
- MUD-Dev digest, Vol 1 #281 - 18 msgs Jeff Freeman
- I Want to Bake Bread Neeby
- I Want to Bake Bread Richard
- I Want to Bake Bread John Buehler
- I Want to Bake Bread Richard
- I Want to Bake Bread Ryan
- I Want to Bake Bread Patrick Dughi
- I Want to Bake Bread Siobhan Perricone
- I Want to Bake Bread Hal Bonnin
- I Want to Bake Bread Travis Casey
- I Want to Bake Bread John Buehler
- Exploration Exp (was: Experience System Differences) Corey Crawford
- Exploration Exp (was: Experience System Differences) Lord Ashon
- Exploration Exp (was: Experience System Differences) John Buehler
- Exploration Exp (was: Experience System Differences) Philip Loguinov, Draymoor
- Exploration Exp (was: Experience System Differences) nbossett@pierb.com
- Exploration Exp (was: Experience System Differences) Warren Powell
- MUD research, good ideas and designers who care? Ola Fosheim Grøstad
- Baking Bread Lord Ashon
- Baking Bread John Buehler
- Distributed PSW design Stephane Bura
- Distributed PSW design Frank Crowell
- Distributed PSW design Bruce
- Distributed PSW design Stephane Bura
- Distributed PSW design John Buehler
- Distributed PSW design J C Lawrence
- Distributed PSW design Justin Rogers
- Distributed PSW design John Buehler
- Distributed PSW design Eli Stevens
- Distributed PSW design John Buehler
- MUD-Dev digest, Vol 1 #282 - 18 msgs Dr. Cat
- MUD-Dev digest, Vol 1 #282 - 18 msgs Koster, Raph
- IOWA project / Request for addition to FAQ Bruce
- No Exp? (was: Exploration Exp) Corey Crawford
- No Exp? (was: Exploration Exp) John Buehler
- No Exp? (was: Exploration Exp) Hulbert, Leland
- No Exp? (was: Exploration Exp) John Buehler
- No Exp? (was: Exploration Exp) msew
- No Exp? (was: Exploration Exp) John Buehler
- No Exp? (was: Exploration Exp) Travis Casey
- No Exp? (was: Exploration Exp) rayzam
- No Exp? (was: Exploration Exp) Michael Tresca
- No Exp? (was: Exploration Exp) John Buehler
- No Exp? (was: Exploration Exp) msew
- No Exp? (was: Exploration Exp) Michael Tresca
- No Exp? (was: Exploration Exp) Alistair Milne
- No Exp? (was: Exploration Exp) J C Lawrence
- No Exp? (was: Exploration Exp) John Buehler
- No Exp? (was: Exploration Exp) J C Lawrence
- No Exp? (was: Exploration Exp) John Buehler
- No Exp? (was: Exploration Exp) J C Lawrence
- C# Greg Miller
- Player Created Object System Philip Loguinov, Draymoor
- Player Created Object System Richard
- Player Created Object System Philip Loguinov, Draymoor
- Player Created Object System Christopher Allen
- Player Created Object System Richard
- Distributed PSW design (Frank Crowell) Peter Yu
- Distributed PSW design (Frank Crowell) Frank Crowell
- MUD-Dev digest, Vol 1 #282 - 18 msgs Jeff Freeman
- MUD-Dev digest, Vol 1 #282 - 18 msgs J C Lawrence
- MUD-Dev digest, Vol 1 #282 - 18 msgs Jake Song
- Room Generation Nathanael Dermyer
- Room Generation J C Lawrence
- Room Generation George Greer
- Room Generation Bruce
- Room Generation Bruce
- Room Generation Richard
- Room Generation Mordengaard
- Room Generation Kwon Ekstrom
- Room Generation Jon Lambert
- Room Generation Patrick Dughi
- Room Generation Ola Fosheim Grøstad
- Room Generation Travis Casey
- Room Generation Ola Fosheim Grøstad
- Room Generation Eli Stevens
- Room Generation Richard
- Room Generation Richard
- Room Generation Colin Coghill
- Room Generation efindel@earthlink.net
- Room Generation Ryan P.
- Variant Methods for Related Skills Christopher Allen
- Variant Methods for Related Skills Travis Casey
- Anyone know of plans for an I-Mode MUD/LARP? J C Lawrence
- Anyone know of plans for an I-Mode MUD/LARP? Koster, Raph
- Anyone know of plans for an I-Mode MUD/LARP? Ola Fosheim Grøstad
- Anyone know of plans for an I-Mode MUD/LARP? rayzam
- Anyone know of plans for an I-Mode MUD/LARP? Travis Casey
- Anyone know of plans for an I-Mode MUD/LARP? Jon Lambert
- Anyone know of plans for an I-Mode MUD/LARP? Jeff Freeman
- Room and Terrain Integration in Textual Environments vognsen@post10.tele.dk
- Project Entropia the_logos@www.achaea.com
- Project Entropia John Vanderbeck
- Project Entropia Christopher Allen
- Project Entropia J C Lawrence
- Project Entropia J C Lawrence
- Project Entropia John Vanderbeck
- Project Entropia the_logos@www.achaea.com
- Project Entropia Batir
- Project Entropia the_logos@www.achaea.com
- Project Entropia Frank Crowell
- Project Entropia Jessica Mulligan
- Project Entropia Frank Crowell
- Project Entropia Jessica Mulligan
- Project Entropia the_logos@www.achaea.com
- Project Entropia the_logos@www.achaea.com
- MUD-Dev digest, Vol 1 #285 - 32 msgs Dr. Cat
- MUD-Dev digest, Vol 1 #285 - 32 msgs Jeff Freeman
- MUD-Dev digest, Vol 1 #285 - 32 msgs Jake Song
- MUD-Dev digest, Vol 1 #285 - 32 msgs Jeff Freeman
- MUD-Dev digest, Vol 1 #285 - 32 msgs Jake Song
- MUD-Dev digest, Vol 1 #285 - 32 msgs Koster, Raph
- MUD-Dev digest, Vol 1 #285 - 32 msgs Jeff Freeman
- MUD-Dev digest, Vol 1 #285 - 32 msgs Jeff Freeman
- MUD-Dev digest, Vol 1 #285 - 32 msgs Jake Song
- Skill System Kwon Ekstrom
- Skill System Travis Casey
- Skill System justice@softhome.net
- Skill System Ben Chambers
- Skill System Batir
- Skill System Ben Chambers
- Skill System Batir
- Skill System justice@softhome.net
- Long Day's Journey Into Tights J C Lawrence
- MUD-Dev digest, Vol 1 #289 - 8 msgs Dr. Cat
- MUD-Dev digest, Vol 1 #289 - 8 msgs the_logos@www.achaea.com
- MUD-Dev digest, Vol 1 #289 - 8 msgs Hans-Henrik Staerfeldt
- MUD-Dev digest, Vol 1 #289 - 8 msgs Nathan F.Yospe
- MUD-Dev digest, Vol 1 #289 - 8 msgs justice@softhome.net
- MUD-Dev digest, Vol 1 #289 - 8 msgs Dave Rickey
- MUD-Dev digest, Vol 1 #289 - 8 msgs Vincent Archer
- MUD-Dev digest, Vol 1 #289 - 8 msgs msew
- MUD-Dev digest, Vol 1 #289 - 8 msgs Travis Casey
- When Do We Get the "Right" to Privacy? J C Lawrence
- When Do We Get the "Right" to Privacy? Nathan F.Yospe
- When Do We Get the "Right" to Privacy? Koster, Raph
- Cybercafes a fluke? (was: MUD-Dev digest, Vol 1 #289 - 8 msgs) Scion Altera
- Cybercafes a fluke? (was: MUD-Dev digest, Vol 1 #289 - 8 msgs) Holly Sommer
- An interesting concept Richard.Woolcock@rsuk.rohde-schwarz.com
- [iggamedes] WAKE UP! :) Tomb Raider style games? J C Lawrence
- [iggamedes] WAKE UP! :) Tomb Raider style games? Jon Lambert
- Cultural Differences in Gaming and Gamers SavantKnowsAll@cs.com
- Cultural Differences in Gaming and Gamers Koster, Raph
- Cultural Differences in Gaming and Gamers the_logos@www.achaea.com
- System burps and outages J C Lawrence
- Semi Graphical Muds Ben Chambers
- Semi Graphical Muds Peter Yu
- Semi Graphical Muds Christopher Allen
- Semi Graphical Muds the_logos@www.achaea.com
- Semi Graphical Muds Ben Chambers
- Semi Graphical Muds David Loeser
- Semi Graphical Muds Ben Chambers
- Semi Graphical Muds David Loeser
- Semi Graphical Muds the_logos@www.achaea.com
- Semi Graphical Muds Ben Chambers
- Semi Graphical Muds Corey Crawford
- Semi Graphical Muds Kerem HADIMLI
- Semi Graphical Muds Jon Lambert
- Semi Graphical Muds the_logos@www.achaea.com
- Semi Graphical Muds J C Lawrence
- Semi Graphical Muds Ben Chambers
- Semi Graphical Muds Kerem HADIMLI
- Semi Graphical Muds Frank Crowell
- Semi Graphical Muds Ben Chambers
- Semi Graphical Muds Koster, Raph
- Semi Graphical Muds Ben Chambers
- Semi Graphical Muds Caliban Tiresias Darklock
- Semi Graphical Muds Bruce
- Semi Graphical Muds Jay Carlson
- Semi Graphical Muds the_logos@www.achaea.com
- Semi Graphical Muds Jon Lambert
- Semi Graphical Muds J C Lawrence
- Semi Graphical Muds Bruce
- Semi Graphical Muds the_logos@www.achaea.com
- Semi Graphical Muds Bruce
- Semi Graphical Muds Christopher Allen
- Semi Graphical Muds Bruce
- Semi Graphical Muds Felix A. Croes
- Semi Graphical Muds Christopher Allen
- Semi Graphical Muds Felix A. Croes
- Semi Graphical Muds Ben Chambers
- Semi Graphical Muds Bruce
- Semi Graphical Muds David Loeser
- Semi Graphical Muds Marc Bowden
- Semi Graphical Muds Felix A. Croes
- Semi Graphical Muds Bruce
- Semi Graphical Muds Felix A. Croes
- Semi Graphical Muds Adam Casbarian
- Semi Graphical Muds J C Lawrence
- Semi Graphical Muds the_logos@www.achaea.com
- Semi Graphical Muds J C Lawrence
- Semi Graphical Muds Koster, Raph
- Semi Graphical Muds J C Lawrence
- Semi Graphical Muds Koster, Raph
- Semi Graphical Muds the_logos@www.achaea.com
- Semi Graphical Muds J C Lawrence
- Semi Graphical Muds the_logos@www.achaea.com
- Semi Graphical Muds John Buehler
- Semi Graphical Muds Koster, Raph
- Semi Graphical Muds Dave Rickey
- Semi Graphical Muds Hulbert, Leland
- Semi Graphical Muds Dave Rickey
- Semi Graphical Muds geoffrey@yorku.ca
- Semi Graphical Muds the_logos@www.achaea.com
- Semi Graphical Muds rayzam
- Semi Graphical Muds J C Lawrence
- Semi Graphical Muds Sanvean
- Semi Graphical Muds J C Lawrence
- Semi Graphical Muds Tamzen Cannoy
- Semi Graphical Muds J C Lawrence
- Semi Graphical Muds the_logos@www.achaea.com
- Semi Graphical Muds Frank Crowell
- Semi Graphical Muds rayzam
- Semi Graphical Muds the_logos@www.achaea.com
- Semi Graphical Muds rayzam
- Semi Graphical Muds the_logos@www.achaea.com
- Semi Graphical Muds J C Lawrence
- Semi Graphical Muds the_logos@www.achaea.com
- Semi Graphical Muds rayzam
- Semi Graphical Muds the_logos@www.achaea.com
- Semi Graphical Muds Ben Chambers
- Semi Graphical Muds rayzam
- Semi Graphical Muds Kevin Littlejohn
- Semi Graphical Muds J C Lawrence
- Semi Graphical Muds Ben Chambers
- Semi Graphical Muds the_logos@www.achaea.com
- Semi Graphical Muds J C Lawrence
- Semi Graphical Muds Adam Casbarian
- Semi Graphical Muds the_logos@www.achaea.com
- Ebay bans character selling the_logos@www.achaea.com
- Ebay bans character selling susie
- Ebay bans character selling Frank Crowell
- Ebay bans character selling Frank Crowell
- Ebay bans character selling the_logos@www.achaea.com
- Ebay bans character selling Richard.Woolcock@rsuk.rohde-schwarz.com
- Ebay bans character selling Kevin Littlejohn
- Ebay bans character selling Travis Casey
- Ebay bans character selling Hans-Henrik Staerfeldt
- Ebay bans character selling Hans-Henrik Staerfeldt
- Ebay bans character selling rayzam
- Ebay bans character selling John Buehler
- Ebay bans character selling Hans-Henrik Staerfeldt
- Ebay bans character selling Dave Rickey
- Ebay bans character selling Eric Lee {RAT}
- Ebay bans character selling Frank Crowell
- Ebay bans character selling Timothy Dang
- Ebay bans character selling Paul Robinson
- Ebay bans character selling Peter Yu
- Ebay bans character selling Daniel.Harman@barclayscapital.com
- Ebay bans character selling David Kennerly
- Ebay bans character selling Willowreed@aol.com
- Ebay bans character selling Travis Casey
- Ebay bans character selling rayzam
- Ebay bans character selling Jeremy Music
- Ebay bans character selling rayzam
- Ebay bans character selling Yves K
- Ebay bans character selling the_logos@www.achaea.com
- front end clients.....was Semi Graphical Muds Willowreed@aol.com
- front end clients.....was Semi Graphical Muds Frank Crowell
- front end clients.....was Semi Graphical MUDs Christopher Allen
- Meta-gaming: (real <--> game) transfers David Kennerly
- EverQuest Study Dave Rickey
- [pol-core-test] New file uploaded to pol-core-test (OT) Jeff Freeman
- [pol-core-test] New file uploaded to pol-core-test (OT) the_logos@www.achaea.com
- [pol-core-test] New file uploaded to pol-core-test(OT) Dave Rickey
- [pol-core-test] New file uploaded to pol-core-test(OT) Valerio Santinelli
- [pol-core-test] New file uploaded to pol-core-test(OT) Frank Crowell
- PvP Systems John Buehler
- PvP Systems Jon Lambert
- PvP Systems the_logos@www.achaea.com
- PvP Systems Federico Di Gregorio
- PvP Systems John Buehler
- PvP Systems gmiller@classic-games.com
- PvP Systems John Buehler
- PvP systems Greg Miller
- PvP systems John Buehler
- PvP systems gmiller@classic-games.com
- PvP systems John Buehler
- PvP systems gmiller@classic-games.com
- PvP systems John Buehler
- PvP systems gmiller@classic-games.com
- PvP systems the_logos@www.achaea.com
- PvP systems J C Lawrence
- PvP systems the_logos@www.achaea.com
- PvP systems J C Lawrence
- PvP systems the_logos@www.achaea.com
- PvP systems the_logos@www.achaea.com
- PvP systems Dave Turner
- PvP systems gmiller@classic-games.com
- PvP systems the_logos@www.achaea.com
- PvP systems S. Patrick Gallaty
- PvP systems the_logos@www.achaea.com
- PvP Systems Federico Di Gregorio
- PvP Systems John Buehler
- PvP Systems the_logos@www.achaea.com
- PvP Systems John Buehler
- PvP Systems Jake Song
- PvP Systems the_logos@www.achaea.com
- PvP Systems John Buehler
- PvP Systems the_logos@www.achaea.com
- PvP Systems John Buehler
- PvP Systems the_logos@www.achaea.com
- PvP Systems Corey Crawford
- PvP Systems Jon Lambert
- PvP Systems John Buehler
- PvP Systems Jon Lambert
- PvP Systems John Buehler
- PvP Systems Sanvean
- PvP Systems J C Lawrence
- PvP Systems John Buehler
- PvP Systems J C Lawrence
- PvP Systems John Buehler
- PvP Systems J C Lawrence
- PvP Systems John Buehler
- PvP Systems J C Lawrence
- PvP Systems the_logos@www.achaea.com
- PvP Systems J C Lawrence
- PvP Systems Michael Tresca
- PvP Systems John Buehler
- PvP Systems Jon Lambert
- PvP Systems John Buehler
- PvP Systems Travis Casey
- PvP Systems the_logos@www.achaea.com
- PvP Systems Kerem HADIMLI
- PvP Systems the_logos@www.achaea.com
- PvP Systems The Druid
- PvP Systems rayzam
- PvP Systems John Buehler
- PvP Systems msew
- PvP Systems Koster, Raph
- PvP Systems msew
- PvP Systems msew
- PvP Systems John Buehler
- PvP Systems msew
- PvP Systems Vincent Archer