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
- An Idea... Mud Development Framework Bruce
- An Idea... Mud Development Framework Miroslav Silovic
- An Idea... Mud Development Framework Ben Chambers
- An Idea... Mud Development Framework Justin Rogers
- An Idea... Mud Development Framework Ben Chambers
- An Idea... Mud Development Framework John Buehler
- An Idea... Mud Development Framework Bruce
- An Idea... Mud Development Framework Jeremy Lowery
- An Idea... Mud Development Framework Chris Jones
- Server stability (was: Player statistics) Bruce
- Server stability (was: Player statistics) Koster, Raph
- Server stability (was: Player statistics) Bruce
- Server stability (was: Player statistics) Koster, Raph
- Server stability (was: Player statistics) J C Lawrence
- Server stability (was: Player statistics) Valerio Santinelli
- Server stability (was: Player statistics) Tess Snider
- Server stability (was: Player statistics) Bruce
- Server stability (was: Player statistics) Koster, Raph
- Server stability (was: Player statistics) Ben Chambers
- Server stability (was: Player statistics) Chris Jones
- New Muds Corey Crawford
- Dinner scheduling and possible roundtable J C Lawrence
- New Mud Fox McCloud
- MUD-Dev digest, Vol 1 #277 - 13 msgs Dr. Cat
- MUD-Dev digest, Vol 1 #277 - 13 msgs Matthew Mihaly
- MUD-Dev digest, Vol 1 #277 - 13 msgs Jake Song
- MUD-Dev digest, Vol 1 #277 - 13 msgs Jeff Freeman
- Server stability (was: Player statistics) Par Winzell
- Server stability (was: Player statistics) J C Lawrence
- Server stability (was: Player statistics) Bruce
- Server stability (was: Player statistics) Felix A. Croes
- MUD-Dev digest, Vol 1 #277 - 13 msgs J C Lawrence
- MUD-Dev digest, Vol 1 #277 - 13 msgs Jake Song
- MUD-Dev digest, Vol 1 #277 - 13 msgs Bruce
- MUD-Dev digest, Vol 1 #277 - 13 msgs Mark Watson
- ANNC: .NET Frameworks based Mud Codebase Justin Rogers
- ANNC: .NET Frameworks based Mud Codebase Bruce
- ANNC: .NET Frameworks based Mud Codebase szii@sziisoft.com
- ANNC: .NET Frameworks based Mud Codebase Justin Rogers
- ANNC: .NET Frameworks based Mud Codebase szii@sziisoft.com
- Announcing: Pan J C Lawrence
- Announcing: Pan J C Lawrence
- Announcing: Pan Kyndig
- Experience System Differences Alornen
- Experience System Differences Malcolm Tester
- Experience System Differences Hulbert, Leland
- Experience System Differences rayzam
- Experience System Differences Ben Chambers
- Experience System Differences rayzam
- Experience System Differences Ben Chambers
- Experience System Differences Travis Casey
- Experience System Differences Mark Watson
- Experience System Differences rayzam
- Experience System Differences Kindred321@aol.com
- Experience System Differences Hans-Henrik Staerfeldt
- Experience System Differences Brian M. Schkerke
- Experience System Differences Ben Chambers
- Experience System Differences Malcolm Tester
- Experience System Differences Warren Powell
- speaking of symposia... Robert Zubek
- MUD-Dev digest, Vol 1 #281 - 18 msgs Dr. Cat
- MUD-Dev digest, Vol 1 #281 - 18 msgs Jeff Freeman
- I Want to Bake Bread Neeby
- I Want to Bake Bread Richard
- I Want to Bake Bread John Buehler
- I Want to Bake Bread Richard
- I Want to Bake Bread Ryan
- I Want to Bake Bread Patrick Dughi
- I Want to Bake Bread Siobhan Perricone
- I Want to Bake Bread Hal Bonnin
- I Want to Bake Bread Travis Casey
- I Want to Bake Bread John Buehler
- Exploration Exp (was: Experience System Differences) Corey Crawford
- Exploration Exp (was: Experience System Differences) Lord Ashon
- Exploration Exp (was: Experience System Differences) John Buehler
- Exploration Exp (was: Experience System Differences) Philip Loguinov, Draymoor
- Exploration Exp (was: Experience System Differences) nbossett@pierb.com
- Exploration Exp (was: Experience System Differences) Warren Powell
- MUD research, good ideas and designers who care? Ola Fosheim Grøstad
- Baking Bread Lord Ashon
- Baking Bread John Buehler
- Distributed PSW design Stephane Bura
- Distributed PSW design Frank Crowell
- Distributed PSW design Bruce
- Distributed PSW design Stephane Bura
- Distributed PSW design John Buehler
- Distributed PSW design J C Lawrence
- Distributed PSW design Justin Rogers
- Distributed PSW design John Buehler
- Distributed PSW design Eli Stevens
- Distributed PSW design John Buehler
- MUD-Dev digest, Vol 1 #282 - 18 msgs Dr. Cat
- MUD-Dev digest, Vol 1 #282 - 18 msgs Koster, Raph
- IOWA project / Request for addition to FAQ Bruce
- No Exp? (was: Exploration Exp) Corey Crawford
- No Exp? (was: Exploration Exp) John Buehler
- No Exp? (was: Exploration Exp) Hulbert, Leland
- No Exp? (was: Exploration Exp) John Buehler
- No Exp? (was: Exploration Exp) msew
- No Exp? (was: Exploration Exp) John Buehler
- No Exp? (was: Exploration Exp) Travis Casey
- No Exp? (was: Exploration Exp) rayzam
- No Exp? (was: Exploration Exp) Michael Tresca
- No Exp? (was: Exploration Exp) John Buehler
- No Exp? (was: Exploration Exp) msew
- No Exp? (was: Exploration Exp) Michael Tresca
- No Exp? (was: Exploration Exp) Alistair Milne
- No Exp? (was: Exploration Exp) J C Lawrence
- No Exp? (was: Exploration Exp) John Buehler
- No Exp? (was: Exploration Exp) J C Lawrence
- No Exp? (was: Exploration Exp) John Buehler
- No Exp? (was: Exploration Exp) J C Lawrence
- C# Greg Miller
- Player Created Object System Philip Loguinov, Draymoor
- Player Created Object System Richard
- Player Created Object System Philip Loguinov, Draymoor
- Player Created Object System Christopher Allen
- Player Created Object System Richard
> From: Bruce [mailto:bruce@puremagic.com]
> Could you just post it to MUD-Dev given the apparent general level
> of interest?
It turns out that the design document was the discussion we had on our
board system. Its included at the end with its big heading. Theres
not as much there as I remember. The guy who went ahead and coded the
prototype system pretty much found it sufficient. How much use it
will be to others is debatable :) Unfortunately, most of our
discussion for most things we did at that stage was carried out online
and not logged.
Why is it a decomposition rather construction system?
Strangely enough, rather than the seemingly more logical goal of a
generic system that allows objects to created, the initial goal was
actually to allow objects to be taken apart. Like the gem out of the
pommel of a sword and things like that. This evolved into a system
where objects were composed of other objects and there was a template
which defined how they were put together.
Taking composite objects apart was a lot more achievable than the
reverse process. Its all very well to say, making composite objects
involves manipulations, tools and ingredients - but chances are most
processes involving these are very different. Not knowing a wide
range of these processes due to our extreme realisticity requirements
meant that we were of the opinion that we couldn't therefore design a
generic system to manage the processes. On the other hand, a lot less
information needs to be known to allow an object to be taken apart. A
sword for instance is just a blade, crossguard, grip and pommel.
Additional information is what each is made of, what each joins to and
how it is joined to it. As our system is based around defining
objects and then including them in other objects, this allows for a
wide variety of swords.
If at a later stage we wanted to expand the decomposition system to
additionally be the basis for a construction system, then it naturally
lends itself to this defining the templates for objects.
Our prototype system works. But for unknown reasons we moved onto the
next interesting idea and never actually added the easier stuff that
makes it usable and allows it to be integrated into the game. We have
quite a few projects at this level :)
The "design document".
--<cut>--
O B J E C T D E C O M P O S I T I O N
----------------------------------------
Thu May 7 18:23:40 1998: (Galileo)
-----------------------------------
Okay, I've been contemplating basic object manipulation and structure
in an effort to come up with something practical, useable, and above
all else realistic. This of course is *not* what we have ATM. Here's
what I've come up with so far, your opinions as always are welcome and
encouraged.
We build for lack of a better term, a substance/material handler that
stores information on an assortment of common materials from iron, to
flesh. For each of these basic materials, we store:
state (solid/liquid/gas/plasma)
consistancy (how thick or thin it is)
texture
opacity
color
strength (how durable it is)
density (it's density, water is 1 remember)
smell
taste
other (anything that doesn't fit in one of the above)
Then when creating an object, let's say a sword you'ld have to set
what substances (or materials if your prefer), and in what porportions
were used to build it. In our example:
set_material( ({ STEAL, 90, GOLD, 10 }) );
This would give us a sword that's 90% steal but, also 10% gold,
probably the hilt. This has a couple of advantages. The biggest one
I see, of course is it makes standardizing weapons, armour, etc
painless. The durability, sharpness, and what not would be calculated
for you and you wouldn't need to mess with getting approprite values,
and balancing it. There would of course be support for setting your
own unqiue material for this particular item, and over riding the
default computed values if desired. Also, this system has the perk of
saving a bit of memory, by consolidating all that repetative attack
information and what not that was scattered throughout all the
individual objects.
On top of this I'd like to change how weight is done, now I know the
stones system is what most muds use, but does anyone really like it?
Personally, I'd be inclined to convert it over to a grams. The units
are nicer, a player can more readily digest how much he is actually
carrying, since 500 stones, doesn't mean as much to most people in my
opinion as 25 kg.
Also, as an odd thought, I never much liked the way bags worked
either. It seems to me, they should be based more on volume rather
then mass. Now we've stored the materials density, and we have it's
mass so we can easily calculate a volume for the object. Now, this
isn't gonna always be acurate, for obvious reasons such as a sword may
have a smaller volume then a cinder block, yet be considerably larger.
However, it would in my opinion be slightly better then just basing it
on mass which is done now.
Finally, I've some ideas on potions and mixing of liquids and gases,
that's been outdated a bit by this, but the basic idea still applies.
The file is in /w/galileo/text/potions.txt, please take a look.
Anyway, this is already longer then I had hoped, but if you do read it
all please post an opinion on it. I'm done now.
Thu May 7 19:41:14 1998: (Eggjon)
----------------------------------
I agree with you on most points. Grams make more sense to me than
stones..... I don't think we should have to stick to percentages,
i.e.
set_material(({"steel",9,"gold",1}));
should be as effective as
set_material(({"steel",18,"gold",2}));
since we already have the weight stored.
I don't think we can make materials totally calculate the effect of a
weapon... But there's no reason they shouldn't calculate the effect
of a piece of armour... Weapons can be pierce, blunt, whatever... I
think a spear made 90% out of wood can do as much damage as a hammer
made 90% out of steel. In the right hands, of course.
Thu May 7 22:09:51 1998: (Donky)
---------------------------------
I'm more inclined to the more thematically correct stones measurement
than the metric system.
set_material(steel, gold)
doesn't quite raise my flag, to me this infers that the metals are
mixed (I forget the word.. amalgam?)
Maybe objects could be composed out of parts, like:
sword = hilt + blade + pommel.
the hilt might be made out of well, steel wrapped in leather (which
the player might be able to remove). The pommel might be gold with a
jewel of some kind which can be pried out by a player.
The blade, steel again perhaps engraved and inlaid with gold runes.
Ideally we would be able to have blacksmiths that could repair these,
and make them. Players would be able to learn the same.
+++
> state (solid/liquid/gas/plasma)
> consistancy (how thick or thin it is)
Hmm, to me consistancy applies only to materials in the liquid state
and could easily come under the texture umbrella. i.e. The liquid had
a thick texture.
> texture
> opacity
Hmm, opacity being how see through the material is could come under
colour possibly?
> color
> strength (how durable it is)
Maybe strength should be renamed to durability? How does this relate
to liquids, I can see the relevance for solids. Perhaps this might be
part of a replacement for the condition of objects? i.e. when they
need repair etc..
> density (it's density, water is 1 remember)
> smell
> taste
> other (anything that doesn't fit in one of the above)
Hmm, it occurs to me that secondary properties might be required
depending on the state of the material.
For instance, lets say you have 'water'. It would have two potential
states, solid and liquid. The default would of course be liquid. So
lets see, from this, we might derive that we would want to keep a
range of properties representing a state of a material. We would want
to specify whether a solid is consumable, you can taste a sword but
you can't eat it. You can taste an apple, and also eat it. If you
taste solid water 'frozen', then it might get stuck to your tongue.
> Then when creating an object, let's say a sword you'ld have to set
> what substances (or materials if your prefer), and in what
> porportions were used to build it. In our example:
This is how, I see it. Again, it is not 'how it is' but merely my
thoughts up for comment or use.
A sword would be specified as having three main parts, the blade, the
pommel and the hilt. Each can be made out of a solid material, to
form the whole. Lets say a you get some 'dirt', put it in a bowl. You
take out your waterskin and tip in some water and have mud in the
bowl. You get somw mud from the bowl and form a blade. You get some
more and form a pommel and a hilt. You join them all together. You
have a sword. Yeah, sure that sword is going to be crap as dogshit
and a real sword is going to plow through it and slam into you making
you sick as dogshit. But imagine if you are a wizard, you cast an
illusion on a dirt sword so that it looks like the most kick-ass sword
that was ever made, I think this makes for really good potential.
Ok, so we have 'objects' that can be requested which are created in a
specified way but not nescessarily with a given selection of
materials. The object might have properties, lets say for instance
you carve a sword in its entirety out of stone. A steel sword that
hits stone will soon blunt or even break. That can be calculated from
the strength of the offense and the strength of the defense and the
properties of the connecting materials.
Ideally, this has much more potential than swords IMO. Players might
learn how to make 'yarn' from 'wool', might learn how to make clothes
from 'yarn' and then could sell clothes. This is just one example of
many possibilities.
I think it is essential we make this possible.
> Also, as an odd thought, I never much liked the way bags worked
> either. It seems to me, they should be based more on volume rather
> then mass. Now we've stored the materials density, and we have it's
> mass so we can easily calculate a volume for the object. Now, this
> isn't gonna always be acurate, for obvious reasons such as a sword
> may have a smaller volume then a cinder block, yet be considerably
> larger. However, it would in my opinion be slightly better then
> just basing it on mass which is done now. >
I think mass should still be relevant in that the material of a bag
might not be able to support over a certain mass. Thus the bottom
might fall out of a sack or backpack etc if too heavy things are put
in and it is lifted.
Fri May 8 15:16:20 1998: (Hogwash)
-----------------------------------
> I think a spear made 90% out of wood can do as much damage as a
> hammer made 90% out of steel. In the right hands, of course.
However, a spear made out of wood would probably be more liable to
break, than a hammer made out of steel
+++
> that the metals are mixed (I forget the word.. amalgam?)
Alloy?
Fri May 8 15:40:22 1998: (Belgie)
----------------------------------
It's fun to dispute words but they're both right.
Amalgam - An alloy of Mercury with another metal or metals.
- A mixture of diverse elements.
Alloy - A macroscopically homogeneous mixture of solid solution
- Something added that lowers value or purity.
Too bad I sold back that material science book, might have come in
handy with all these new stuff.
Fri May 8 19:54:35 1998: (Galileo)
-----------------------------------
Okay, here's another track we might take. Since it seems the
functionality everyone really wants is the ability to create objects
such as our sword example, from a set of pieces maybe we should persue
that primarily. What I mean, is let's go ALL the way back, and change
what IS a standard object.
We'll assume for arguements sake that any instance of OBJECT_OBJ will
simply contain information pertaining to a specific part of a large
object. For example, it might be the gold hilt of our sword. Mind
you it's NOT the entire sword but just the hilt, and is composed of
only 1 material, (we'll allow alloys too).
Now since obviously, alot of things in the game are going to made from
multiple distinct parts, we'll set up base template inheritances.
These will contain basic information for what parts are
required/optional to build this object. So when building a sword you
would inherit the SWORD_OBJ, and then either set each part with
specific information about it, or we could also set it up to pull the
info for an existing object if ya like. Now we wouldn't want to store
an array of object pointers since they're unique to each clone, and
we'd like to get all the information localized in 1 object. So, I'm
off the opinion that the standard object should be written to use
classes, and then a copy of the class that represents OBJECT_OBJ,
could just be stored in SWORD_OBJ. This way, it's pretty painless to
remove and attach pieces to other peices, assuming they conform to one
of the available templates.
Of course, we'll set up a generic template to cover all the objects
that don't quite fall into a specific template type, or for other
reason don't require or desire this kind of functionality, the money
object for example.
Now what this does for us is a few things, people should be able to
smith weapons since we have a definite pattern, and proceedure define
to create certain things. For example the sword, if you go out and
find a chunk of iron and bang it in to the shape of a blade, and a
hilt we'd easily be able to discover that assembled they're a sword
and should be treated as such.
It also sets up rough classification of item type for everything in
the game. You'ld be able to tell if somethings a Tee-Shirt, or an
actual full suit of armour by checking it's type, in this case
CLOTHING_OBJ, and ARMOUR_OBJ. This plays nicely into an economic
system suggested by Belgie. I won't get into the details here, but
the jist of it is, each area would have slightly different values for
the materials, and the type of object. In which case it'd be easy to
calculate a relative value of this object in various points around the
game. Since, it seems we'll have multiple types of currency, this
might actually turn out to be nessisary where bartering is the only
means available. But this is for another post...
+++
Also, some other little details things, I suppose durability does make
more sense as a name for the element. Also I forgot to add 1 thing to
that list of elements, value. Each substance will have to have a
specific value.
As for a few not applying, your right. A few don't apply to every
phase of a substance, but it seemed to me id'd rather put a few extra
in, the set up complete different classes for each different phase.
Maybe, that wasn't a good idea, opinions?
As for stone, I can see why some people would want to keep it as it
is, it's quite a bit more romantic and in theme, but I don't find the
nussence worth the effect.
Fri May 8 20:08:49 1998: (Eggjon)
----------------------------------
I think we shouldn't bother with making objects a collection of small
subobjects. I think we should try to make it something more like the
corpse object, i.e. you can get take objects apart to get two objects.
So, perhaps an array of parts? We'd make up a part class for it, too?
Sat May 9 23:38:28 1998: (Donky)
---------------------------------
The method I had in mind was that everything that was possible to be
made was composed of parts. A sword would be a part, but obviously
you can't build with it so it would be a part that no other parts
specify in their recipe.
Ok, let me make it a bit clearer how I see my vision of how this would
all work. As Galileo and I have already considered, the best way to
handle all this would be to have a handler that you request such
objects from passing a list of specifications that fit the objects
design schema. Ideally, we might want to consider passing any objects
that are parts used to create the object requested so the handler can
handle disposing of them at the same time.
On object requested might be a 'part'. A part isn't nescessarily part
of another object the handler knows about, but is itself specified in
the handler, this allows us to have a sword as a part as mentioned
above. Lets say you built the sword out of a hilt with attributes X
(that obviously fit into the hilt design schema) a blade with
attributes Y (same as for hilt) and ditto for the blade. The
requested sword object would contain the specific hilt info which is
the information that could be used to recreate the hilt
separately. And the same for the blade and pommel. (ok, so I meant
pommel in the instance of blade in the last paragraph). Ideally in
the case of things that were made from raw materials, like the blade,
there would only be a need to keep a record of it's composition. Same
for liquids. Perhaps, liquids could also be 'parts'. I think it
would be a good idea.
Anyway, thats how I see it, yes if every sword on the mud was
different it might get a bit memory intensive but we could share the
information for swords that are the same. etc, similarily for other
items.
--<cut>--_______________________________________________
- Distributed PSW design (Frank Crowell) Peter Yu
- Distributed PSW design (Frank Crowell) Frank Crowell
- MUD-Dev digest, Vol 1 #282 - 18 msgs Jeff Freeman
- MUD-Dev digest, Vol 1 #282 - 18 msgs J C Lawrence
- MUD-Dev digest, Vol 1 #282 - 18 msgs Jake Song
- Room Generation Nathanael Dermyer
- Room Generation J C Lawrence
- Room Generation George Greer
- Room Generation Bruce
- Room Generation Bruce
- Room Generation Richard
- Room Generation Mordengaard
- Room Generation Kwon Ekstrom
- Room Generation Jon Lambert
- Room Generation Patrick Dughi
- Room Generation Ola Fosheim Grøstad
- Room Generation Travis Casey
- Room Generation Ola Fosheim Grøstad
- Room Generation Eli Stevens
- Room Generation Richard
- Room Generation Richard
- Room Generation Colin Coghill
- Room Generation efindel@earthlink.net
- Room Generation Ryan P.
- Variant Methods for Related Skills Christopher Allen
- Variant Methods for Related Skills Travis Casey
- Anyone know of plans for an I-Mode MUD/LARP? J C Lawrence
- Anyone know of plans for an I-Mode MUD/LARP? Koster, Raph
- Anyone know of plans for an I-Mode MUD/LARP? Ola Fosheim Grøstad
- Anyone know of plans for an I-Mode MUD/LARP? rayzam
- Anyone know of plans for an I-Mode MUD/LARP? Travis Casey
- Anyone know of plans for an I-Mode MUD/LARP? Jon Lambert
- Anyone know of plans for an I-Mode MUD/LARP? Jeff Freeman
- Room and Terrain Integration in Textual Environments vognsen@post10.tele.dk
- Project Entropia the_logos@www.achaea.com
- Project Entropia John Vanderbeck
- Project Entropia Christopher Allen
- Project Entropia J C Lawrence
- Project Entropia J C Lawrence
- Project Entropia John Vanderbeck
- Project Entropia the_logos@www.achaea.com
- Project Entropia Batir
- Project Entropia the_logos@www.achaea.com
- Project Entropia Frank Crowell
- Project Entropia Jessica Mulligan
- Project Entropia Frank Crowell
- Project Entropia Jessica Mulligan
- Project Entropia the_logos@www.achaea.com
- Project Entropia the_logos@www.achaea.com
- MUD-Dev digest, Vol 1 #285 - 32 msgs Dr. Cat
- MUD-Dev digest, Vol 1 #285 - 32 msgs Jeff Freeman
- MUD-Dev digest, Vol 1 #285 - 32 msgs Jake Song
- MUD-Dev digest, Vol 1 #285 - 32 msgs Jeff Freeman
- MUD-Dev digest, Vol 1 #285 - 32 msgs Jake Song
- MUD-Dev digest, Vol 1 #285 - 32 msgs Koster, Raph
- MUD-Dev digest, Vol 1 #285 - 32 msgs Jeff Freeman
- MUD-Dev digest, Vol 1 #285 - 32 msgs Jeff Freeman
- MUD-Dev digest, Vol 1 #285 - 32 msgs Jake Song
- Skill System Kwon Ekstrom
- Skill System Travis Casey
- Skill System justice@softhome.net
- Skill System Ben Chambers
- Skill System Batir
- Skill System Ben Chambers
- Skill System Batir
- Skill System justice@softhome.net
- Long Day's Journey Into Tights J C Lawrence
- MUD-Dev digest, Vol 1 #289 - 8 msgs Dr. Cat
- MUD-Dev digest, Vol 1 #289 - 8 msgs the_logos@www.achaea.com
- MUD-Dev digest, Vol 1 #289 - 8 msgs Hans-Henrik Staerfeldt
- MUD-Dev digest, Vol 1 #289 - 8 msgs Nathan F.Yospe
- MUD-Dev digest, Vol 1 #289 - 8 msgs justice@softhome.net
- MUD-Dev digest, Vol 1 #289 - 8 msgs Dave Rickey
- MUD-Dev digest, Vol 1 #289 - 8 msgs Vincent Archer
- MUD-Dev digest, Vol 1 #289 - 8 msgs msew
- MUD-Dev digest, Vol 1 #289 - 8 msgs Travis Casey
- When Do We Get the "Right" to Privacy? J C Lawrence
- When Do We Get the "Right" to Privacy? Nathan F.Yospe
- When Do We Get the "Right" to Privacy? Koster, Raph
- Cybercafes a fluke? (was: MUD-Dev digest, Vol 1 #289 - 8 msgs) Scion Altera
- Cybercafes a fluke? (was: MUD-Dev digest, Vol 1 #289 - 8 msgs) Holly Sommer
- An interesting concept Richard.Woolcock@rsuk.rohde-schwarz.com
- [iggamedes] WAKE UP! :) Tomb Raider style games? J C Lawrence
- [iggamedes] WAKE UP! :) Tomb Raider style games? Jon Lambert
- Cultural Differences in Gaming and Gamers SavantKnowsAll@cs.com
- Cultural Differences in Gaming and Gamers Koster, Raph
- Cultural Differences in Gaming and Gamers the_logos@www.achaea.com
- System burps and outages J C Lawrence
- Semi Graphical Muds Ben Chambers
- Semi Graphical Muds Peter Yu
- Semi Graphical Muds Christopher Allen
- Semi Graphical Muds the_logos@www.achaea.com
- Semi Graphical Muds Ben Chambers
- Semi Graphical Muds David Loeser
- Semi Graphical Muds Ben Chambers
- Semi Graphical Muds David Loeser
- Semi Graphical Muds the_logos@www.achaea.com
- Semi Graphical Muds Ben Chambers
- Semi Graphical Muds Corey Crawford
- Semi Graphical Muds Kerem HADIMLI
- Semi Graphical Muds Jon Lambert
- Semi Graphical Muds the_logos@www.achaea.com
- Semi Graphical Muds J C Lawrence
- Semi Graphical Muds Ben Chambers
- Semi Graphical Muds Kerem HADIMLI
- Semi Graphical Muds Frank Crowell
- Semi Graphical Muds Ben Chambers
- Semi Graphical Muds Koster, Raph
- Semi Graphical Muds Ben Chambers
- Semi Graphical Muds Caliban Tiresias Darklock
- Semi Graphical Muds Bruce
- Semi Graphical Muds Jay Carlson
- Semi Graphical Muds the_logos@www.achaea.com
- Semi Graphical Muds Jon Lambert
- Semi Graphical Muds J C Lawrence
- Semi Graphical Muds Bruce
- Semi Graphical Muds the_logos@www.achaea.com
- Semi Graphical Muds Bruce
- Semi Graphical Muds Christopher Allen
- Semi Graphical Muds Bruce
- Semi Graphical Muds Felix A. Croes
- Semi Graphical Muds Christopher Allen
- Semi Graphical Muds Felix A. Croes
- Semi Graphical Muds Ben Chambers
- Semi Graphical Muds Bruce
- Semi Graphical Muds David Loeser
- Semi Graphical Muds Marc Bowden
- Semi Graphical Muds Felix A. Croes
- Semi Graphical Muds Bruce
- Semi Graphical Muds Felix A. Croes
- Semi Graphical Muds Adam Casbarian
- Semi Graphical Muds J C Lawrence
- Semi Graphical Muds the_logos@www.achaea.com
- Semi Graphical Muds J C Lawrence
- Semi Graphical Muds Koster, Raph
- Semi Graphical Muds J C Lawrence
- Semi Graphical Muds Koster, Raph
- Semi Graphical Muds the_logos@www.achaea.com
- Semi Graphical Muds J C Lawrence
- Semi Graphical Muds the_logos@www.achaea.com
- Semi Graphical Muds John Buehler
- Semi Graphical Muds Koster, Raph
- Semi Graphical Muds Dave Rickey
- Semi Graphical Muds Hulbert, Leland
- Semi Graphical Muds Dave Rickey
- Semi Graphical Muds geoffrey@yorku.ca
- Semi Graphical Muds the_logos@www.achaea.com
- Semi Graphical Muds rayzam
- Semi Graphical Muds J C Lawrence
- Semi Graphical Muds Sanvean
- Semi Graphical Muds J C Lawrence
- Semi Graphical Muds Tamzen Cannoy
- Semi Graphical Muds J C Lawrence
- Semi Graphical Muds the_logos@www.achaea.com
- Semi Graphical Muds Frank Crowell
- Semi Graphical Muds rayzam
- Semi Graphical Muds the_logos@www.achaea.com
- Semi Graphical Muds rayzam
- Semi Graphical Muds the_logos@www.achaea.com
- Semi Graphical Muds J C Lawrence
- Semi Graphical Muds the_logos@www.achaea.com
- Semi Graphical Muds rayzam
- Semi Graphical Muds the_logos@www.achaea.com
- Semi Graphical Muds Ben Chambers
- Semi Graphical Muds rayzam
- Semi Graphical Muds Kevin Littlejohn
- Semi Graphical Muds J C Lawrence
- Semi Graphical Muds Ben Chambers
- Semi Graphical Muds the_logos@www.achaea.com
- Semi Graphical Muds J C Lawrence
- Semi Graphical Muds Adam Casbarian
- Semi Graphical Muds the_logos@www.achaea.com
- Ebay bans character selling the_logos@www.achaea.com
- Ebay bans character selling susie
- Ebay bans character selling Frank Crowell
- Ebay bans character selling Frank Crowell
- Ebay bans character selling the_logos@www.achaea.com
- Ebay bans character selling Richard.Woolcock@rsuk.rohde-schwarz.com
- Ebay bans character selling Kevin Littlejohn
- Ebay bans character selling Travis Casey
- Ebay bans character selling Hans-Henrik Staerfeldt
- Ebay bans character selling Hans-Henrik Staerfeldt
- Ebay bans character selling rayzam
- Ebay bans character selling John Buehler
- Ebay bans character selling Hans-Henrik Staerfeldt
- Ebay bans character selling Dave Rickey
- Ebay bans character selling Eric Lee {RAT}
- Ebay bans character selling Frank Crowell
- Ebay bans character selling Timothy Dang
- Ebay bans character selling Paul Robinson
- Ebay bans character selling Peter Yu
- Ebay bans character selling Daniel.Harman@barclayscapital.com
- Ebay bans character selling David Kennerly
- Ebay bans character selling Willowreed@aol.com
- Ebay bans character selling Travis Casey
- Ebay bans character selling rayzam
- Ebay bans character selling Jeremy Music
- Ebay bans character selling rayzam
- Ebay bans character selling Yves K
- Ebay bans character selling the_logos@www.achaea.com
- front end clients.....was Semi Graphical Muds Willowreed@aol.com
- front end clients.....was Semi Graphical Muds Frank Crowell
- front end clients.....was Semi Graphical MUDs Christopher Allen
- Meta-gaming: (real <--> game) transfers David Kennerly
- EverQuest Study Dave Rickey
- [pol-core-test] New file uploaded to pol-core-test (OT) Jeff Freeman
- [pol-core-test] New file uploaded to pol-core-test (OT) the_logos@www.achaea.com
- [pol-core-test] New file uploaded to pol-core-test(OT) Dave Rickey
- [pol-core-test] New file uploaded to pol-core-test(OT) Valerio Santinelli
- [pol-core-test] New file uploaded to pol-core-test(OT) Frank Crowell
- PvP Systems John Buehler
- PvP Systems Jon Lambert
- PvP Systems the_logos@www.achaea.com
- PvP Systems Federico Di Gregorio
- PvP Systems John Buehler
- PvP Systems gmiller@classic-games.com
- PvP Systems John Buehler
- PvP systems Greg Miller
- PvP systems John Buehler
- PvP systems gmiller@classic-games.com
- PvP systems John Buehler
- PvP systems gmiller@classic-games.com
- PvP systems John Buehler
- PvP systems gmiller@classic-games.com
- PvP systems the_logos@www.achaea.com
- PvP systems J C Lawrence
- PvP systems the_logos@www.achaea.com
- PvP systems J C Lawrence
- PvP systems the_logos@www.achaea.com
- PvP systems the_logos@www.achaea.com
- PvP systems Dave Turner
- PvP systems gmiller@classic-games.com
- PvP systems the_logos@www.achaea.com
- PvP systems S. Patrick Gallaty
- PvP systems the_logos@www.achaea.com
- PvP Systems Federico Di Gregorio
- PvP Systems John Buehler
- PvP Systems the_logos@www.achaea.com
- PvP Systems John Buehler
- PvP Systems Jake Song
- PvP Systems the_logos@www.achaea.com
- PvP Systems John Buehler
- PvP Systems the_logos@www.achaea.com
- PvP Systems John Buehler
- PvP Systems the_logos@www.achaea.com
- PvP Systems Corey Crawford
- PvP Systems Jon Lambert
- PvP Systems John Buehler
- PvP Systems Jon Lambert
- PvP Systems John Buehler
- PvP Systems Sanvean
- PvP Systems J C Lawrence
- PvP Systems John Buehler
- PvP Systems J C Lawrence
- PvP Systems John Buehler
- PvP Systems J C Lawrence
- PvP Systems John Buehler
- PvP Systems J C Lawrence
- PvP Systems the_logos@www.achaea.com
- PvP Systems J C Lawrence
- PvP Systems Michael Tresca
- PvP Systems John Buehler
- PvP Systems Jon Lambert
- PvP Systems John Buehler
- PvP Systems Travis Casey
- PvP Systems the_logos@www.achaea.com
- PvP Systems Kerem HADIMLI
- PvP Systems the_logos@www.achaea.com
- PvP Systems The Druid
- PvP Systems rayzam
- PvP Systems John Buehler
- PvP Systems msew
- PvP Systems Koster, Raph
- PvP Systems msew
- PvP Systems msew
- PvP Systems John Buehler
- PvP Systems msew
- PvP Systems Vincent Archer