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
On Sat, 4 Apr 1998 07:04:14 PST8PDT
Cat <cat@bga.com> wrote:
> I presume the comments about disk-based muds running faster than
> memory-based ones are including the tacit assumption that one is
> talking about muds that don't have the option of running on a
> machine with a large surplus of RAM?
Yes, but only just.
Aside: I've done a lot of work on large RAM machines (the machine I'm
typing on now has 256Meg RAM, which is piddley compared to the 32Gig
RAM sitting behind me).
Even given a technical surplus of RAM (ie physical RAM is larger than
total working set of system), many systems will continue to swap.
Why? File/disk cacheing, long idle memory pages, etc -- the OS
typically thinks it knows better than mere applications where best
performance lies. Yes, this can be turned off in a variety of
fashions. The two most common means are to mark particular memory
pages as non-swappable (not supported by all OS'es), or to instruct
the entire OS not to swap (scalability and load problems).
However, a disk-based DB with intelligent cacheing can still
out-perform an all-in-RAM system in a few cases (highly dependant on
working set characteristics (no, this ain't common, but I've seen it
in practice)). The base cause is still the same: memory page faults
-- except that this time the expense is not disk/swap IO, but memory
model context. (The heap fragmentation you referred to later is a
prime form) A well written cacheing system will keep all cached items
proximate in memory, thus minimising the memory context
shifts...(highly dependant on CPU and MMU memory architecture).
> I run a commercial project,
> and it seems the only option for really optimal performance is to
> make sure you have enough RAM to keep everything in memory that you
> need.
<nod>
In the general case I doubt that DB<->server IO is the likely
bottleneck, especially given expectable 'net bandwidths to the
consumer in the next 5 years. Physical IO to the machine is much more
likely to be the real plague. (What! You want X,000+ active socket
connections with good bandwidth to all? Get an AS/400 or Sys360....It
still amazes me that commercial MUD offerings are even attempting to
build on PC hardware given its atrocious IO hardwre).
Its probably a safe prediction in a commercial setting that worlds and
world databases will grow large. How large is LambdaMOO's core image
now? (I have no idea). Add a fully rendered world of many times that
size and I would have no problem seeing the core image exceeding
100Gig, and RAM remains expensive at those levels -- especially for a
startup.
> I also don't do a bunch of dynamic stuff - I prefer to do all
> mallocs and loading of maps and objects at startup, and keep it
> there.
Sooth. Custom heap managers are your friend. My own heap manager is
based in spirit on LanbdaMOO's:
I pre-allocate large pools of memory blocks of sizes of various
powers of 2. All later allocation requests are expanded to the next
larger or matching power of 2, and a free block from that pool is
handed back. Minimum block size is 64 bytes (I think, could be 512).
Pools start by doubling their size when they run out of space, until
they reach a total of 1024 allocations and then proceed to grow at a
rate of 1024 blocks per growth spurt.
> Anyway, my server can currently handle over 150 people quite well
> with a memory footprint of under 32 megabytes.
I would have expected world size to be the greater memory consumer.
Users merely consume IO. How large is your world in terms of the time
required for a user to traverse its greatest dimension? How detailed
is your world in terms of LOD?
> I was planning
> to set up a seperate process that does all disk writes, and have the
> other processes dump data to it and then go on about their business.
Not a bad idea as it allows the maintenance of logical consistency for
the permanent storage to be extracted from and no longer dependant on
(per se) the main server.
> But a friend of mine told me about how they eliminated their
> disk-writing bottlenecks when they purchased a RAID array for the
> server, which essentially does the same caching of writes into RAM,
> only it's done for you, in hardware.
Be careful here. All RAID is not created equal. All RAID adapators
and controllers are not created equal. OS drivers for RAID hardware
(where applicable) are also often very unequal.
Some permutations:
RAID in standalone hardware. Good examples are HP's NIKE (Date
General) and Edison boxes. To the outside world (ie your machine) its
just a hoking big disk, or a collection of disks. All the RAID
smarts are done in the disk tower, configured via serial terminal or
LCD panel.
RAID in the SCSI adaptor. DTK make the fastest, bar none, RAID SCSI
adaptors for PC's (cf SmartRaid). Their SmartCache cards are no
slouches either. In this model configuration of the card or its
drivers via software on the host is resposible for the RAID model.
Outside the card its just a bunch of dumb disks. DTK's OS/2 drivers
positively scream. I assume their MS drivers are of comparable
quality. The Linux, *BSD, UnixWare and SCO drivers however are so
poor as to be pathetic. Buslogic's RAID cards, which otheriwse don't
compare to DTK's, far outperform DTK under Linux due to driver
quality.
RAID in software. You use a dumb SCSI card, and dumb disks, and
then use intelligence in the SCSI drivers to do RAID via software on
the host. Linux supports this fairly well. There are obvious
performance and stability penalties.
Cost generally decreases as you descend the above list.
There are also various forms of RAID each with their own performance
characteristics, from RAID 0 (simple mirroring which offers the
fastest possible read/write speeds), to RAID 5 (striping with parity)
which tends to give fair read speeds, but very poor write speeds.
Other RAID levels have other characteristics.
Cacheing can be thrown at the problem at any level, from caches on the
physical drive (the HP C3010 drives I'm trying to shift now (got 100
of them) have 256K of dual ported cache on the actual drive) to cache
on the RAID box (a typical NIKE will have 32Meg of cache or more),
cache on the SCSI adaptor (DTK cards can carry up to 64Meg of cache),
or OS/driver level caching using main system RAM.
<chortle> I spent 18 months at HP working on their HA products, RAID
arrays (NIKE, Edison, Icicle etc), EMC towers (anybody want 40
terrabytes in a box the size of a 'fridge?) etc.
> I realize that purchasing a RAID array isn't an option for most
> hobby projects.
RAID is getting cheaper. DTK continues to make the fastest RAID (and
non-RAID) cards for PC's, bar none (SmartRAID and SmartCache
respectively). Drives are now almost throw-away items: I have stacks
and stacks of 2Gig HP C3010's I'm shifting for $75ea... They make
cute fast little RAID towers.
> Still, I would think that disk-based servers would
> be faster for some muds, not for all muds. (Depending on memory
> footprint, configuration of the machine in question, and whether
> it's running other things besides the mud or not.)
True.
--
J C Lawrence Internet: claw@null.net
(Contractor) Internet: coder@ibm.net
---------(*) Internet: claw@under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith... - 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
- 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
- caved in: Algorithms for for storing free space. Ben Greear
- 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
- 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
- META: That bloke Yaltec. Khan one
- META: That bloke Yaltec. J C Lawrence
- a fruitful exchange on classlessness in r.g.m.admin Cimri
- 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: 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 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) Adam Wiggins
- (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
- 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
- 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