I thought it would be straightforward and neat if I could get the parser to accept synonyms from the player for certain commands; maybe typos the player uses a lot, or flavor words (ie. “fry” instead of “cook”).
I rather expected I could give each action a list of indexed text or a table with indexed text, and have it understand those entries, and then change/update those entries during play. It wouldn’t be infinitely flexible, but I thought a few synonyms would be fun for the player, maybe even make it a bit easier for some ESL folks.
Unfortunately, I can’t even get the thing off the ground. Inform does not like this idea AT ALL. It does not like it in a list, or a table, or in a box, or with a fox, or - ahem. Sorry. (Young niece.) I know 16.1 says that the first word of an action needs to be hardcoded and not a substitution, but I rather thought that was for the foundation action, not all the synonyms. I guess that’s wrong?
This is clearly a fluff thing, and not a Serious Feature, but I’m wondering what the limitation is about. Is it preventative, or is there some interp feature that needs the action commands set ahead of time?
The good news is that this ridiculous and hackish attempt seems to produce the desired result [EDIT: Oh, crap, it doesn’t; it only seems to because “frozzle” is understood as the frozzle without reference to the frozzle-list]:
[code]Lab is a room.
Frizzling is an action applying to one thing. Understand “frizzle [something]” as frizzling.
Frozzling is an action applying to two things. Understand “[frozzle] [something]” as frozzling.
The Frozzle-list is a list of snippets that varies.
The frozzle is a backdrop. It is scenery. It is everywhere. Understand “[text]” as the frozzle when the topic understood is listed in the frozzle-list.
Instead of doing anything when the current action involves the frozzle:
if the current action is frozzling:
continue the action;
otherwise:
say “Frozzle wozzle?”
Booing is an action applying to one topic. Understand “boo [text]” as booing.
Carry out booing:
Add the topic understood to the frozzle-list;
say “’[The topic understood]’ is now an acceptable synonym for frizzling, though it will produce a run-time error.”
The grunion is in the lab.
Carry out frizzling:
say “You frizzle [the noun].”
Carry out frozzling:
try frizzling the second noun.
Test me with “frizzle grunion/boo frozzle/frozzle grunion”.[/code]
The bad news is that – well, the bad news is probably that this is ridiculous and hackish, but the other bad news is that it also produces run-time errors. Still, the grunion gets frizzled. (Another problem is that I can’t figure out how to make the frozzle-list start out nonempty; “The frozzle-list is usually {“frumple”}” doesn’t compile, because the compiler thinks “frumple” is a text rather than a snippet.)
Probably the best way to do what you want is with an “After reading the command,” though I think that would be what your niece would probably call “icky.”
Also, I’m not sure exactly what 16.1 is trying to say, but the first word of your “understand” can definitely be a bracketed token; my IF demo includes “Understand “[any theme]” as keywording” and it works as desired.
I think there’s a suggestion to lift the restriction on synonyms for the first word, but until then you gotta do it the long way. Mind, there’s a syntax something like Understand the command “fry”, “simmer”, or “saute” as “cook” which allows those words wherever cook appears in other grammar lines. The double quotes are all needed.
Thanks for hacking that together! I’m trying to do as little post-command modification as possible, but I guess it’s nice to know the possibility’s open somewhere.
Yeah, and I’m adding as many of those as I can. But there’s always some borderline things, and some stuff I’m going to forget. (Am I going to remember the British spellings for everything? That seems very unlikely.) It would be nice to have a semi-customizable base, especially since saves aren’t compatible between releases. Thus, some non-USian who really wants to “organise [something]” can do so until they are ready to play a version where I’ve added the synonym. Ideally, of course, all this gets caught in beta-testing, but . . . yeah.
It will work without run-time errors if you use indexed text instead of snippets. That is, make the list a list of indexed texts, and copy the topic understood into a temporary indexed text variable before adding it to the list.
Thanks! Unfortunately I just realized that my hack doesn’t work at all; it only seems to work because “frozzle” is already understood as the frozzle, without consulting the frozzle-list. Back to the drawing board, or the “after reading a command” board.
It is sometimes possible to use bracketed tokens as the first thing in an “Understand” – “[foozle] [something]” does work here, and “[text]” works elsewhere, but I don’t know if it’s possible to dynamically add text as synonyms, since my list thing didn’t work.
On further poking, the frozzle-list in my example seems to be working as a repository for synonyms for the frozzle. If you type “boo bam” and then “x bam,” you get “Frozzle wozzle?”, as you should.
This suggests that it might be possible to use something like my code as a way to let the player create extra synonyms for nouns, if not for verbs; but it might be kind of unstable and I really have no idea what’s actually going on under the hood, so I suspect that doing “after reading a command” is safer. Also, when I tried to define a list of synonyms for the frozzle and another for the grunion, the command “frozzle grunion” led to a really ridiculous number of P37 run-time errors, so it may not be a good idea to have syntaxes where two of these understood-by-reference-to-a-list thingies can be showing up.
As you may have guessed from things like “Frozzle wozzle?”, I’m feeling a little lightheaded, so I don’t think I’m going to really try to fix this now.
That will be be the easiest way to accomplish this, I think. Mixing topics and dynamic grammar lines into the problem is going to (continue to) be a source of a headache.
It will probably always be easier for the player to learn from the parser, rather than the other way around. Even for non-native speakers.
However, I totally agree that the parser should be more adaptable to the desires of the author. One of my possible future projects is an extension that allows more I7 access to the parser’s behavior.
Thanks for the input, all. I’ll chew on this for awhile. I’ve got a couple other “after reading the player’s command” things happening, and I don’t want to throw too many monkeys into the machine.
Well, probably, yeah. But that doesn’t necessarily mean that it’s not worth the attempt.