April 1998

• Persistant storage.... My current idea. J C Lawrence
• • Persistant storage.... My current idea. J C Lawrence
  • Persistant storage.... My current idea. Chris Gray
  • • Persistant storage.... My current idea. J C Lawrence
    • • Persistant storage.... My current idea. J C Lawrence
• OT: This is a test of a system config change. coder@ibm.net
• MUD Development Digest Dr. Cat
• • MUD Development Digest Justin McKinnerney
  • • MUD Development Digest Nathan F Yospe
    • • MUD Development Digest Justin McKinnerney
      • • MUD Development Digest J C Lawrence
    • MUD Development Digest J C Lawrence
    • • MUD Development Digest Jon A. Lambert
  • MUD Development Digest Chris Gray
  • MUD Development Digest J C Lawrence
  • • MUD Development Digest J C Lawrence
  • MUD Development Digest J C Lawrence
  • • MUD Development Digest Ben Greear
    • • MUD Development Digest Jon A. Lambert
      • MUD Development Digest Chris Gray
      • • MUD Development Digest Ben Greear
        • • MUD Development Digest Dr. Cat
          • • MUD Development Digest Ben Greear
            • MUD Development Digest Justin McKinnerney
            • • MUD Development Digest Dr. Cat
              • • MUD Development Digest Justin McKinnerney
                  > -----Original Message-----
                  > From: Petidomo List Agent,,,, [mailto:petidomo@kanga.nu]On Behalf Of Dr.
                  > Cat
                  > Sent: Friday, April 24, 1998 6:31 PM
                  > To: mud-dev@kanga.nu
                  > Subject: [MUD-Dev] Re: MUD Development Digest
                  >
                  > [stuff deleted]
                  >
                  >> As a rule of thumb, on pretty much ANY O/S, you really don't want to have
                  >> more than 1/3 your memory be in swap.
                  >
                  > We are in agreement here, but I'd go farther and say zero percent is what
                  > I really want. As J. C. pointed out, I may have to look around for a
                  > Unix that doesn't assume things should be swapped out even when there's a
                  > surplus of RAM - or at least one that can be tweaked to act that way.
                  
                  You could always run without swap under Linux and (I believe) Solaris.
                  
                  While this raises a lot of red flags - if you are the only person running on
                  the system, and you are pretty sure that the only real process on the system
                  is your game server (no sendmail, no ftp, etc), then go for it.
                  
                  Swap was always meant to prevent the system from going down due to physical
                  memory running out and meant as a convineance to agument the price of memory
                  (which isn't so much an issue as it used to be). It was obviously never
                  intended as a source pool for physical memory as this is not what the
                  hardware was intended for. :)
                  
                  > If I had any interest in setting up a game with thousands of simultaneous
                  > users that generated no revenue, I'm sure I'd rush right out and study up
                  > on all the latest data structures and memory management techniques. For
                  > now I'll stay mostly with my old friend the array. Kinda like I used in
                  > BASIC in 1978, only with more datatypes available. :X) They're not
                  > elegant and beautiful and graceful like triple-sideways-linked-lists of
                  > handles to structures... But like an old reliable car, or an old
                  > reliable horse, they get the job done. We've got about 400,000 player
                  > hours logged on our server now so far, and it's rolling along pretty
                  > smoothly most of the time.
                  
                  Everything is relative to scope.
                  
                  It is very easy to start a project with your mentality, and then deal with
                  issues as you run into them. This approach is not uncommon when it comes to
                  multi-user games in general.
                  
                  However, to start a project and say "I want >this< to be possible" is to set
                  your limits. If you plan on supporting up to 100,000 players, do the math,
                  figure out what your game would be like if that happened, figure out every
                  worst case scenario. Then ask yourself if your code is truly up to it.
                  
                  Yes, you can rely on technology advancing to a certain extent - but the game
                  that handles 100,000 players on current technology elegantly will most
                  certainly do so in the future. No one ever got bitten for having a game that
                  ran smoothly on a LOWER platform than one would expect.
                  
                  ----
                  
                  As I progress my own (extremely slow-going) game, I find myself following a
                  similar development path as Java. Though my goals are disctinctively
                  diffrent (My bytecode is not intended to be portable), several concepts
                  inherit to modular coding seem to be popping up as cominalities between Java
                  and my own bytecode.
                  
                  Bytecode could easily be dubbed a "fancy" proceedure. Why do it? Simply
                  put - Extendability. I want to be able to change fundamental game concepts
                  in areas as I wish, on the fly, and without rebooting the game.
                  
                  Many MU*s currently do this. But most of them do it via realtime
                  interpreters. While this isn't a major CPU load, per-se, it does take up
                  data space in the processor cache, so you're pretty much guarenteed more
                  cache misses than if using bytecode for the same proceedure. (And, of
                  course, the natural cycle savings on not having to parse every time
                  something is executed).
                  
                  So, in the end, my point would be that all "fancy" coding is directly
                  related to your goals. And if you intended to be a comertial server, once
                  you are out of beta you are not allowed the luxury of making so many major
                  code changes. So the best solution would be adaptable code.
                  
                  > P.S. The real trick is figuring out what parts would contribute the most
                  > towards "making the game fun", and then *only* implementing those parts.
                  > If you take any other approach, odds are good you'll never get your game
                  > done - indeed, most people that try to make a game never do get one done.
                  
                  I totally agree.
                  
                  Game design is very, very important. Far more important than implementation.
                  
                  However, you can take for granted certain hurtles in implmentation.
                  
                  Case: I want a server that is capable of running under Linux.
                  
                  Problem: Linux inheritly has a hard limit of 256 file handles per-process,
                  and I do not want to hack the kernel (even though it's just chaning one
                  #define it's still bad idea in general) on every machine I have a server
                  running on.
                  
                  Granted: I need code to get around the 256 limit.
                  
                  That case is a physical limit problem. There are other effency problems that
                  are generally a good idea to work around at first and would not hurt you in
                  the end to have worked around.
                  
                  In a few cases, this includes having the ability to adjust a server to
                  whatever technology it uses (such as the memory/swap issue - having an
                  adjustable memory cache with a "fancy" caching algorithm).
                  
                  These problems can be mutually exclusive of the game design itself (256
                  limit), or while they can be mutually exclusive (dbase solution to
                  memory/swap), it may actualy be better for such things to revolve around
                  game specific information which can only be supplied by the design (specific
                  caching implmentation will always be FAR more efficent than a general DBM or
                  ODBMS).
                  
                  If you possess the ability/time/resources to, it never hurts to shoot for a
                  goal that is beoynd what you think will actually happen. Because if it does
                  happen, everyone involved will be happy you did, and guarenteed, someone
                  will be unhappy that you didn't make your goals *higher*! :)
                  
                  - Justin -
                  
                  
                  --
                  MUD-Dev: Advancing an unrealised future.
                • • MUD Development Digest Dr. Cat
                  • • MUD Development Digest J C Lawrence
                    • • MUD Development Digest Matt Chatterley
  • MUD Development Digest J C Lawrence
• GRUMPS maddog@best.com
• • GRUMPS Chris Gray
  • • GRUMPS maddog@best.com
    • • GRUMPS Chris Gray
      • GRUMPS J C Lawrence
      • • GRUMPS maddog@best.com
        • • GRUMPS J C Lawrence
          • • GRUMPS maddog@best.com
            • GRUMPS s001gmu@nova.wright.edu
            • • GRUMPS Joel Dillon
        • GRUMPS Shawn Halpenny
  • GRUMPS Travis Casey
  • • GRUMPS maddog@best.com
    • GRUMPS Brandon J. Rickman
    • • GRUMPS Travis Casey
      • GRUMPS maddog@best.com
  • GRUMPS J C Lawrence
  • • GRUMPS maddog@best.com
    • • GRUMPS J C Lawrence
      • • GRUMPS Vadim Tkachenko
  • GRUMPS J C Lawrence
• caved in: Algorithms for for storing free space. Ben Greear
• • caved in: Algorithms for for storing free space. Cimri
  • caved in: Algorithms for for storing free space. Chris Gray
  • • caved in: Algorithms for for storing free space. Ben Greear
  • caved in: Algorithms for for storing free space. J C Lawrence
• internet connections Chris Gray
• GRUPMS? Vadim Tkachenko
• [Fwd: MUD-Dev] Richard Woolcock
• • [Fwd: MUD-Dev] Nathan F Yospe
  • • [Fwd: MUD-Dev] coder@ibm.net
    • • [Fwd: MUD-Dev] Katrina McClelan
    • [Fwd: MUD-Dev] Richard Woolcock
    • [Fwd: MUD-Dev] J C Lawrence
  • [Fwd: MUD-Dev] Travis S. Casey
  • • [Fwd: MUD-Dev] maddog@best.com
    • • [Fwd: MUD-Dev] J C Lawrence
      • • [Fwd: MUD-Dev] J C Lawrence
    • [Fwd: MUD-Dev] Jon A. Lambert
  • [Fwd: MUD-Dev] Richard Woolcock
• Meta: who dat guy, wot dat web? coder@ibm.net
• • Meta: who dat guy, wot dat web? Katrina McClelan
  • Meta: who dat guy, wot dat web? s001gmu@nova.wright.edu
  • • Meta: who dat guy, wot dat web? J C Lawrence
  • Meta: who dat guy, wot dat web? Jon A. Lambert
  • • Meta: who dat guy, wot dat web? J C Lawrence
• [META] Mailing lists Katrina McClelan
• • [META] Mailing lists Travis S. Casey
• META: The web presence and wot it ain't gonna be J C Lawrence
• • META: The web presence and wot it ain't gonna be Shawn Halpenny
  • • META: The web presence and wot it ain't gonna be J C Lawrence
• META: The web presence and wot it ain't gonna be J C Lawrence
• (fwd) code for teleport coder@ibm.net
• • (fwd) code for teleport Ben Greear
  • • (fwd) code for teleport s001gmu@nova.wright.edu
    • • (fwd) code for teleport J C Lawrence
• META: Archive of Megami/Wout's list's traffic? Archive of the CC: list? J C Lawrence
• Resisting Charm or you're cute and nice, but not to die for. Jon A. Lambert
• • Resisting Charm or you're cute and nice, but not to die for. s001gmu@nova.wright.edu
  • Resisting Charm or you're cute and nice, but not to die for. Katrina McClelan
  • Resisting Charm or you're cute and nice, but not to die for. J C Lawrence
• Genetic Algorithms Jon A. Lambert
• MUD Development Digest J C Lawrence
• • MUD Development Digest Alex Oren
  • • MUD Development Digest Chris Gray
    • • MUD Development Digest Jon Leonard
      • MUD Development Digest Jon A. Lambert
• Resisting Charm or you're cute and nice, but not Jon A. Lambert
• Unreal J C Lawrence
• • Unreal Koster, Raph
  • • Unreal J C Lawrence
  • Unreal Jon A. Lambert
  • • Unreal Matt Chatterley
• META: The web archives are up for review (alpha 1) J C Lawrence
• META: Archive of Megami/Wout's list's traffic? Archive of Alex Oren
• RGMA Alex Oren
• • RGMA Katrina McClelan
  • RGMA Marian Griffith
  • • RGMA Katrina McClelan
• META: That bloke Yaltec. Khan one
• • META: That bloke Yaltec. J C Lawrence
• a fruitful exchange on classlessness in r.g.m.admin Cimri
• • a fruitful exchange on classlessness in r.g.m.admin Ben Greear
• MAGE 2 MAGE v. 0.88 J C Lawrence
• META: membership (was a fruitful exchange on classlessness in r.g.m.admin) coder@ibm.net
• • META: membership (was a fruitful exchange on classlessness in r.g.m.admin) Ben Greear
• META: Archive of Megami/Wout's list's traffic? Archive of Wout Mertens
• (fwd) Development of new code base coder@ibm.net
• Seductions of Sim: Policy as a Simulation Jon A. Lambert
• • Seductions of Sim: Policy as a Simulation J C Lawrence
• META: membership (was a fruitful exchange on clas Jon A. Lambert
• Resisting Charm or you're cute and nice, but not t Jon A. Lambert
• META: Web futures and the demise of MUD civilisation as we know it. coder@ibm.net
• There can be.. only ONE! Matt Chatterley
• • There can be.. only ONE! Caliban Tiresias Darklock
  • • There can be.. only ONE! Matt Chatterley
  • There can be.. only ONE! J C Lawrence
  • • There can be.. only ONE! Richard Woolcock
    • • There can be.. only ONE! J C Lawrence
      • • There can be.. only ONE! Vadim Tkachenko
      • There can be.. only ONE! Jon A. Lambert
      • There can be.. only ONE! Vadim Tkachenko
      • • There can be.. only ONE! Jon A. Lambert
        • • There can be.. only ONE! Richard Woolcock
        • There can be.. only ONE! J C Lawrence
      • There can be.. only ONE! Matt Chatterley
    • There can be.. only ONE! Matt Chatterley
    • • There can be.. only ONE! J C Lawrence
      • • There can be.. only ONE! Matt Chatterley
        • • There can be.. only ONE! J C Lawrence
          • • There can be.. only ONE! Ling
            • • There can be.. only ONE! Matt Chatterley
              • There can be.. only ONE! J C Lawrence
            • There can be.. only ONE! Matt Chatterley
            • • There can be.. only ONE! J C Lawrence
          • There can be.. only ONE! J C Lawrence
• OT: Caballah [was Character development] Alex Oren
• • OT: Caballah [was Character development] Caliban Tiresias Darklock
  • • OT: Caballah [was Character development] Vadim Tkachenko
  • OT: Caballah [was Character development] Vadim Tkachenko
  • • OT: Caballah [was Character development] Marian Griffith
    • • OT: Caballah [was Character development] Jon A. Lambert
• Personality modelling Oliver Jowett
• • Personality modelling J C Lawrence
  • • Personality modelling J C Lawrence
• META: membership Holly Sommer
• • META: membership Cimri
  • META: membership s001gmu@nova.wright.edu
  • • META: membership Katrina McClelan
• META: Other mailing lists Alex Oren
• • META: Other mailing lists J C Lawrence
• META: Web site backgrounds and readability J C Lawrence
• • META: Web site backgrounds and readability Cimri
  • META: Web site backgrounds and readability Holly Sommer
  • META: Web site backgrounds and readability plateau
  • META: Web site backgrounds and readability Vadim Tkachenko
  • • META: Web site backgrounds and readability Caliban Tiresias Darklock
    • • META: Web site backgrounds and readability Vadim Tkachenko
  • META: Web site backgrounds and readability Greg Munt
  • • META: Web site backgrounds and readability J C Lawrence
    • • META: Web site backgrounds and readability Caliban Tiresias Darklock
    • META: Web site backgrounds and readability Matt Chatterley
  • META: Web site backgrounds and readability Holly Sommer
  • META: Web site backgrounds and readability Jon A. Lambert
  • • META: Web site backgrounds and readability Caliban Tiresias Darklock
  • META: Web site backgrounds and readability Jon A. Lambert
  • • META: Web site backgrounds and readability J C Lawrence
• META: Archive message format J C Lawrence
• (fwd) equipment J C Lawrence
• 3D evaluation? J C Lawrence
• META: Archive searching now works... J C Lawrence
• • META: Archive searching now works... Bruce Mitchener
  • • META: Archive searching now works... J C Lawrence
• Fw: [DESIGN] Combat system Richard Woolcock
• [Fwd: Grids and curvature of a sphere] Richard Woolcock
• • [Fwd: Grids and curvature of a sphere] Caliban Tiresias Darklock
  • • [Fwd: Grids and curvature of a sphere] J C Lawrence
  • [Fwd: Grids and curvature of a sphere] J C Lawrence
• SfD: AI and muds; several approaches Nathan F Yospe
• META: We have moved. J C Lawrence
• (fwd) Mudlib Design J C Lawrence
• (fwd) SERVER: New Code Base in VB Started J C Lawrence
• • (fwd) SERVER: New Code Base in VB Started Jon A. Lambert
• Graphical MUD project (Sea Of Blood) J C Lawrence
• (fwd) Sea of Blood Graphical MUD J C Lawrence
• MAPPING: Creating a bitmaped graphic from map coordinates John Bertoglio
• • MAPPING: Creating a bitmaped graphic from map coordinates Nathan F Yospe
  • • MAPPING: Creating a bitmaped graphic from map coordinates John Bertoglio
    • • MAPPING: Creating a bitmaped graphic from map coordinates s001gmu@nova.wright.edu
  • MAPPING: Creating a bitmaped graphic from map coordinates Jon Leonard
  • MAPPING: Creating a bitmaped graphic from map coordinates Caliban Tiresias Darklock
  • MAPPING: Creating a bitmaped graphic from map coordinates J C Lawrence
  • • MAPPING: Creating a bitmaped graphic from map coordinates Vadim Tkachenko
• Gentle Reminder J C Lawrence
• Systems you use Ling
• • Systems you use Caliban Tiresias Darklock
  • Systems you use J C Lawrence
  • Systems you use Adam Wiggins
  • Systems you use Jon A. Lambert
  • Systems you use Katrina McClelan
  • • Systems you use J C Lawrence
    • • Systems you use Katrina McClelan
• (fwd) CODE RELEASE: [client] Jcrossclient - java client to "crossfire" J C Lawrence
• Teamwork Ling
• • Teamwork J C Lawrence
• MAPPING: Creating a bitmaped graphic from map Jon A. Lambert
• • MAPPING: Creating a bitmaped graphic from map J C Lawrence
  • • MAPPING: Creating a bitmaped graphic from map Jon A. Lambert
    • • MAPPING: Creating a bitmaped graphic from map John Bertoglio
• MAPPING: Creating a bitmaped graphic from map Jon A. Lambert
• MAPPING: Creating a bitmaped graphic from map Caliban Tiresias Darklock
• • MAPPING: Creating a bitmaped graphic from map Jon A. Lambert
• (fwd) AD: [custom graphical] whitestar Crossfire MUD J C Lawrence
• • (fwd) AD: [custom graphical] whitestar Crossfire MUD Dr. Cat
  • • (fwd) AD: [custom graphical] whitestar Crossfire MUD Ben Greear
    • • (fwd) AD: [custom graphical] whitestar Crossfire MUD Matt Chatterley
    • (fwd) AD: [custom graphical] whitestar Crossfire MUD Chris Gray
  • (fwd) AD: [custom graphical] whitestar Crossfire MUD Dr. Cat
  • • (fwd) AD: [custom graphical] whitestar Crossfire MUD J C Lawrence
    • • (fwd) AD: [custom graphical] whitestar Crossfire MUD Jay Sax
      • (fwd) AD: [custom graphical] whitestar Crossfire MUD Dr. Cat
      • • (fwd) AD: [custom graphical] whitestar Crossfire MUD Caliban Tiresias Darklock
        • (fwd) AD: [custom graphical] whitestar Crossfire MUD J C Lawrence
        • • (fwd) AD: [custom graphical] whitestar Crossfire MUD Koster, Raph
          • • (fwd) AD: [custom graphical] whitestar Crossfire MUD Jay Sax
            • (fwd) AD: [custom graphical] whitestar Crossfire MUD Adam Wiggins
      • (fwd) AD: [custom graphical] whitestar Crossfire MUD Matt Chatterley
  • (fwd) AD: [custom graphical] whitestar Crossfire MUD Chris Gray
• There can be.. only ONE! (fwd) Matt Chatterley
• • There can be.. only ONE! (fwd) J C Lawrence
  • • There can be.. only ONE! (fwd) Matt Chatterley
    • • There can be.. only ONE! (fwd) Adam Wiggins
      • • There can be.. only ONE! (fwd) Matt Chatterley
        • There can be.. only ONE! (fwd) J C Lawrence
      • There can be.. only ONE! (fwd) J C Lawrence
      • • There can be.. only ONE! (fwd) Matt Chatterley
• There can be.. only ONE! (fwd) Matt Chatterley
• • There can be.. only ONE! (fwd) J C Lawrence
• There can be.. only ONE! (fwd) Matt Chatterley
• • There can be.. only ONE! (fwd) J C Lawrence
  • • There can be.. only ONE! (fwd) Matt Chatterley
    • • There can be.. only ONE! (fwd) Jon A. Lambert
      • There can be.. only ONE! (fwd) J C Lawrence
      • • There can be.. only ONE! (fwd) Matt Chatterley
• How to represent a 3d object... Ben Greear
• • How to represent a 3d object... Oliver Jowett
  • • How to represent a 3d object... Ben Greear
  • How to represent a 3d object... Justin McKinnerney
  • How to represent a 3d object... J C Lawrence
• fwd Room descriptions, was Roleplaying John Bertoglio
• • fwd Room descriptions, was Roleplaying Chris Gray
  • fwd Room descriptions, was Roleplaying Ling
  • fwd Room descriptions, was Roleplaying J C Lawrence
• Room descriptions, was Roleplaying Richard Woolcock
• • Room descriptions, was Roleplaying John Bertoglio
• Java for Mud Client (Crossfire MUD topic) Justin McKinnerney
• • Java for Mud Client (Crossfire MUD topic) Joel Dillon
  • • Java for Mud Client (Crossfire MUD topic) Justin McKinnerney
    • • Java for Mud Client (Crossfire MUD topic) Joel Dillon
      • • Java for Mud Client (Crossfire MUD topic) s001gmu@nova.wright.edu
        • • Java for Mud Client (Crossfire MUD topic) J C Lawrence
        • Java for Mud Client (Crossfire MUD topic) J C Lawrence
      • Java for Mud Client (Crossfire MUD topic) Ben Greear
    • Java for Mud Client (Crossfire MUD topic) J C Lawrence
• META: mud-dev@null.net is now decommissioned. J C Lawrence
• • META: mud-dev@null.net is now decommissioned. John Bertoglio
  • META: mud-dev@null.net is now decommissioned. J C Lawrence
• Group mechanics/Leadership [was: Room descriptions] Shawn Halpenny
• • Group mechanics/Leadership [was: Room descriptions] John Bertoglio
• (fwd) [DESIGN] Macro semi-language J C Lawrence
• • (fwd) [DESIGN] Macro semi-language J C Lawrence
• (fwd) POLL: Games ruined by bad players (Player killers, tank rushers etc) J C Lawrence
• • (fwd) POLL: Games ruined by bad players (Player killers, tank rushers etc) Dr. Cat
  • (fwd) POLL: Games ruined by bad players (Player killers, tank rushers etc) Marian Griffith
  • (fwd) POLL: Games ruined by bad players (Player killers, tank rushers etc) J C Lawrence
  • • (fwd) POLL: Games ruined by bad players (Player killers, tank rushers etc) Chris Gray
    • • (fwd) POLL: Games ruined by bad players (Player killers, tank rushers etc) Koster, Raph
      • • (fwd) POLL: Games ruined by bad players (Player killers, tank rushers etc) Marian Griffith
        • • (fwd) POLL: Games ruined by bad players (Player killers, tank rushers etc) Koster, Raph
          • • (fwd) POLL: Games ruined by bad players (Player killers, tank rushers etc) Dr. Cat
            • • (fwd) POLL: Games ruined by bad players (Player killers, tank rushers etc) Adam Wiggins
      • (fwd) POLL: Games ruined by bad players (Player killers, tank rushers etc) Adam Wiggins
      • • (fwd) POLL: Games ruined by bad players (Player killers, tank rushers etc) Chris Gray
      • (fwd) POLL: Games ruined by bad players (Player killers, tank rushers etc) J C Lawrence
• OT: Birth announcement Koster, Raph
• • OT: Birth announcement Nathan F Yospe
  • OT: Birth announcement J C Lawrence
  • • OT: Birth announcement J C Lawrence
    • • OT: Birth announcement John Bertoglio
      • • OT: Birth announcement J C Lawrence
  • OT: Birth announcement Jon A. Lambert
  • • OT: Birth announcement Koster, Raph
• (fwd) POLL: Games ruined by bad players (Playe Jon A. Lambert
• • (fwd) POLL: Games ruined by bad players (Playe Dr. Cat
  • • (fwd) POLL: Games ruined by bad players (Playe J C Lawrence
    • • (fwd) POLL: Games ruined by bad players (Playe Dr. Cat
      • • (fwd) POLL: Games ruined by bad players (Playe J C Lawrence
      • (fwd) POLL: Games ruined by bad players (Playe Richard Woolcock
• Some thoughts on languages and users - was: Macro semi Jon A. Lambert
• • Some thoughts on languages and users - was: Macro semi Chris Gray
• PK's: A solution? John Bertoglio
• • PK's: A solution? Shawn Halpenny
  • • PK's: A solution? Michael Hohensee
    • • PK's: A solution? s001gmu@nova.wright.edu
      • PK's: A solution? J C Lawrence
  • PK's: A solution? Katrina McClelan
  • • PK's: A solution? John Bertoglio
    • PK's: A solution? Holly Sommer
  • PK's: A solution? J C Lawrence
  • • PK's: A solution? John Bertoglio
• META: Membership authentication J C Lawrence
• (fwd) MOB or player? Global Communications on Muds J C Lawrence
• • (fwd) MOB or player? Global Communications on Muds John Bertoglio
• (fwd) Confusing? J C Lawrence
• • (fwd) Confusing? Chris Gray
• (fwd) POLL: Games ruined by bad players (Player killers, tank rushers etc) J C Lawrence
• PK and my "Mobless MUD" idea Jay Sax
• • PK and my "Mobless MUD" idea Caliban Tiresias Darklock
  • • PK and my "Mobless MUD" idea John Bertoglio
    • PK and my "Mobless MUD" idea Chris Gray
    • PK and my "Mobless MUD" idea Ling
    • PK and my "Mobless MUD" idea J C Lawrence
    • • PK and my "Mobless MUD" idea Adam Wiggins
      • • PK and my "Mobless MUD" idea J C Lawrence
        • • PK and my "Mobless MUD" idea Adam Wiggins
          • • PK and my "Mobless MUD" idea Marian Griffith
      • PK and my "Mobless MUD" idea Dr. Cat
      • • PK and my "Mobless MUD" idea Koster, Raph
        • • PK and my "Mobless MUD" idea Dr. Cat
          • • PK and my "Mobless MUD" idea Jon A. Lambert
            • • PK and my "Mobless MUD" idea Dr. Cat
              • PK and my "Mobless MUD" idea J C Lawrence
            • PK and my "Mobless MUD" idea Koster, Raph
            • • PK and my "Mobless MUD" idea Marian Griffith
              • PK and my "Mobless MUD" idea Dr. Cat
              • • PK and my "Mobless MUD" idea John Bertoglio
                • • PK and my "Mobless MUD" idea Dr. Cat
                  • • PK and my "Mobless MUD" idea Marian Griffith
                    • • PK and my "Mobless MUD" idea Dr. Cat
                      • • PK and my "Mobless MUD" idea Adam Wiggins
                        • • PK and my "Mobless MUD" idea J C Lawrence
                  • PK and my "Mobless MUD" idea J C Lawrence
                  • • PK and my "Mobless MUD" idea John Bertoglio
                    • • PK and my "Mobless MUD" idea J C Lawrence
                      • • PK and my "Mobless MUD" idea Marian Griffith
                        • • PK and my "Mobless MUD" idea J C Lawrence
                          • • PK and my "Mobless MUD" idea Alex Oren
                    • PK and my "Mobless MUD" idea Jon A. Lambert
            • PK and my "Mobless MUD" idea J C Lawrence
          • PK and my "Mobless MUD" idea J C Lawrence
          • • PK and my "Mobless MUD" idea John Bertoglio
            • • PK and my "Mobless MUD" idea Dr. Cat
              • • PK and my "Mobless MUD" idea John Bertoglio
                • • PK and my "Mobless MUD" idea s001gmu@nova.wright.edu
                  • PK and my "Mobless MUD" idea J C Lawrence
            • PK and my "Mobless MUD" idea Adam Wiggins
            • • PK and my "Mobless MUD" idea J C Lawrence
              • • PK and my "Mobless MUD" idea Adam Wiggins
        • PK and my "Mobless MUD" idea Adam Wiggins
        • PK and my "Mobless MUD" idea Marian Griffith
        • • PK and my "Mobless MUD" idea Koster, Raph
        • PK and my "Mobless MUD" idea J C Lawrence
  • PK and my "Mobless MUD" idea Caliban Tiresias Darklock
  • • PK and my "Mobless MUD" idea John Bertoglio
    • • PK and my "Mobless MUD" idea Caliban Tiresias Darklock
      • PK and my "Mobless MUD" idea J C Lawrence
  • PK and my "Mobless MUD" idea John Bertoglio
  • • PK and my "Mobless MUD" idea J C Lawrence
    • • PK and my "Mobless MUD" idea Adam Wiggins
      • • PK and my "Mobless MUD" idea Marian Griffith
      • PK and my "Mobless MUD" idea John Bertoglio
• META: Mail archives and MIME attachments J C Lawrence
• • META: Mail archives and MIME attachments Jon A. Lambert
• Bio of John Bertoglio J C Lawrence
• Reuters: Cheaters Never Prosper J C Lawrence
• Correction s001gmu@nova.wright.edu
• Supporting articles found for UOL play style J C Lawrence
• • Supporting articles found for UOL play style John Bertoglio
  • • Supporting articles found for UOL play style J C Lawrence
    • • Supporting articles found for UOL play style John Bertoglio
      • • Supporting articles found for UOL play style Koster, Raph
        • • Supporting articles found for UOL play style J C Lawrence
  • Supporting articles found for UOL play style Koster, Raph
• Mud-Client, and specifically, COOLMud and SFWhite Jay Sax
• • Mud-Client, and specifically, COOLMud and SFWhite Dan Root
  • Mud-Client, and specifically, COOLMud and SFWhite J C Lawrence
• regulating player-created objects Dan Shiovitz
• • regulating player-created objects Adam Wiggins
  • • regulating player-created objects Dan Shiovitz
    • • regulating player-created objects Adam Wiggins
      • • regulating player-created objects s001gmu@nova.wright.edu
        • regulating player-created objects Brandon J. Rickman
        • • regulating player-created objects Marian Griffith
          • • regulating player-created objects Brandon J. Rickman
          • regulating player-created objects Adam Wiggins
          • • regulating player-created objects Brandon J. Rickman
            • • regulating player-created objects Adam Wiggins
              • • regulating player-created objects Brandon J. Rickman
                • • regulating player-created objects Adam Wiggins
      • regulating player-created objects Nathan F Yospe
    • regulating player-created objects Nathan F Yospe
  • regulating player-created objects Nathan F Yospe
  • • regulating player-created objects Dan Shiovitz
    • • regulating player-created objects Shawn Halpenny
      • regulating player-created objects J C Lawrence
  • regulating player-created objects J C Lawrence
  • • regulating player-created objects John Bertoglio
• atomic functions Felix A. Croes
• • atomic functions Shawn Halpenny
  • • atomic functions Felix A. Croes
    • • atomic functions Shawn Halpenny
      • • atomic functions Jon A. Lambert
        • • atomic functions Felix A. Croes
          • • atomic functions Jon A. Lambert
            • • atomic functions Felix A. Croes
              • • atomic functions Jon A. Lambert
                • • atomic functions Felix A. Croes
                  • • atomic functions Jon A. Lambert
                    • • atomic functions Felix A. Croes
                      • • atomic functions J C Lawrence
                        • • atomic functions Felix A. Croes
                  • atomic functions J C Lawrence
                • atomic functions J C Lawrence
        • atomic functions Felix A. Croes
      • atomic functions J C Lawrence
      • • atomic functions Felix A. Croes
        • • atomic functions J C Lawrence
          • • atomic functions Felix A. Croes
            • • atomic functions J C Lawrence
          • atomic functions Chris Gray
    • atomic functions J C Lawrence
    • • atomic functions Chris Gray
      • • atomic functions J C Lawrence
        • • atomic functions Jon A. Lambert
          • • atomic functions Chris Gray
            • atomic functions J C Lawrence
  • atomic functions Jon A. Lambert
  • • atomic functions Felix A. Croes
    • • atomic functions Joel Dillon
      • • atomic functions Jon A. Lambert
    • atomic functions J C Lawrence
    • • atomic functions Jon A. Lambert
      • • atomic functions J C Lawrence
  • atomic functions Chris Gray
  • • atomic functions Jon A. Lambert
    • atomic functions Shawn Halpenny
    • • atomic functions Adam Wiggins
      • • atomic functions Adam Wiggins
        • atomic functions Shawn Halpenny
        • • atomic functions J C Lawrence
          • • atomic functions Jon A. Lambert
            • atomic functions Chris Gray
  • atomic functions J C Lawrence
  • • atomic functions Felix A. Croes
    • • atomic functions Shawn Halpenny
      • • atomic functions Felix A. Croes
        • atomic functions Jon A. Lambert
        • • atomic functions Shawn Halpenny
        • atomic functions Jon A. Lambert
      • atomic functions J C Lawrence
  • Atomic functions Par Winzell
  • • Atomic Functions Ben
  • Atomic functions Felix A. Croes
• (fwd) AD: [custom graphical] whitestar Dr. Cat
• • (fwd) AD: [custom graphical] whitestar Caliban Tiresias Darklock
  • • (fwd) AD: [custom graphical] whitestar Dr. Cat
    • (fwd) AD: [custom graphical] whitestar J C Lawrence
• DOOM Gets a Storyline? Holly Sommer
• • DOOM Gets a Storyline? Koster, Raph
• META: Filtering suggestions J C Lawrence
• (fwd) AD: [custom graphical] whitestar s001gmu@nova.wright.edu
• • (fwd) AD: [custom graphical] whitestar Dr. Cat
  • • (fwd) AD: [custom graphical] whitestar J C Lawrence
• UO in Wired, was OT: Birth announcement Koster, Raph