Hi,
I am facing a problem that I do not know if it can be solved at all (or with reasonable effort).
I would like to catch all inputs that are not already handled by game-specific INSTEAD OF or BEFORE rules (with the exception of EXAMINE).
The method must be able to also catch
“BLANK INPUT” (-> “I beg your pardon?”)
“kdjkajdfkakdfh” (-> “That’s not a verb I recognise.”)
“x kitchen” (-> “You can’t see any such thing”)
The Kitchen is a room.
The annoying fly is in the Kitchen.
Description of the fly is "The fly hums annoyingly through the air in unpredictable curves.".
Instead of doing something other than examining to the fly:
say "You won't get rid of the annoying fly with this[one of][or] either[stopping].".
won’t do (this is only a short example - there are many more objects and Instead rules).
Do any of you have an idea or an approach how to solve this?
A simple elegant solution would be great!
So you want to completely cut out the check/carry out/report machinery and stop processing after the before and instead stages?
This is possible by messing with the action-processing rules—specifically, you’ll want to insert a rule before the “descend to specific action-processing rule” that calls your own custom rulebook and then cancels everything. You can also short-circuit the “printing a parser error” activity and call the same rulebook.
But I have to ask, what’s your actual goal here? You say you don’t want to replace room descriptions, but room descriptions are the result of an action (looking), so I’m not sure you actually want to completely shut down Inform’s action processing. Similarly you probably don’t want to shut down SAVE or QUIT.
There’s a crucial difference of meaning between the two.
“Instead of doing anything other than examining the fly” catches any action that is not examining the fly. Looking is not examining the fly, therefore looking is caught.
“Instead of doing anything other than examining to the fly” catches any action done to the fly that is not examining. Looking is not examining, but it’s also not done to the fly, so it’s not caught.
I believe you can also write the second one as “instead of doing anything to the fly other than examining”, for clarity.
So far as the other requirements go… If you crack open the index, you can find the “printing a parser error” rule and change things up.
For instance, changing the blank input response:
Rule for printing a parser error when the latest parser error is the I beg your pardon error:
say "You must have pressed the enter key by mistake." instead.
You can change the response to unrecognized verbs in the same way:
Rule for printing a parser error when the latest parser error is the not a verb I recognise error:
say "I don't understand." instead.
e: though it seems you may want something more comprehensive. I’m pretty sure that anything I came up with would just break everything
So I’m not sure I 100% grasp what you’re trying to do, but what about doing this:
The Kitchen is a room.
The annoying fly is in the Kitchen.
Description of the fly is "The fly hums annoyingly through the air in unpredictable curves.".
The first specific action-processing rule when the fly is in the location:
[if we get here, no BEFORE or INSTEAD rules have intercepted the action]
[allow out-of-world actions like save, etc.]
if action in world is false, continue the action;
[allow examining and looking -- you could add more exceptions if you want]
if the current action is looking, continue the action;
if the action name part of the current action is the examining action, continue the action;
say "You won't get rid of the annoying fly with this[one of][or] either[stopping].";
stop the action.
Rule for printing a parser error when the fly is in the location:
[this changes all parser errors as long as the fly is around, but you could be more granular if you want]
say "You won't get rid of the annoying fly with this[one of][or] either[stopping].";
rule succeeds.
I have no idea what will break then that I still need, but probably yes.
That sounds promising, I’ll see if I can get anywhere with it!
I’m not that solid with the rule books yet, where’s the best place to look it up? In the index?
I’m afraid if I go into more detail here I’ll give away too much of the game. If you are interested, I could send you a detailed description / the actual code in a DM.
The room descriptions are not the problem, only the object descriptions. If necessary, I could also solve this in a different way (with INSTEAD rules).
I guess shutting down SAVE or QUIT is an absolute no go.
If you want to shut off the default implementation of every action, except out-of-world actions like SAVE and QUIT:
The special hack rules are a rulebook.
Last instead of doing anything except examining:
follow the special hack rules;
stop the action.
This means that the default implementation of every action will cease to function. Looking will no longer print room descriptions. Picking up objects will no longer move them to your inventory. Any action that has not been specifically overridden by the game will simply print nothing and fail.
And it sounds like you want to shut down parser errors too.
Before printing a parser error:
follow the special hack rules;
abandon the activity.
Then put your code in “special hack” rules. You probably want to give the rulebook a more descriptive name depending on your goal.
For just switching response text, it can be handy to just do…
The parser error internal rule response (X) is "You must have pressed the enter key by mistake."
And that could include adaptive text and thus be suitable for simple if-else cases; for more complicated or specific things you’d want to add Printing a Parser Error activity rules.
I assumed that was the case, but because my memory is awful and I have enough trouble reading code already, I decided that the generic “parser internal error [letter designation]” wasn’t enough for me as a visual aid. I’d rather spell it out.
I assume there was a technical reason for putting several default responses under one rule? I think that most default responses get their own rule.
This works surprisingly well and seems to be exactly what I was looking for! (I haven’t tested it extensively yet).
I don’t understand exactly what is happening though - what is the function of the “Last” at the beginning?
This is fine (I hope!) and I knew beforehand that I will need to take care of all the cases.
This results in an error – I think the activity has to be specified. But that is not a problem, I think I’ll use a blend of your and @kamineko’s suggestions anyway:
Rule for printing a parser error:
if the latest parser error is the I beg your pardon error:
say "Blabla.";
else if the latest parser error is the not a verb I recognise error:
say "Blibli.";
else:
say "Bleble".
I guess “special hack rules” is just the right description
The parser is an enormous mass of Inform 6 code making use of some rulebooks, mostly in the form of Activities (Reading a Command, Asking Which Do You Mean, Deciding Scope, Deciding Whether All Includes, Clarifying the Parser’s Choice, and, of course, Printing a Parser Error – hunh – that adds up to a longer list than I expected) plus the Does the Player Mean rules. But much of the parser is a single enormous function called Parser__parse. So there is a technical reason why the parser has so very many rule responses: it would have to be rewritten and reorganized into discrete rules for it to be otherwise.
Most of the Standard Rules’ Check Action rules have only one response, but across all the rules having multiple responses is commoner than having one. For instance, built-in Report Action rules routinely have one response for the player doing something, and another for the player seeing an NPC doing it. The list writer internal rule has 25 response texts, 'cause each of them is a fragment.
Yep, “abandon the activity” is wrong, you can’t do that from within an activity rule itself. I forget how to make an activity stop from inside it—the equivalent to “stop the action” in an action-processing rule.
An alternative is to make a “first for” rule:
First rule for printing a parser error:
Since by default only one “for” rule will ever be run.
A rulebook, such as “instead”, is fundamentally just a list of rules. It runs through those rules one at a time until one of them makes a decision, then it stops.
Normally, Inform arranges the rules within a rulebook in order of specificity. A rule about “unlocking the iron door with the skeleton key” is more specific than a rule about “unlocking the iron door with something”, which is more specific than a rule about “unlocking something with something”. But you can also override Inform’s judgement to put rules exactly where you want them.
In this case, I’m saying this rule belongs at the very end of the “instead” rulebook. This means it runs during the “instead” phase, but only if no other “instead” rule made a decision (because when a decision is made the rulebook ends). Therefore, it’ll apply to all actions that aren’t handled before or during the “instead” phase.
My mistake. I’ve worked with the A&B setup for report actions. I guess only two options and consistency is a different feel for me, but it is definitely two responses. I appreciate the explanations!
