I’m wondering if there’s a convenient way to get the parser to understand the equivalence of two different inputs. Here’s the code:
[code]Include Conversation Framework by Eric Eve.
Include Conversation Responses by Eric Eve.
Include Conversational Defaults by Eric Eve.
The Crypt is a room. Count Dracula is a man in the Crypt.
Test me with “actions / tell count to jump / count, jump”[/code]
The two commands result in different actions (answering Count Dracula that “to jump” and asking Count Dracula to try jumping). But they shouldn’t, because they’re both ways of giving an order. How might I be able to make these operate the same way, without disrupting the other functionality of Eric’s excellent extensions?
Persuasion is a special case because (as I have understood) the NPC, COMMAND syntax is hardcoded into the parser and you can’t access it easily. Example 412 in the manual has this to change TELL NPC TO X into NPC, X:
After reading a command:
let N be indexed text;
let N be the player's command;
replace the regular expression "\b(ask|tell|order) (.+?) to (.+)" in N with "\2, \3";
change the text of the player's command to N.
This is a pet peeve of mine. I feel pretty strongly about avoiding indexed text, but there are aspects of the parser that just can’t be accessed any other way (aside from rewriting one or two huge monolithic functions in the I6 code).
I don’t disagree … but as a practical matter, using indexed text is not unduly painful. It’s not like getting a root canal or something. Well, once in a while it can be, but mostly not.
As I understand it (imperfectly, in all likelihood), the whole business of text vs. indexed text is sort of a workaround for how I6 optimizes its text storage in order to accommodate the Z-machine.
As a classical musician, I find this reminiscent of the fact that parts for clarinets and trumpets are written a whole-step higher than they sound … except that some clarinet parts are written a minor third higher than they sound, and must be played on a different clarinet. It’s a living fossil.
I understand an aversion to indexed text. For my part, it annoys me to have to use regular expressions to do the job of an Understand statement. Granted that the issue doesn’t come up all that often, but having to stick all the synonyms of “ask/tell/order/beg/cajole” into a wholly different form for that one purpose… doesn’t sit well with me, I guess.
Yeah, it’s just a small niggle, and I do get the sense that the I6 code responsible for such substitution is deep magic and fairly opaque one at that, so I can understand how it may be completely different in practice. Still, given how far I7 has come from its first incarnations, part of me wonders if resolving these sorts of issues (giving the author direct control over the persuasion-stage syntax at the I7 level, that is) could be the logical next step.
It seems to me like indexed text has two completely different applications.
The first, and the one I think it is appropriate for, is output filtering. You can have a rule do some very complicated things with the text, which would be completely impossible if only chunks of compressed text were being used.
The second is input filtering. The reason this bothers me is that the underlying I6 code already has data structures for doing this, in the form of three separate buffers (the two extra ones are needed for keeping track of earlier commands in the case of disambiguation and OOPS). I think it should be possible for I7 to have access to these buffers, or maybe even to create new ones. They are not indexed text, and I don’t think they are dynamically allocated at all. It just seems like a waste to me that I6 and I7 can’t share.
One of the things on my somewhat unlikely todo list, inspired quite a bit by John Ingold’s “Disambiguation Control” and Aaron Reed’s “Smarter Parser” is to completely rewrite the main parser routines so they integrate better with I7.