March 1997
- Linear Quadtrees Carter T Shock
- Linear Quadtrees gzhang1234@yahoo.com
- q-tree stuff Chris Gray
- q-tree stuff Carter T Shock
- q-tree stuff coder@ibm.net
- Issues from the digests and Wout's list Alex Oren
- Issues from the digests and Wout's list coder@ibm.net
- Issues from the digests and Wout's list coder@ibm.net
- Issues from the digests and Wout's list coder@ibm.net
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list coder@ibm.net
- Issues from the digests and Wout's list Chris Gray
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Miroslav Silovic
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Miroslav Silovic
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list Caliban Tiresias Darklock
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Caliban Tiresias Darklock
- Issues from the digests and Wout's list Miroslav Silovic
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Caliban Tiresias Darklock
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Caliban Tiresias Darklock
- Issues from the digests and Wout's list coder@ibm.net
- Issues from the digests and Wout's list Miroslav Silovic
- Issues from the digests and Wout's list Jon A. Lambert
- Issues from the digests and Wout's list Ling
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list Chris Gray
- Issues from the digests and Wout's list Ling
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Chris Gray
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Jon A. Lambert
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list S001GMU@nova.wright.edu
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list Travis Casey
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list Jon A. Lambert
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list Ling
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list Orion Henry
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Ling
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Chris Gray
- Issues from the digests and Wout's list Jon A. Lambert
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list Jon A. Lambert
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list Chris Gray
- Issues from the digests and Wout's list Chris Gray
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list Jeff Kesselman
- ListMail dupes coder@ibm.net
- Threads, IO handling, and Event Queues Nathan Yospe
- Threads, IO handling, and Event Queues Chris Gray
- Threads, IO handling, and Event Queues coder@ibm.net
- Threads, IO handling, and Event Queues Carter T Shock
- Threads, IO handling, and Event Queues Nathan Yospe
- Threads, IO handling, and Event Queues claw@null.net
- Threads, IO handling, and Event Queues coder@ibm.net
- mud grammar (was Just a bit of musing) Carter T Shock
- mud grammar (was Just a bit of musing) Nathan Yospe
- mud grammar (was Just a bit of musing) Chris Gray
- mud grammar (was Just a bit of musing) claw@null.net
On 10/03/97 at 08:43 AM, "Carter T Shock" <ctso@umiacs.umd.edu> said: >>
From: coder@ibm.net
>> A good MUD grammar is incredibly context sensitive. A simple example is
>> the case where the presence or proximity of an object adds verbs to the
>> players. There is no need for this crap to wander thru the global
>> namespace, or even warp the general grammar.
>>
>> >As such, one should be able to whip up a command interpreter with
>> >lex/yacc. I've started on it at least a dozen times but never managed to
>> >quite finish. Is this worthwhile? Thoughts?
>>
>> Nope. That approach tends to preclude having a dynamic language where
>> users or objects can add, redefine, mutate or delete verbs and nouns
>> freely at runtime. A Very Bad Idea.
>>
>
>I think we have a misunderstanding here. There's grammar (the structure
>of a language) and then there's vocabulary (all of the individual words
>that make up the language). I agree that the vocabulary is dynamic. I
>don't think the grammar is.
>
>I'll go one step more and suggest that how you implement the various
>entities (people, critters, and objects) in your mud can influence the
>success of such an approach.
Note: I don't distinguish in any way between users (people), mobiles,
critters, objects, rooms, etc. They're all defined and treated in the
same manner, and quite potentially a single object can be any one or all
of them at the same time or change state among them. (cf earlier
discussion of The Magic Sack").
We're getting into messy territory here. There are two base arguments:
the "I want to know that PUSH will work on all buttons", and, "I want the
command language's grammar to be logically consistant across the game."
The first I think is valid, but is a social/administrative problem, not a
technological problem. I don't see MUD servers as despotic grammar
police. The tack I've taken is to make it fairly easy for someone coding
a button to grab a set of applicable verbs and supporting operation code
for their object. If they choose to, great. If they don't, leave it up
to the administration to detect/repair/handle.
The second is a Good Thing, but I'm not sure if its enforcable/codable
without either binding it into the server, or precluding users from
creating alternate grammars (eg an area which requires all commands in
Klingon with a reversed (subject/object)/(verb/noun) grammar). While the
alternate grammar bit may be of dubious value, for the me the requirement
of not binding ANYTHING game specific, such as a grammar, into the server
is absolute.
The tack I've taken is stolen from ColdX, which in turn is lifted fairly
directly from Cold, COOL, and before that MOO (tho its a long way from
Tiny*):
Everything is an object.
Objects are defined in a database.
Objects have Unique IDs.
Objects may contain methods, attributes and verb templates.
Objects may inherit from other objects (multiple inheritance).
Inheritance applies to methods, AND verb templates.
Inherited methods, and verb templates can be locally over-ridden.
Objects may define methods and verb templates as unable to be
over-ridden.
Objects may declare (virtual) methods and verb templates without
defining them.
Objects inheriting virtual methods and verb templates must define them.
A verb template is a string which defines a spcific command grammar
which is
used to match against commands. eg A template of "l?ook [at] <this>"
defined
on a dog object (note that the template is defined on the target object,
not on
the issuer) with defined names "dog", "rusty", and "fido" would match
any of
the following:
l dog
l at dog
look at dog
l rusty
l fido
l at fido
etc.
And would result in the method attached to that template being called on
the
dog object.
As such a user programming an object with a button would inherit from a
button object to get the requisite verbs and supporting code. There are
problems with this general approach however:
You quickly end up with a very large array of base objects intended as
components. (eg button object). This can present namespace and
complexity/learning curve problems (I'm coding a widget, would any of
the 800+ component objects already defined really help me here?), as
well
as the obvious documentation problems
>Lessee... in most mud worlds, the "nouns" are dynamic, but the verbs are
>not.
Not true for MUDs which support (free) user programming.
>I put nouns in quotes because often a noun/adjective pairing is
>required to uniquely identify an object (the long sword, the black sword,
>etc.).
I believe "noun phrase" is the accepted term.
>The verbs in the system are your commands. cast, throw, hit, etc.
>If we want to allow dynamic or generic verbs, now you're getting into
>natural language processing and I definitely don't want to go there. So
>there are some distinct sentence structures that emerge:
><verb> <object> "hit foo"
><verb> <object> <object> "give gold foo" "cast fireball foo"
I don't have any docs or notes here at work, but you should be able to
find some good references on the basic english-style declaritive grammars
on the Web.
Where <noun> is a noun phrase, which may consist of a series of noun
phrases joined by (implied) conjunctions, and where a noun phrase may
consist of (several) adjective(s) and a noun:
<verb>
<verb> <noun>
<verb> <noun> <adverb>
<verb> <noun> [<preposition>] <noun>
<verb> <noun> [<preposition>] <noun> <adverb>
etc.
>So the first trick is to define your grammar... establish a mapping of
>verbs to appropriate objects. We'll start with "hit". In most codes if
>you "hit foo" the code first sees what the allowable targets are for foo,
>then tries to locate a foo somewhere in the world that satisfies the
>target rules (get_person_room_vis(), get_obj_room_vis() whatever).
Not for me. I do a cyclic proximity scan from the issuer, looking for an
object with a template which matches "hit foo". The basic scanning order
is: issuer, inventory, removed inventory, items close, items nearby,
items far, and then out thru any levels of containment (room, area, etc).
>An example of where this works very nicely is with magic. Identify the
>verb "cast" as special in your lexical analyzer. Rather than
><verb> <object> <object>
>it becomes
><verb> <spell> <object>
For me:
Bubba learns a new spell "wugga".
Bubba's object now inherits from the "wugga" object, adding the
requisite
templates and methods.
Bubba enters, "cast wugga on boffo", or "wugga boffo", and gets the
expected result.
>Now the question, why bother?
>Well, first off, it can make the mud more user-friendly. Rather than
>simply reporting "huh?" on bad commands, a true parser should be able to:
>
> 1) report the exact location of the error in the command
> 2) offer up suggestions (tab completion of commands)
Hurm
Not arguing, but not clear on what I can't do here. My system violently
discourages name compleation if only due to its transactional nature
(everything is a transaction which can be rolled back). Hurm. I guess
this could fit in by putting a light weight client interface between the
connection object and the socket to allow very light-weight accessor-only
private transactions to get possible target lists. Hurm. Could get
*really* ugly fast, but it would work.
The thing I have right now (and am fairly happy with), is the old target
query:
> get bag
Do you want the:
1) Red bag
2) Tattered paper bag
3) Mouldy sack
0) Cancel command
>> 2
You take the tattered paper bag.
>Now, we could do all of this without learning lex/yacc, but doing it in
>lex/yacc gives you a standard interface.. not to mention someone else has
>written most of the ugly code for you already. Btw, the newer flavors of
>the GNU lexer/parser software (glex and bison I think) offer up a C++
>version that encapsulates the parser as an object. Nifty side effect is
>that you can have more than one. So, if you really want to screw with the
>user's minds you could conceivably have different command sets in
>different parts of your world. (something along Zelazny's Amber... the
>physics are different in the place you've warped to so the commands,
>spells, etc are different). Wait, it gets better... if we want to link up
>muds, there are ways that one mud could export its parser object to
>another so, if you wanted, you could process commands for a user in the
>remote mud locally (not sure why you'd want to, but hey.... explore the
>possibiliteis :)
cf COOL and its YO protocol.
--
J C Lawrence Internet: coder@null.net
----------(*) Internet: coder@ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith... - mud grammar (was Just a bit of musing) Chris Gray
- mud grammar (was Just a bit of musing) claw@null.net
- mud grammar (was Just a bit of musing) Chris Gray
- mud grammar Carter T Shock
- mud grammar Nathan Yospe
- mud grammar Alex Oren
- mud grammar Nathan Yospe
- mud grammar Adam Wiggins
- mud grammar Chris Gray
- Just a bit of musing (VRML) Dmitri Kondratiev
- Just a bit of musing (VRML) claw@null.net
- Room coding Nathan Yospe
- Room coding Furball
- command parsing Chris Gray
- command parsing Adam Wiggins
- command parsing claw@null.net
- Room coding S001GMU@nova.wright.edu
- Room coding Chris Gray
- Resets and repops Furball
- Resets and repops claw@null.net
- Resets and repops Jon A. Lambert
- Resets and repops claw@null.net
- Resets and repops Nathan Yospe
- Resets and repops Jon A. Lambert
- Resets and repops Nathan Yospe
- Resets and repops claw@null.net
- Resets and repops Adam Wiggins
- Resets and repops Nathan Yospe
- Resets and repops Adam Wiggins
- Resets and repops Nathan Yospe
- Resets and repops Chris Gray
- Resets and repops Chris Gray
- Resets and repops Adam Wiggins
- Resets and repops Travis Casey
- Resets and repops Chris Gray
- Resets and repops Adam Wiggins
- Resets and repops Shawn Halpenny
- Resets and repops Jeff Kesselman
- Resets and repops Chris Gray
- Resets and repops Nathan Yospe
- Resets and repops Jon A. Lambert
- Resets and repops Nathan Yospe
- Resets and repops claw@null.net
- Resets and repops claw@null.net
- Resets and repops claw@null.net
- Resets and repops claw@null.net
- Resets and repops Nathan Yospe
- Resets and repops Adam Wiggins
- Resets and repops claw@null.net
- Resets and repops Adam Wiggins
- Resets and repops claw@null.net
- Resets and repops Nathan Yospe
- Resets and repops claw@null.net
- Resets and repops Jon A. Lambert
- Resets and repops Furball
- Resets and repops Chris Gray
- Resets and repops Adam Wiggins
- Resets and repops claw@null.net
- Resets and repops Adam Wiggins
- Resets and repops claw@null.net
- Resets and repops Chris Gray
- Resets and repops claw@null.net
- Resets and repops Adam Wiggins
- Resets and repops claw@null.net
- Resets and repops Adam Wiggins
- Resets and repops claw@null.net
- Resets and repops S001GMU@nova.wright.edu
- Resets and repops coder@ibm.net
- Resets and repops S001GMU@nova.wright.edu
- Resets and repops clawrenc@cup.hp.com
- Resets and repops S001GMU@nova.wright.edu
- Resets and repops Chris Gray
- Resets and repops Nathan Yospe
- Resets and repops claw@null.net
- Resets and repops Nathan Yospe
- Resets and repops Adam Wiggins
- Resets and repops Nathan Yospe
- Resets and repops Adam Wiggins
- Resets and repops Nathan Yospe
- Resets and repops Chris Gray
- Resets and repops Nathan Yospe
- Resets and repops Chris Gray
- Resets and repops Adam Wiggins
- Resets and repops Chris Gray
- Resets and repops claw@null.net
- Resets and repops lhulbert@czn.com
- Resets and repops claw@null.net
- Resets and repops Chris Gray
- Resets and repops claw@null.net
- Resets and repops Adam Wiggins
- Resets and repops Chris Gray
- Resets and repops Chris Gray
- Resets and repops claw@null.net
- Resets and repops claw@null.net
- Resets and repops claw@null.net
- mud grammar claw@null.net
- mud grammar Nathan Yospe
- mud grammar claw@null.net
- List software claw@null.net
- List software Nathan Yospe
- List software Chris Gray
- List software claw@null.net
- List software claw@null.net
- I got your message..! MAYA DASWANI
- 3D graphics claw@null.net
- Sorry for the dups (again) coder@ibm.net
- mud grammar Jon A. Lambert
- mud grammar claw@null.net
- mud grammar Nathan Yospe
- mud grammar coder@ibm.net
- mud grammar Nathan Yospe
- mud grammar Chris Gray
- mud grammar claw@null.net
- EVOLUTION response claw@null.net
- EVOLUTION response Jon A. Lambert
- EVOLUTION response claw@null.net
- Garbage Collector Artur 'Revinor' Biesiadowski
- A perspective out of time - the mudreport document Nathan Yospe
- A perspective out of time - the mudreport document claw@null.net
- Old missing posts from old list coder@ibm.net
- Execution Chris Gray
- Mixture Furball
- Resets and repops (a really short post) claw@null.net
- Resets and repops (a really short post) Nathan Yospe
- Resets and repops (a really short post) claw@null.net
- Resets and repops (a really short post) Adam Wiggins
- Resets and repops (a really short post) claw@null.net
- Resets and repops (a really short post) Nathan Yospe
- Resets and repops (a really short post) Nathan Yospe
- Resets and repops (a really short post) <= hah! Chris Gray
- VT100 codes ... Khanone@aol.com
- VT102 codes Adam Wiggins
- VT102 codes Adam Wiggins
- VT102 codes Adam Wiggins
- Dupes coder@ibm.net
- Efficiency Chris Gray
- Event Handling Nathan Yospe
- Event handling Shawn Halpenny
- Event handling Vadim Tkachenko
- Event handling Maddy
- A brief introduction.. ok, you got me: an introduction Greg Munt
- A brief introduction.. ok, you got me: an introduction Adam Wiggins
- A brief introduction.. ok, you got me: an introduction coder@ibm.net
- Greetings. :) Michael Hohensee
- Greetings. :) claw@null.net
- Greetings. :) Nathan Yospe
- Greetings. :) Michael Hohensee
- Greetings. :) coder@ibm.net
- Greetings. :) Nathan Yospe
- Greetings. :) Chris Gray
- Greetings. :) coder@ibm.net
- Greetings. :) Chris Gray
- Greetings. :) Nathan Yospe
- Greetings. :) Jeff Kesselman
- Greetings. :) Chris Gray
- Greetings. :) Greg Munt
- Greetings. :) Jon A. Lambert
- Greetings. :) Nathan Yospe
- Greetings. :) clawrenc@cup.hp.com
- Greetings. :) Furball
- Greetings. :) Chris Gray
- Greetings. :) clawrenc@xsvr1.cup.hp.com
- Greetings. :) Shawn Halpenny
- Greetings. :) Jeff Kesselman
- Greetings. :) Shawn Halpenny
- Greetings. :) Jeff Kesselman
- Greetings. :) Shawn Halpenny
- Greetings. :) Jon A. Lambert
- Greetings. :) Jeff Kesselman
- Greetings. :) Shawn Halpenny
- Greetings. :) Jon A. Lambert
- Greetings. :) clawrenc@cup.hp.com
- Greetings. :) Jeff Kesselman