I7: I am subverting the "G" command unintentionally (solved)

Authoring Inform 7
1

The code below subverts the “G” command.

[code]“shortcircuit” by Andrew Schultz

room 1 is a room.

after reading a command:
if the player’s command includes “xyzzy”:
say “A voice booms ‘That is a [one of][or]really [stopping]tired old joke!’”;
follow the every turn rules instead;

test oops with “x me/xyzzy/g”
[/code]

I expect the test to say ‘That is a really tired old joke!’ but instead it examines the player (command before-before.)

I suspect the problem is, I’m not following certain rules or telling inform to. My guess, the every turn rules, didn’t work.

Any suggestions? This code seems rickety, but a more complex version is in my wordplay game(s). So it’s tricky to find a better way to do things & I’m not sure if it’s worth it.

2

I think what’s happening is that AGAIN refers to the previous action, not the previous command, and when you forestall the action sequence with an ‘after reading a command’ rule, the previous action never gets changed.

3

Good point–I oversimplified my actual source. The below also tries to “G” X ME instead.

[code]“shortcircuit” by Andrew Schultz

room 1 is a room.

xyzzying is an action applying to nothing.

carry out xyzzying:
say “A voice booms ‘That is a [one of][or]really [stopping]tired old joke!’”;

after reading a command:
if the player’s command includes “xyzzy”:
try xyzzying;
follow the every turn rules instead;

test oops with “x me/xyzzy/g”[/code]

The every turn rules come before the generate action rule, which asks me if I want to quit if I put it in “after reading a command.”

I’ve tried others after xyzzying, but with no luck. So I think I’m just missing a semi-obvious rule here.

4

If the reading-a-command activity is stopped, the parser considers the input to have been rejected, and loops back to the command prompt. It skips all of the parser activity, which includes recording the command buffer for “again” purposes.

I think what you want is to ‘change the text of the player’s command to “xyzzy”’, and then let the parser continue normally. (And add a line about ‘Understand “xyzzy” as xyzzying.’)

5

Ah-ha…this explanation of skipping the parser activity also explains behavior I’d seen elsewhere in my game.

The actual code looks through a table of possible commands and tokens and checks for matches & deconstructing it into 100+ separately defined actions would be awkward–especially since I don’t want to risk spoiling a magic-word verb early. But your advice gave me the idea to kick this code to the “Rule for printing a parser error when the latest parser error is the didn’t understand error:” block.

That seems to make more sense with what I want to do, and it cuts down on the time to parse through any old command.

I had blinders on thinking I had to put the parsing loop in “after reading a command” and not a parser error, because what I wanted to do was the opposite of a parser error, so I assumed it couldn’t go in the parser error code.

Your comment also tipped me off to look in Parser.i6t for the “g” code. I’d not looked much at the reserve files, having been generally intimidated, & the documentation is impressive. So thanks very much again!

(Incidentally, the table/code looks like this. I suppose I could define a topic, charges, disappearing, etc., but a table is easier to track:)

repat through table of magic-verbs:
  if item-to-see entry is visible and player's command includes "[magic-word entry]" and can-operate-rule entry succeeds:
    try magicking the item-to-see entry;

table of magic-verbs
item-to-see  magic-word  does-it-disappear  charges  can-operate-rule
potion  "glug"  false  5   can-identify-poisonous-potions rule
wand   "zzzap/zzap/zap"    false   7  trained-with-wand rule
wizard's hat  "presto"    false    8  trivially-true rule
scroll    "gnusto"  true  1  trivially-true rule
(100 more entries)