curiousdannii-testing
commented
2 years ago 557058:4c095ffd-6d6f-47ce-9e73-77c613347b86:
Comment by zarf :
I see two separate issues in your example.
- You expect "while examining" to work in a parser error rule, but it doesn't. "While examining" and "when the current action is examining" are both false during parsing. Since you've exposed the action_to_be variable, you could write a condition "when parser action-to-be is examining".
- Your first and second rule are judged equally specific even though one of them has a two-part ("and") condition. I don't know if this is wrong; I don't know all the ins and outs of the rulebook compiler. I'll leave it to Graham to say.
Reported by : otistdog
Description :
It looks like the "for printing a parser error" activity should be capable of checking the state of action_to_be (similar to other activities that happen during parsing), but it does not seem to do so in execution of appropriate rules. The generated rulebook specificity listing does not show a higher preference for rules that include a "while" clause vs. those that don't.
In contrast, rules that would require a fully-formed action do seem to be be given higher specificity, even though they will not evaluate as naively expected (similar to other activities that happen during parsing).
Steps to reproduce :
"Test" Place is a room. Parser action-to-be is an action name that varies. The parser action-to-be variable translates into I6 as "action_to_be". Rule for printing a parser error when the latest parser error is the can't see any such thing error: say " The what now?"
Rule for printing a parser error while examining when the latest parser error is the can't see any such thing error:
say "Can't see that thingy, so can't look at it closer (action name version)."
Rule for printing a parser error when the current action is examining something and the latest parser error is the can't see any such thing error:
say "Can't see that thingy, so can't look at it closer (full action version)." [Note that this rule is acknowledged to have an improper preamble for the activity; see "Additional Information"]
Test me with "x cow".
Additional information :
Output from "test me":
============================
Place
>test me
(Testing.)
>[1] x cow
The what now?
============================
You can see that action_to_be is set in a way valid for comparison. However, the generated I6 includes:
! ----------------------------------------------------------------------------------------------------
! Rules in rulebook: for Printing a parser error (B95_for_printing_a_parser_er)
! ----------------------------------------------------------------------------------------------------
! Rule 1/3 ! Rule for printing a parser error when the current action is examining something and the latest parser error is the can't see any such thing error:
! >>> III - When/while requirement >>>
! Rule 2/3 ! Rule for printing a parser error when the latest parser error is the can't see any such thing error:
! === equally specific with ===
! Rule 3/3 ! Rule for printing a parser error while examining when the latest parser error is the can't see any such thing error:
! ----------------------------------------------------------------------------------------------------
Based on that, it looks like the improper rule requiring a fully-formed action is given highest specificity, while the other two rules are judged equally specific, even though one does actually check for the partial action:
============================
! No specific request
! Rule for printing a parser error when the latest parser error is the can't see any such thing error:
[ R_777 ;
if ((((((etype == I83_can_t_see_any_such_thing))))))
{ ! Runs only while condition holds if (debug_rules) DB_Rule(R_777, 777); ! [1: say ~<action-to-be = [parser action-to-be]> The what now?~] say__p=1;ParaContent(); print " The what now?"; new_line; .L_Say6; .L_SayX6;
RulebookSucceeds(); rtrue;
}
else if (debug_rules > 1) DB_Rule(R_777, 777, 'context');
rfalse;
];
! No specific request
! Rule for printing a parser error while examining when the latest parser error is the can't see any such thing error:
[ R_778 ;
if (((((((action ==##Examine) && (actor==player) && (self=actor,true) && (((etype == I83_can_t_see_any_such_thing)))))))))
{ ! Runs only while condition holds if (debug_rules) DB_Rule(R_778, 778); ! [1: say ~Can't see that thingy, so can't look at it closer (action name version).~] say__p=1;ParaContent(); print "Can't see that thingy, so can't look at it closer (action name version)."; new_line; .L_Say7; .L_SayX7; RulebookSucceeds(); rtrue; }
else if (debug_rules > 1) DB_Rule(R_778, 778, 'context');
rfalse;
];
============================
Per WWI 18.3, only "the most specific" for rule is selected, which in this case I would think would be the "... while examining..." version. However, this is not the case, even when the improper version evaluating the fully-formed current action is removed. Therefore, my guess is that this is at root a specificity-evaluation issue, so I'm entering this under "compiles but misbehaves".
imported from: [Mantis 1802] Rule for printing a parser error does not acknowledge "while