October 1997
- Carnage, scripting newbie guides Koster, Raph
- Carnage, scripting newbie guides Nathan Yospe
- Carnage, scripting newbie guides Chris Gray
- Carnage, scripting newbie guides ##Make Nylander
- Carnage, scripting newbie guides ##Make Nylander
- Usability and interface and who the hell is supposed to clawrenc@cup.hp.com
- 101 Spells Not Worth Memorizing clawrenc@cup.hp.com
- more classes (Usability and interface and who the Brian Price
- more classes (Usability and interface and who the Matt Chatterley
- more classes (Usability and interface and who the coder@ibm.net
- Stranger in a Strange Land (was Usability and interface and Maddy
- Tablets. Ola Fosheim Grøstad
- Stranger in a Strange Land (was Usability and interface clawrenc@cup.hp.com
- Usability and interface ... Marian Griffith
- Usability and interface ... Caliban Tiresias Darklock
- Usability and interface ... Broly
- Usability and interface ... Caliban Tiresias Darklock
- Usability and interface ... Derrick Jones
- Usability and interface ... coder@ibm.net
- Usability and interface ... Derrick Jones
- Usability and interface ... coder@ibm.net
- Usability and interface ... coder@ibm.net
- Usability and interface ... Marian Griffith
- Turn-based Combat Jon A. Lambert
- Turn-based Combat Travis Casey
- Turn-based Combat John G.
- OT: I'm moving! coder@ibm.net
- (fwd) New mud release coder@ibm.net
- Riddles for games clawrenc@cup.hp.com
- Riddles for games Chris Gray
- Riddles for games coder@ibm.net
- The Trap Collection clawrenc@cup.hp.com
- Learning through failure Jon A. Lambert
- Learning through failure Maddy
- The Trap Collection - Volume II clawrenc@cup.hp.com
- THE COMPLETE GUIDE TO UNLAWFUL CARNAL KNOWLEDGE FOR FANTASY ROLE-PLAYING GAMES clawrenc@cup.hp.com
- (fwd) New MUD software wanted? coder@ibm.net
- (fwd) New MUD software wanted? Felix A. Croes
- (fwd) New MUD software wanted? coder@ibm.net
- META: File attachments as list postings. coder@ibm.net
- More Riddles... Jon A. Lambert
- More Riddles... Jon A. Lambert
- multiple intelligences Brandon J. Rickman
- multiple intelligences Travis Casey
- multiple intelligences Brandon J. Rickman
- multiple intelligences S001GMU@nova.wright.edu
- multiple intelligences Travis S. Casey
- multiple intelligences coder@ibm.net
- OT: Usability and interface and who the hell is suppo coder@ibm.net
- Fear of magic (was:Usability and interface) Derrick Jones
- Fear of magic (was:Usability and interface) Michael Hohensee
- Fear of magic (was:Usability and interface) coder@ibm.net
- The Official T$R Book of Adventure Suggestions coder@ibm.net
- Mud governance Koster, Raph
- Mud governance Felix A. Croes
- Mud governance Mike Sellers
- Mud governance Travis Casey
- Mud governance coder@ibm.net
- Mud governance Mike Sellers
- Mud governance coder@ibm.net
- Mud governance S001GMU@nova.wright.edu
- Mud governance coder@ibm.net
- Mud governance Koster, Raph
- Mud governance coder@ibm.net
- OT: Usability and interface and who the hell is su Jon A. Lambert
- Fear of magic (was:Usability and interface) Marian Griffith
- Fear of magic (was:Usability and interface) Derrick Jones
- Fear of magic (was:Usability and interface) coder@ibm.net
- Fear of magic (was:Usability and interface) Nathan Yospe
- Fear of magic (was:Usability and interface) Marian Griffith
- Fear of magic (was:Usability and interface) Sauron
- Fear of magic (was:Usability and interface) coder@ibm.net
- Fear of magic (was:Usability and interface) Marian Griffith
- Fear of magic (was:Usability and interface) coder@ibm.net
- Fear of magic (was:Usability and interface) Brandon J. Rickman
- Fear of magic (was:Usability and interface) Derrick Jones
- Fear of magic (was:Usability and interface) Jon A. Lambert
- Fear of magic (was:Usability and interface) Adam Wiggins
- Fear of magic (was:Usability and interface) Derrick Jones
- Fear of magic (was:Usability and interface) Derrick Jones
- Fear of magic (was:Usability and interface) Derrick Jones
- Fear of magic (was:Usability and interface) coder@ibm.net
- Fear of magic (was:Usability and interface) coder@ibm.net
- Fear of magic (was:Usability and interface) Sauron
- Fear of magic (was:Usability and interface) Marian Griffith
- Fear of magic (was:Usability and interface) Marian Griffith
- Fear of magic (was:Usability and interface) Jon A. Lambert
- Fear of magic (was:Usability and interface) coder@ibm.net
- Fear of magic (was:Usability and interface) Vadim Tkachenko
- Fear of magic (was:Usability and interface) Sauron
- Fear of magic (was:Usability and interface) Stephen Zepp
- Fear of magic (was:Usability and interface) Matt Chatterley
- Fear of magic (was:Usability and interface) Vadim Tkachenko
- Fear of magic (was:Usability and interface) Stephen Zepp
- Fear of magic (was:Usability and interface) coder@ibm.net
- Fear of magic (was:Usability and interface) Matt Chatterley
- Fear of magic (was:Usability and interface) coder@ibm.net
- Fear of magic (was:Usability and interface) Alex Oren
- Fear of magic (was:Usability and interface) Alex Oren
- Fear of magic (was:Usability and interface) Koster, Raph
- Fear of magic (was:Usability and interface) Chris Gray
- Fear of magic (was:Usability and interface) Richard Woolcock
- Fear of magic (was:Usability and interface) Stephen Zepp
- META: List burp coder@ibm.net
- To catch a mage (was fear of magic) Derrick Jones
- To catch a mage (was fear of magic) Matt Chatterley
- To catch a mage (was fear of magic) coder@ibm.net
- To catch a mage (was fear of magic) coder@ibm.net
- To catch a mage (was fear of magic) Derrick Jones
- To catch a mage (was fear of magic) coder@ibm.net
- To catch a mage (was fear of magic) Derrick Jones
- To catch a mage (was fear of magic) coder@ibm.net
- CODE RELEASE: [mush mux] Portable Space Engine v0.8.3 RELEASED! coder@ibm.net
- ANNOUNCEMENT: [graphical commercial] Mystic Realms coder@ibm.net
- CODE RELEASE: [server] New Mud Software (SunderMUD 1.0) coder@ibm.net
- string parsing Felix A. Croes
- string parsing Chris Gray
- string parsing Felix A. Croes
- string parsing Jon A. Lambert
- string parsing Felix A. Croes
- string parsing Chris Gray
- string parsing Felix A. Croes
- string parsing Chris Gray
- string parsing Felix A. Croes
- string parsing Chris Gray
- string parsing coder@ibm.net
- string parsing Felix A. Croes
- string parsing coder@ibm.net
- string parsing Chris Gray
- string parsing coder@ibm.net
- string parsing Chris Gray
- string parsing coder@ibm.net
- string parsing Jon A. Lambert
- string parsing Adam Wiggins
- string parsing Ola Fosheim Grøstad
"Felix A. Croes" <felix@xs1.simplex.nl> wrote:
>What follows is a description of something I am currently implementing
>for my server. I am providing it here for others to comment on. Also,
>I'd like to hear of other approaches to the same problem.
Hi Felix, I salute your effort in trying to introduce more intelligent
grammarbased parsing to LPC. (hopefully you take advantage of the
freely available libraries for regexp's etc)
I am currently sketching ways of using grammars for *generating*
output, as opposed to the more traditional parsing of input. Have you
considered to include this in your work? As you are working with a
textbased system I think this could be useful for programming NPC
behaviour or at the very least to aid the simulation meaningful
talking.
> Thing: Noun
> Thing: ( Adjs ) Noun
> Noun: word
> Adjs: word Adjs
> Adjs: word
>
>parse_string(grammar, "bottle") will return
>
> ({ "bottle" }),
Uhm, shouldn't it return that "bottle" is a *Thing* ? Isn't that the point
with parsing? Sortof? I guess I missed you somewhere...
>breadth-first LR(k) parsing algorithm. Next, any LPC functions specified
>for rules are called (bottom-up), and the intermediate parse trees for
>those rules are replaced by the return values of those functions. As
>a special case, if the LPC function returns zero, the entire parse tree
>that this intermediate parse tree is part of is discarded. Finally,
>the resulting parse tree(s) are returned.
So your functioncalls are a mixture of a "generating rule" and a
"production rule"? Won't you "loose" some information in the process
in the case of user errors, or is that the responsibility of the
function being called? I'm probably misinterpreting you, parserdesign
is not my primary interst although I have some interests in the field.
I suppose you could do the following if your functioncalls accept
"empty" as input. I am thinking along the lines of doing matching
against the results of NPC functioncalls, making programming of
default values easier. I think you would make the parser a lot more
powerful by adding some kind of context sensitivity . (I have not
checked to see if the grammar is correct (probably needs some
rewriting or additions) or parsable and think more of usage than
implementation :-)
KILLACTION = 'kill' KILLOBJECT KILLWEAPON
KILLOBJECT = &assert_killable(&find_closest_object(OBJECT)) //1. pri
KILLOBJECT = &assert_killable(&find_reachable_object(OBJECT)) // 2nd
KILLOBJECT = &assert(&find_any_killable_in_room())
KILLOBJECT = &raise_no_killable_exception(OBJECT)
KILLOBJECT = &raise_no_killable_in_room_exception()
KILLWEAPON = 'with' WEAPON
KILLWEAPON = &assert(&find_weapon($player)) //assert flags empty as nonmatch
KILLWEAPON = &raise_no_weapon_exception(ANYTHING)
Or even
DOACTION = 'do something with' OBJECT
OBJECT = KILLOBJECT
OBJECT = KISSOBJECT
OBJECT = OTHEROBJECT
KILLOBJECT = &assert_killable(&find_object(OBJECT)) // 1st priority
KISSOBJECT = &assert_is_pretty_girl(&find_living(PERSON))// 2nd
The input 'do something with Lisa' would then yield:
({ 'DOACTION', ({ 'KISSOBJECT', OBJ('Lisa') }) })
Then apply some rewriterules and hopefully you'll end up with
({ 'KISS', ({ KISSOBJECT, OBJ('Lisa') }) })
or maybe
({ 'KISS', OBJ('Lisa') })
of course, on a playerkiller Mud Lisa would become a KILLOBJECT :-)
Therefore the priority of productions should be probably be context
sensitive in a globale sense (kill if unhappy, kiss if happy ;-) and
put on a separate layer. Maybe one should add stuff for measuring
distance between two valid interpretation. What I mean by this is to
add some functionality that would flag the difference between KISS and
KILL as unacceptable but the difference between HUG and KISS as
acceptable..
I guess the rewrite stuff could be included in the parserlanguage
design... The assert_* functions are additional context rules, should
probably have a different syntax. The raise_ functions should probably
be related to the failed asserts on a separate layer... Ugh...
>the player should probably be notified about the ambiguity.
Or even better, but much more advanced, give the user feedback of the
parsing during entering of input:
types: kill<tab>
output: 'kill' (myself|green troll|blue troll) with (fist|knife|hammer)
types: kill gre<tab>
output: 'kill green troll with' (fist|knife|hammer)
etc.
By adding contextsensitivity it should also be able to narrow down the
choices of weapons by considering the monster at hand.
Please read this message as a 'what if...' or 'maybe you could...'
reply. Don't tell me you can't implement this, I' not going to help
you (heeh), but I'm sure somebody on this list has done something
similar. Besides you didn't ask for _useful_ comments :^)
Ola. - string parsing Chris Gray
- string parsing Felix A. Croes
- string parsing Nathan Yospe
- string parsing Felix A. Croes
- string parsing Nathan Yospe
- string parsing coder@ibm.net
- string parsing Chris Gray
- string parsing Nathan Yospe
- string parsing Chris Gray
- string parsing coder@ibm.net
- Idea: Hive-mind monster coder@ibm.net
- Idea: Hive-mind monster Adam Wiggins
- Idea: Hive-mind monster coder@ibm.net
- Idea: Hive-mind monster Sauron
- Idea: Hive-mind monster Derrick Jones
- Idea: Hive-mind monster Michael Hohensee
- Idea: Hive-mind monster Brandon J. Rickman
- Idea: Hive-mind monster coder@ibm.net
- Idea: Hive-mind monster Derrick Jones
- Idea: Hive-mind monster coder@ibm.net
- Idea: Hive-mind monster coder@ibm.net
- Idea: Hive-mind monster coder@ibm.net
- Skill Listing - Part II Jon A. Lambert
- Skill Listing - Part II Derrick Jones
- Skill Listing - Part I Jon A. Lambert
- Poison List - Part II Jon A. Lambert
- Poison List - Part III Jon A. Lambert
- Poison List - Part IV Jon A. Lambert
- Poison List - Part I Jon A. Lambert