July 1998
- Elven Language List J C Lawrence
- Summary: "Influence Mapping" J C Lawrence
- 1997 CGDC AI Roundtable Moderator's Report J C Lawrence
- 1997 CGDC AI Roundtable Moderator's Report J C Lawrence
- Summary: Recognizing Strategic Dispositions J C Lawrence
- Back to the Future (was WIRED: Kilers have more fun) Mike Sellers
- Back to the Future (was WIRED: Kilers havemore fun) Koster, Raph
- Back to the Future (was WIRED: Kilers have more fun) J C Lawrence
- Back to the Future (was WIRED: Kilers have more fun) S. Patrick Gallaty
- Back to the Future (was WIRED: Kilers have more fun) J C Lawrence
- Help Request On Creating MUD Strahd Von ZAROVICH
- Help Request On Creating MUD Jon Leonard
- Help Request On Creating MUD J C Lawrence
- Help Request On Creating MUD J C Lawrence
- Help Request On Creating MUD J C Lawrence
- WIRED: Kilers have more fun Chris Gray
- WIRED: Kilers have more fun Adam Wiggins
- WIRED: Kilers have more fun J C Lawrence
- WIRED: Kilers have more fun Koster, Raph
- WIRED: Kilers have more fun Jon A. Lambert
- [RELEASED] Update release of ScryMUD (Accepting builders) Ben Greear
- Meta (Are code release announcement appreciated?) Ben Greear
- Meta (Are code release announcement appreciated?) Nathan F Yospe
- Meta (Are code release announcement appreciated?) J C Lawrence
- Ubiquity Scope & Requirements Greg Munt
- Ubiquity Scope & Requirements Vadim Tkachenko
- Ubiquity Scope & Requirements Greg Munt
- Ubiquity Scope & Requirements Chris Gray
- Ubiquity Scope & Requirements Vadim Tkachenko
- IMatix Tools: Libero and SMT J C Lawrence
- Affordances and social method (Was: Wired Magazine...) Till Eulenspiegel
- Affordances and social method (Was: Wired Magazine...) Marian Griffith
- Affordances and social method (Was: Wired Magazine...) Adam Wiggins
- Affordances and social method (Was: Wired Magazine...) Marian Griffith
- Affordances and social method (Was: Wired Magazine...) Orion Henry
- Affordances and social method (Was: Wired Magazine...) J C Lawrence
- Affordances and social method (Was: Wired Magazine...) Marian Griffith
- Affordances and social method (Was: Wired Magazine...) Marian Griffith
- Affordances and social method (Was: Wired Magazine...) Adam Wiggins
- Affordances and social method (Was: Wired Magazine...) Marian Griffith
- Affordances and social method (Was: Wired Magazine...) Caliban Tiresias Darklock
- Affordances and social method (Was: Wired Magazine...) Adam Wiggins
- Affordances and social method (Was: Wired Magazine...) Marian Griffith
- Affordances and social method (Was: Wired Magazine...) Maddy
- Affordances and social method (Was: Wire d Magazine...) cat
- Affordances and social method (Was: Wire d Magazine...) S. Patrick Gallaty
- Affordances and social method (Was: Wire d Magazine...) Dan Shiovitz
- Affordances and social method (Was: Wire d Magazine...) J C Lawrence
- Affordances and social method (Was: Wire d Magazine...) S. Patrick Gallaty
- Affordances and social method (Was: Wire d Magazine...) Caliban Tiresias Darklock
- Affordances and social method (Was: Wire d Magazine...) Caliban Tiresias Darklock
- Affordances and social method (Was: Wire d Magazine...) Marian Griffith
- SMAP: Small Application's Persistency, C++ Library J C Lawrence
- Development of a Smart Compiler J C Lawrence
- (fwd) command parsers: a modest proposal (with apologies to J. Swift) J C Lawrence
- (fwd) command parsers: a modest proposal (with apologies to J. Swift) Chris Gray
- WIRED: Kilers have more fun Petri Virkkula
- An Introduction Jeroen Ruigrok/Asmodai
- An Introduction Chris Gray
- An Introduction Jeroen Ruigrok/Asmodai
- An Introduction J C Lawrence
- An Introduction Caliban Tiresias Darklock
- An Introduction J C Lawrence
- An Introduction Caliban Tiresias Darklock
- An Introduction Chris Gray
- An Introduction Jeroen Ruigrok/Asmodai
- An Introduction Ross Nicoll
- An Introduction Chris Gray
- An Introduction Chris Gray
- An Introduction Ross Nicoll
- An Introduction J C Lawrence
- An Introduction Caliban Tiresias Darklock
- An Introduction Adam J. Thornton
- An Introduction J C Lawrence
- An Introduction Adam J. Thornton
- An Introduction Koster, Raph
- An Introduction Caliban Tiresias Darklock
- An Introduction Ilya, Game Commandos
- An Introduction Matthew Mihaly
- An Introduction Koster, Raph
- An Introduction Jon A. Lambert
- (fwd) command parsers: a modest proposal (with apologies to J. Swift) Richard Bartle
- Summary: The Game Design Mailing List "Learning AI" Thread J C Lawrence
- Summary: The "Extensible Game AI" thread J C Lawrence
- (fwd) command parsers: a modest proposa Michael.Willey@abnamro.com
- (fwd) command parsers: a modest proposa Adam Wiggins
- (fwd) command parsers: a modest proposa Ross Nicoll
- OT: Computer History Archive Holly Sommer
- (fwd) command parsers: a modest proposal (with apologies to J. Swift) Chris Gray
- You think users won't number crunch and statis Jon A. Lambert
- You think users won't number crunch and statis Matt Chatterley
- You think users won't number crunch and statis Adam Wiggins
- You think users won't number crunch and statis Dan Shiovitz
- You think users won't number crunch and statis Adam Wiggins
- You think users won't number crunch and statis Shawn Halpenny
- You think users won't number crunch and statis Adam Wiggins
- You think users won't number crunch and statis Travis S. Casey
- You think users won't number crunch and statis Katrina McClelan
- Massive brainstorm rant about an imaginary class system. (resent) Till Eulenspiegel
- PRNGs: Pseudo Random Number Generators J C Lawrence
- (fwd) command parsers: a modest proposa Richard Bartle
I've combined all my replies on this into one message, so people who have
no interest in the subject only have one to delete, not four.
Michael.Willey@abnamro.com wrote:
>I would disagree with that - As a player, I'd rather have the game
>abort a command than perform an unwanted command.
Unfortunately, players have different ideas as to what is "unwanted".
If the game takes a reasonably systematic approach so that players can
predict what will happen when they issue a command, they can begin to
exploit it; at that point, it becomes a "wanted" command. The problems arise
if, in learning what a command does, dangerous situations can arise as a
result of intuition misalignment: what a newbie thinks a command "ought to
do" and what it actually does. If you were routinely losing objects or
points or whatever from believing that X would happen when actually Y
happens, that would dispirit you. In the case of DROP ROCK, though, the
side-effects of either dropping 1 or dropping all of them aren't usually
going to be damaging; players will understand what the parser is doing after
only a few uses of the command, and will modify their future uses
accordingly.
Of course, the proof of the pudding is in the eating: although some
players probably would prefer to have to say DROP [A ] THE ] 1 ] EVERYTHING
I HAVE WHICH IS A] ROCK, in general they're happy to go along with how the
parser handles it. In 10 or more years of doing it the way I've described,
players have had no problems. I'm not saying they would necessarily have had
problems any other way, either, of course; what I am saying is that the way
I do it does work in practice.
Ross Nicoll <rnicoll@calmar-mud.com> wrote:
>Fine, until someone wants to drop more than one mouse (well, would you want
>to be wandering around with a load of mice? :) ).
You mean you don't have a way to say "MICE is the plural of MOUSE"?
It ought to be trivially easy.
>You could have fun with gloves, too; unless you have right glove and left
>glove objects, you're likely to have a "pair of gloves" object.
I don't have gloves in MUD2, but I have some shoes. There is indeed
a "left shoe" and a "right shoe", which can be separated; together they are
a "pair of shoes". You can DROP PAIR OF SHOES or DROP SHOES if you want to,
of course; in fact, DROP PAIR will work on its own (although it would drop
any othe robjects which were part of a pair, too).
>There's also the possibility of a plural that has an extra "es" instead of
>just "s" on the end, but I can't think of an word to use as an example.
Er, so what? Generating plurals on the fly is OK - the rules of
English are fairly inclusive - but you ought to be able to override the
default, surely? It's just a vocabulary entry which points at the plural
form of an object, like a synonym.
Adam Wiggins <adam@angel.com> wrote:
>Are you aruging that there is a gain somewhere by using this method, or
>just that the actual implementation is irrelevant since it's the same to
>the player and doesn't signifigantly affect performance either way?
From the player's point of view, you should be able to implement a
filter-while-searching algorithm such that it looks the same to them as a
filter-after-searching algorithm. After all, it's just as case of
pre-processing the parse tree prior to interpret it.
There is gain over simple pre-filtering parsers, though, in that if
you can bind nouns to sets of objects then you can manipulate those sets
prior to filtering. This shows up well with superlatives: DROP THE 3
HEAVIEST ROCKS OR STONES can take all the nearby rocks, take all the nearby
stones, form the union of the two sets, create an ordered set based on
weight, then return the set consisting of the first three elements. Now
you could implement that on a per-object basis, but it's not simple.
Building up per-object filters for things like DROP ALL OPEN BOXES WHICH
ARE NOT GOLD can get quite complicated. Not impossible, obviously, but
not how I'd do it.
>> >In "drop rock", it seems MUD2 would drop all rocks.
>> That's right, it would.
>Egads! How does one manipulate a single item?
DROP 1 ROCK or DROP A ROCK would do. If you wanted a particular
rock, you'd either use some unique adjective combination (DROP LICHEN-COVERED
ROCK) or superlative (DROP THE SMALLEST ROCK) or, if there was no way to
discriminate by descriptions, you'd drop it by its individual name, DROP
ROCK12.
>% i
>You are carrying a bow and ten arrows.
>% nock arrow
>You attempt to nock ten arrows at once, but end up just dropping them all
>over the place.
Well I execute my commands in series, not in parallel, so what would
happen is the first arrow would be nocked, and the rest would generate
error messages about the bow already being nocked. However, I don't print
such error messages if at least one command was successful, so all the
user would see is "You nock the arrow in the bow.". If they bow had an
arrow nocked when you tried the initial command, none would work so you
would get an error message (but not 10 copies of it).
>If "drop rock" drops all rocks, how do I drop only one, or two? "drop one
>rock"? This seems somewhat counterintuative.
You'd DROP 1 ROCK or DROP 2 ROCKs.
I don't find this counter-intuitive at all. If, in real life, you
had a handful of rocks and I wanted you to drop two of them, what I'd tell
you to do is DROP TWO ROCKS. I wouldn't tell you to DROP ROCK then tell you
to DROP ROCK again. I wouldn't even tell you to DROP A ROCK then DROP A
ROCK again: I'd just say DROP TWO ROCKS. What's counter-intuitive about it?
>> > - drop all of them
>> > - complain about ambiguity
>> > - drop some "random" rock
>> > - allow the user to choose
>I'd say that this choice is very specific to a given person.
Well, it's more specific to the MUD than to the individual: in a
non-game context, complaining about ambiguity might be a valuable thing to
do (EFL teaching MUDs might do it, for example).
Ideally, of course, which option is taken should be a decision which
the player ought to be able to set, and the programmer should write four
separate parsing routines. The issue then becomes what to make the default
for newbies.
>Personally I find the third option the best, mostly because it's what is
>found on most muds I've played. In some cases it drops the top item, in
>some cases the last, but either way you get what you ask for, which is one
>rock.
No, you didn't ask for one rock. GET ONE ROCK would ask for one
rock. GET ROCK genuinely is ambiguous.
>In most cases, if you have a big pile of something that all answers
>to the same keyword, they are all the same anyways and you don't care
>which one you get (in the case of the arrows, above, for example).
My players use GET TREASURE so often it's abbreviatable to a single
command, GT. If they enter a room with 3 pieces of treasure, they just want
it all; they don't want to type G ALL T or G T... (the dots repeat commands
in MUD2). If there was some they didn't want, they'd either name the other
stuff specifically or exclude the one they didn't want as in G T X AMULET.
>Commonly this is handled as:
>% get rock
>You get a rock.
Well, like I said, it's up to you how you do it. I happen to prefer
this to get all the rocks, but it's not like it's a biggie. I'm quite happy
for everyone else's MUDs to take a one-at-a-time approach.
>% get ten rocks
>You get ten rocks.
>% get all rocks
>You get twenty rocks.
MUD2 does this the same way.
>% drop third rock
>You drop the third rock.
I don't handle this in MUD2, partly because your inventory is not
necessarily displayed the way it's actually stored, so I'd have to work out
what people THOUGHT was their third rock prior to dropping it.
>This becomes more and more useful as more adjectives come in: if you're
>sorting through a huge pile of swords, all of which have slightly varying
>names like "a long thin blade made of silver" or "a long thin blade made
>of silver and etched with runes" or "a thin, single-edge blade" and you
>accidentaly grab the wrong one, you can always assume that "drop blade" or
>"drop sword" will rectify your mistake, instead of re-typing all the
>adjectives or recalling them from a command history (which is not always
>availible, anyways).
Of course, you could just use pronouns...
>% look
>You are in a room containing yourself, Bubba the Troll, and a hundreds of
>swords.
>%
>Bubba drops his sword.
>% get sword
>You get the sword.
GET IT
You pick up the sword.
>ACK! Surely you must have a method or specifying just one?
Yes, you type KILL A RAT, or KILL THE BIGGEST RAT or KILL THE
MOST INJURED RAT or whatever. If you've switched on object-naming, you can
KILL RAT7 if you really want.
>Some folks on the list prefer the pronoun notation:
I prefer it because sometime you can't tell whether a verb is
meant to be transitive or not.
DROP SWORD
You drop the sword.
LOOK
The sword is long and sharp and covered in blood.
NO YOU DUMB MACHINE I MEANT LOOK, YOU KNOW, LIKE LOOK AROUND!
Of course, you won't get this problem quite as much if you have a
system where verbs have to be specific to objects, so LOOK wouldn't work on
a sword, only EXAMINE would.
Chris Gray <cg@ami-cg.GraySage.Edmonton.AB.CA> wrote:
>OK. To clarify, however, I should say that what I meant for the fourth
>choice is that the user could set the policy for themselves, choosing
>once among the other alternatives.
Oh, I thought you meant enumerating the possible objects and getting
them to select which one. In that case, this is another option which should
be available.
>Hmm. I could get used to that! (My current scenario happens to have
>a room that comes equipped with a lot of rats, which aren't really
>dangerous. Typing only one command to attack all of them would be handy!)
KILL ALL RATS should work?
>Sounds similar again. My server is now in C (initially in my own
>language called "Draco"), and supports an internal language which the
>scenario is written in. The server supplies a bunch of "builtin"
>functions to help in parsing, however.
I have a MUDDLE-to-C compiler written, which takes my MUDDLE
world definition and translates it into native C. I haven't got around to
writing the run-time system yet, though.
>> >Are there in fact possibilities of adding to the vocabulary at run time?
>> Yes, there are.
>How does that work? Can normal players do it, or is it only available
>to administrators?
Well there's a SYN command, short for SYNONYM:
Flrxptl has just arrived.
SYN FLRXPTL AS "JOE"
JOE HI! HOW's TRICKS?
FLRXPTL TELLS YOU "SO-SO..."
I also allow the creation of objects under certain controlled
circumstances, and these will have names which are added to the vocabulary.
>Do you have any kind of human algorithm, etc. that allowed you to decide
>what abbreviations to use? Similar for handing misspellings?
Well writing anything which isn't understood to a log file catches
most of them.
>I can add/remove any kind of vocabulary at run-time, simply because the
>dictionary stuff is all created and manipulated by "builtin" functions
>which any player who has a "wizard" character can access.
Yes, I can do that. A dictionary is just a mapping between words
(modulated by their parts of speech) and objects in the database (where
"object" includes things like functions and commands, as well as normal
pick-it-up objects).
Richard - (fwd) command parsers: a modest proposa Adam J. Thornton
- Affordances and social method (Was: Wi Michael.Willey@abnamro.com
- Affordances and social method (Was: Wi Todd Lair
- MapMaker S. Patrick Gallaty
- (fwd) command parsers: a modest proposa Chris Gray
- My "mud" server, A.T.O.M. and the coming design notes Mike L Kesl
- Output Classification Notes, version 061098 Mike L Kesl
- Output Classification Notes, version 061098 CJones@aagis.com
- Output Classification Notes, version 061098 J C Lawrence
- Output Classification Notes, version 061098 Vadim Tkachenko
- Output Classification Notes, version 061098 Ben Greear
- Output Classification Notes, version 061098 Chris Gray
- Output Classification Notes, version 061098 J C Lawrence
- Universe Design Notes, version 061098 Mike L Kesl
- Universe Design Notes, version 061098 Chris Gray
- Universe Design Notes, version 061098 Mike L Kesl
- Universe Design Notes, version 061098 J C Lawrence
- Universe Design Notes, version 061098 s001gmu@nova.wright.edu
- World Creation Notes, version 061098 Mike L Kesl
- World Creation Notes, version 061098 Chris Gray
- World Creation Notes, version 061098 Mike L Kesl
- World Creation Notes, version 061098 J C Lawrence
- (fwd) command parsers: a modest proposa Richard Bartle
- Alternate UOL's J C Lawrence
- Alternate UOL's S. Patrick Gallaty
- Alternate UOL's Felix A. Croes
- Alternate UOL's Jason Goodwin
- Alternate UOL's Ben Greear
- Alternate UOL's Felix A. Croes
- Alternate UOL's J C Lawrence
- Alternate UOL's D. B. Brown
- Alternate UOL's Adam Wiggins
- Alternate UOL's Koster, Raph
- Alternate UOL's D. B. Brown
- Alternate UOL's Koster, Raph
- Alternate UOL's Nathan F Yospe
- Alternate UOL's Damion Schubert
- Alternate UOL's Damion Schubert
- Alternate UOL's J C Lawrence
- Alternate UOL's Adam J. Thornton
- Support for remote NPCs Joel Kelso
- Support for remote NPCs Nathan F Yospe
- Affordances and social method Jon A. Lambert
- Affordances and social method Marian Griffith
- Affordances and social method Jon A. Lambert
- Affordances and social method Marian Griffith
- Affordances and social method J C Lawrence
- [Fwd: brainstormer] Richard Woolcock
- Physics Lesson John Bertoglio
- Physics Lesson Mike Sellers
- Physics Lesson Ling
- (fwd) command parsers: a modest proposa Chris Gray
- Affordances and social method (Was: Wire d Magazine...) Chris Gray
- Affordances and social method (Was: Wire d Magazine...) Adam Wiggins
- Affordances and social method (Was: Wire d Magazine...) S. Patrick Gallaty
- Affordances and social method (Was: Wire d Magazine...) Koster, Raph
- Affordances and social method (Was: Wired Magazine...) Damion Schubert
- Affordances and social method (Was: Wire d Magazine...) J C Lawrence
- Affordances and social method (Was: Wire d Magazine...) J C Lawrence
- META: MUD-Dev is a NewHoo "Cool Site" J C Lawrence
- Biomass project Joel Kelso
- Affordances and social method (Was: Wi Koster, Raph
- Affordances and social method (Was: Wi Dr. Cat
- Affordances and social method (Was: Wi Koster, Raph
- Affordances and social method (Was: Wi Dr. Cat
- Affordances and social method (Was: Wi J C Lawrence
- Affordances and social method (Was: Wi Jon A. Lambert
- Affordances and social method (Was: Wi Jon A. Lambert
- Affordances and social method (Was: Wi J C Lawrence
- Affordances and social method (Was: Wi Holly Sommer
- Affordances and social method (Was: Wi s001gmu@nova.wright.edu
- Affordances and social method (Was: Wi quzah
- Affordances and social method (Was: Wi J C Lawrence
- Affordances and social method (Was: Wi s001gmu@nova.wright.edu
- Affordances and social method (Was: Wi Dan Shiovitz
- Affordances and social method (Was: Wi T. Alexander Popiel
- Affordances and social method (Was: Wi Jon A. Lambert
- Affordances and social method (Was: Wi Dan Shiovitz
- Affordances and social method (Was: Wi Hans-Henrik Staerfeldt
- Affordances and social method (Was: Wi s001gmu@nova.wright.edu
- Affordances and social method (Was: Wi J C Lawrence
- Affordances and social method (Was: Re:Wired Ma gazine...) Koster, Raph
- Affordances and social method (Was: Re:Wire Michael.Willey@abnamro.com
- Amit's Games Programming Page Ling
- You think users won't number crunch and statis Holly Sommer
- You think users won't number crunch and statis Adam Wiggins
- You think users won't number crunch and statis Holly Sommer
- You think users won't number crunch and statis Adam Wiggins
- You think users won't number crunch and statis Matthew R. Sheahan
- You think users won't number crunch and statis Damion Schubert
- You think users won't number crunch... Caliban Tiresias Darklock
- [OT] Private emails Richard Woolcock
- [Java] multithreading: update and a question Vadim Tkachenko
- [Java] multithreading: update and a question Chris Gray
- [Java] multithreading: update and a question Vadim Tkachenko
- [Java] multithreading: update and a question Ben Greear
- [Java] multithreading: update and a question Vadim Tkachenko
- [Java] multithreading: update and a question J C Lawrence
- [Java] multithreading: update and a question J C Lawrence
- [Java] multithreading: update and a question Chris Gray
- [Java] multithreading: update and a question Vadim Tkachenko
- [Java] multithreading: update and a question J C Lawrence
- [Java] multithreading: update and a question Vadim Tkachenko
- [Java] multithreading: update and a question Nathan F Yospe
- [CODE RELEASE] ScryMUD, and the Hegemon Client 1.4.3 (minor release) Ben Greear
- [DESIGN] Antagonizing players Ben Greear
- [DESIGN] Antagonizing players quzah
- [DESIGN] Antagonizing players Richard Woolcock
- Job offer for multiplayer game development J C Lawrence
- Job offer for multiplayer game development S. Patrick Gallaty
- Job offer for multiplayer game development Nathan F Yospe
- Job offer for multiplayer game development Spangler, Jason
- Job offer for multiplayer game development Dr. Cat
- Job offer for multiplayer game development J C Lawrence
- Java VM performance J C Lawrence
- UBE/high: Affordances and social method (Was: Wi Dr. Cat
- [CODE] [LANGUAGE/PLATFORM SPECIFIC] My Event Engine Todd Lair
- [CODE] [LANGUAGE/PLATFORM SPECIFIC] My Event Engine Chris Gray
- [CODE] [LANGUAGE/PLATFORM SPECIFIC] My Event Engine Todd Lair
- [CODE] [LANGUAGE/PLATFORM SPECIFIC] My Event Engine oliver@jowett.manawatu.planet.co.nz
- [CODE] [LANGUAGE/PLATFORM SPECIFIC] My Event Engine s001gmu@nova.wright.edu
- [CODE] [LANGUAGE/PLATFORM SPECIFIC] My Event Engine Oliver Jowett
- [CODE] [LANGUAGE/PLATFORM SPECIFIC] My Event Engine s001gmu@nova.wright.edu
- [CODE] [LANGUAGE/PLATFORM SPECIFIC] My Event Engine Joel Kelso
- [CODE] [LANGUAGE/PLATFORM SPECIFIC] My Event Engine s001gmu@nova.wright.edu
- [CODE] [LANGUAGE/PLATFORM SPECIFIC] My Event Engine J C Lawrence
- [CODE] [LANGUAGE/PLATFORM SPECIFIC] My Event Engine Adam Wiggins
- [CODE] [LANGUAGE/PLATFORM SPECIFIC] My Event Engine J C Lawrence
- [CODE] [LANGUAGE/PLATFORM SPECIFIC] My Event Engine Todd Lair
- [CODE] [LANGUAGE/PLATFORM SPECIFIC] My Event Engine s001gmu@nova.wright.edu
- [CODE] [LANGUAGE/PLATFORM SPECIFIC] My Event Engine J C Lawrence
- [CODE] [LANGUAGE/PLATFORM SPECIFIC] My Event Engine Chris Gray
- [CODE] [LANGUAGE/PLATFORM SPECIFIC] My Event Engine T. Alexander Popiel
- [CODE] [LANGUAGE/PLATFORM SPECIFIC] My Event Engine Chris Gray
- [CODE] [LANGUAGE/PLATFORM SPECIFIC] My Event Engin Jon A. Lambert
- Scripting Design Notes Mike L Kesl
- Scripting Design Notes Chris Gray
- Scripting Design Notes Vadim Tkachenko
- Scripting Design Notes Jo Dillon
- Scripting Design Notes Chris Gray
- Login and Accounts Mike L Kesl
- Login and Accounts quzah
- Login and Accounts Matt Chatterley
- Login and Accounts Ling
- Login and Accounts Matt Chatterley
- Login and Accounts J C Lawrence
- Design Patterns for Concurrent, Parallel, and Distributed Systems Alex Oren
- DBMS in MU*'s Jeroen Ruigrok/Asmodai
- DBMS in MU*'s Adam J. Thornton
- DBMS in MU*'s Jeroen Ruigrok/Asmodai
- DBMS in MU*'s Adam J. Thornton
- DBMS in MU*'s quzah
- DBMS in MU*'s s001gmu@nova.wright.edu
- DBMS in MU*'s quzah
- DBMS in MU*'s Adam J. Thornton
- DBMS in MU*'s Jeroen Ruigrok/Asmodai
- DBMS in MU*'s J C Lawrence
- DBMS in MU*'s quzah@geocities.com
- DBMS in MU*'s Chris Gray
- DBMS in MU*'s The Arrow
- DBMS in MU*'s J C Lawrence
- DBMS in MU*'s Ola Fosheim Grøstad
- DBMS in MU*'s Ross Nicoll
- DBMS in MU*'s Chris Gray
- DBMS in MU*'s s001gmu@nova.wright.edu
- DBMS in MU*'s Adam Wiggins
- DBMS in MU*'s J C Lawrence
- DBMS in MU*'s Jon A. Lambert
- DBMS in MU*'s J C Lawrence
- DBMS in MU*'s s001gmu@nova.wright.edu
- DBMS in MU*'s Chris Gray
- Network Connectivity Jeroen Ruigrok/Asmodai
- Network Connectivity T. Alexander Popiel
- Network Connectivity Matt Chatterley
- Affordances and social method Hans-Henrik Staerfeldt
- WIRED: Kilers have more fun Matthew R. Sheahan
- Overworld Maps on diku style Muds- Design notes Katrina McClelan
- Overworld Maps on diku style Muds- Design notes Richard Woolcock
- Overworld Maps on diku style Muds- Design notes Katrina McClelan
- WIRED: Kilers have more fun Chris Gray
- WIRED: Kilers have more fun Caliban Tiresias Darklock
- Informix releases free version for Linux J C Lawrence
- Objects (was DBMS in MU*'s) s001gmu@nova.wright.edu
- OT: Sid Meier s001gmu@nova.wright.edu
- More on Informix Linux release J C Lawrence
- WIRED: Kilers have more fun Koster, Raph
- WIRED: Kilers have more fun S. Patrick Gallaty
- WIRED: Kilers have more fun Caliban Tiresias Darklock
- WIRED: Kilers have more fun Nathan F Yospe
- Fun vs Realism [ Was: OT: Sid Meier ] Leach, Brad BA
- Fun vs Realism [ Was: OT: Sid Meier ] Caliban Tiresias Darklock
- Fun vs Realism [ Was: OT: Sid Meier ] Nathan F Yospe
- Fun vs Realism [ Was: OT: Sid Meier ] Caliban Tiresias Darklock
- Fun vs Realism [ Was: OT: Sid Meier ] Markku Nylander
- Fun vs Realism [ Was: OT: Sid Meier ] Nathan F Yospe
- Fun vs Realism [ Was: OT: Sid Meier ] Adam Wiggins
- Fun vs Realism [ Was: OT: Sid Meier ] Brandon J. Rickman
- Fun vs Realism [ Was: OT: Sid Meier ] Damion Schubert
- Fun vs Realism [ Was: OT: Sid Meier ] Caliban Tiresias Darklock
- Fun vs Realism [ Was: OT: Sid Meier ] Adam Wiggins
- Fun vs Realism [ Was: OT: Sid Meier ] Damion Schubert
- Fun vs Realism [ Was: OT: Sid Meier ] Caliban Tiresias Darklock
- Fun vs Realism [ Was: OT: Sid Meier ] Adam J. Thornton
- Fun vs Realism [ Was: OT: Sid Meier ] Damion Schubert
- Fun vs Realism [ Was: OT: Sid Meier ] Brandon J. Rickman
- Fun vs Realism [ Was: OT: Sid Meier ] Koster, Raph
- Fun vs Realism [ Was: OT: Sid Meier ] Brandon J. Rickman
- Fun vs Realism [ Was: OT: Sid Meier ] J C Lawrence
- Fun vs Realism [ Was: OT: Sid Meier ] Adam Wiggins
- Fun vs Realism [ Was: OT: Sid Meier ] Damion Schubert
- Fun vs Realism [ Was: OT: Sid Meier ] Adam Wiggins
- Fun vs Realism [ Was: OT: Sid Meier ] Chris Gray
- The Eternal City on The Big Network Mike Sellers
- WIRED: Kilers have more fun Marian Griffith
- WIRED: Kilers have more fun Chris Gray
- WIRED: Kilers have more fun Caliban Tiresias Darklock
- WIRED: Kilers have more fun Marian Griffith
- WIRED: Kilers have more fun Koster, Raph
- WIRED: Kilers have more fun Caliban Tiresias Darklock
- WIRED: Kilers have more fun Marian Griffith
- WIRED: Kilers have more fun Adam Wiggins
- WIRED: Kilers have more fun J C Lawrence
- WIRED: Kilers have more fun quzah
- WIRED: Kilers have more fun Koster, Raph
- WIRED: Kilers have more fun Adam Wiggins
- WIRED: Kilers have more fun Damion Schubert
- WIRED: Kilers have more fun quzah
- WIRED: Kilers have more fun Marian Griffith
- WIRED: Kilers have more fun Damion Schubert
- Ansii color, needing some specs and or pointers. Ben Greear
- Ansii color, needing some specs and or pointers. Caliban Tiresias Darklock
- Ansii color, needing some specs and or pointers. Caliban Tiresias Darklock
- Ansii color, needing some specs and or pointers. Scatter
- Ansii color, needing some specs and or pointers. Caliban Tiresias Darklock
- Ansii color, needing some specs and or pointers. Vadim Tkachenko
- Ansii color, needing some specs and or pointers. Jo Dillon
- Ansii color, needing some specs and or pointers. Chris Gray
- Ansii color, needing some specs and or pointers. S. Patrick Gallaty
- Ansii color, needing some specs and or pointers. Robert Woods
- Ansii color, needing some specs and or pointers. S. Patrick Gallaty
- Ansii color, needing some specs and or pointers. Katrina McClelan
- Ansii color, needing some specs and or pointers. J C Lawrence
- Ansii color, needing some specs and or pointers. karp@svconsult.com
- Ansii color, needing some specs and or pointers. Ben Greear
- Ansii color, needing some specs and or pointers. Ross Nicoll
- Ansii color, needing some specs and or pointers. Chris Gray
- WIRED: Kilers have more fun Chris Gray
- PANARD VISION -- 3D-Real-Time Portable Engine J C Lawrence
- Affordances and social method Leach, Brad BA
- Affordances and social method S. Patrick Gallaty
- Affordances and social method quzah
- Affordances and social method Leach, Brad BA
- Affordances and social method Robert Woods
- Affordances and social method Orion Henry
- Affordances and social method S. Patrick Gallaty
- Affordances and social method Mike Sellers
- Affordances and social method Joel Kelso
- Affordances and social method Caliban Tiresias Darklock
- Affordances and social method Mike Sellers
- Affordances and social method Jon A. Lambert
- Affordances and social method s001gmu@nova.wright.edu
- Affordances and social method J C Lawrence
- (subject missing) J C Lawrence
- User inventions (was:killers have more...) Ola Fosheim Grøstad
- User inventions (was:killers have more...) Caliban Tiresias Darklock
- User inventions (was:killers have more...) Matt Chatterley
- Unix vs NT and its relation to MUD environments. J C Lawrence