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
  • • An Idea... Mud Development Framework Jeremy Lowery
      <EdNote: Quote severely trimmed.>
      
      ----- Original Message -----
      From: "Bruce" <bruce@puremagic.com>
      To: <mud-dev@kanga.nu>
      Sent: Sunday, January 14, 2001 3:32 AM
      Subject: Re: [MUD-Dev] An Idea... Mud Development Framework
      
      > Jeremy Lowery wrote:
      
      > > 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?
      
      
      C++ objects
      
      > What happens when (not if) someone puts the wrong data into
      > ofrdb.mlib?
      >
      
      All files will be put through a tokenizer/lexical analysier before
      they are introduced into the system.
      
      > What are the virtual index numbers used for? (Why are they
      > virtual?)
      
      The initial idea behind the virtual index numbers is a way to handle
      dangling pointers. Since poiners are (in a way) a unique key.
      
      > Can you have multiple object factories?
      
      In a sense, yes. I haven't decided whether to have a set of base
      objects definitions and have class factories associated with each base
      class, or to make the object system completely dynamic, therefore all
      objects would be created from the same object factory, based off of an
      "object template" type mechanism.
      
      > > 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?
      
      All objects will have an independant saving mechanism based off of
      file streams, there will be integrity tests for objects referenced in
      more than one place, etc.
      
      > > 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?
      
      Haven't thought of this :)
      
      > > 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'?
      
      A bad use of the word parse :) System message will be numeric
      constants
      
      > > 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.
      
      A lot of the bases I have seen have builder ports. By not having
      explicitit binding of conenctions to character objects, connections
      can be bound to other "builder type" objects.
      
      > > 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?
      
      Yes, all objects would have default message handling abilities.
      Ideally, all objects must implement functions to execute manditory
      system messages (such as Save)
      
      
      > > 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?
      
      Well, generally objects "die" when they are destroyed inside the game,
      or if a client has the object, when the client closes its connection.
      
      > 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.
      
      
      One technology that I"ve been looking into can do something very
      similar. It's called Active Scripting. The idea would be to define a
      a set of COM Servers that expose pragmatic interfaces to script. A
      client would initialize base services, the loading sequence, and
      instantaniate the runtime. Core system scripts (such as object
      definition, command interfaces, etc) would be compiled into the
      program on initialization for speed. Of course, scripts could be
      compiled into the server during runtime as well. The easy way out
      would to add references to the scripts that are to be compiled into
      the server at runtime. On loading, all compiled scripts with
      references would be compiled into the server. You could get a bit
      fancier by actually extended the server with the scripts as "patches."
      For other scripts, a script cache would be set up for speed. The COM
      Servers would expose objects static objects such as Server, Database,
      Runtime, as well as building Servers such as ObjectBuilders and things
      of this nature.
      
      Scripts could be written in any language that has an ActiveX Script
      Server Component Registered on the system. Such as VBScript, Python,
      JScript, Perl, and LISP, completely depending on the programmers
      preference and the Interfaces that Language Components provide .
      
      Jeremy
    • • An Idea... Mud Development Framework Bruce
      • An Idea... Mud Development Framework Miroslav Silovic
      • • An Idea... Mud Development Framework Bruce
  • 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
    • • Server stability (was: Player statistics) Klara
• 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
    • • Exploration Exp (was: Experience System Differences) rayzam
      • • Exploration Exp (was: Experience System Differences) Justin Rogers
• 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 Bruce
  • 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
• • Room and Terrain Integration in Textual Environments Bruce
• 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 Neeby
  • 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