Hi,
Really quick question. Is there a quick way, if a player enters a certain room, to make the player unable to do anything. Anything at all. Including inventory, move, examine…you know, anything. So whatever the player types it just responds ‘No.’ and doesn’t increase the turn count.
Thanks for any help!
McT
Do you want to block meta-commands as well? If so:
After reading a command when the location is the Torture Chamber:
say "No.";
reject the player's command.Perfect. Thanks Draconis. I feel dumb now.
You don’t want to block meta commands.
Instead of doing anything:But won’t that still increment the turn count and trigger “every turn” rules?
I suppose you could use Vyznev’s extension (the one that prevents failed actions from taking time), then put “take no time” in your instead rule.
You can prevent actions from taking time with (adapted from the Recipe Book):
[the condition must match in both rules so to avoid bugs it's best to define the condition in a separate phrase]
To decide whether blocking commands:
if the location is whatever, decide yes;
decide no.
Instead of doing anything when blocking commands:
say "No."
The take some actions out of world rule is listed before the every turn stage rule in the turn sequence rules.
This is the take some actions out of world rule: if blocking commands, rule succeeds.If I do the instead of anything rule, won’t more specific rules take over?
For instance, if the player has an item in there inventory with a more specific instead rule, wouldn’t that win out over the “doing anything” rule?
You could avoid this by saying “First instead of doing anything”.
However, a better answer is to say – this is why you have should a clear notion of what each rulebook is for. (Not everybody has the same set of notions, but you should have one.)
I use “instead” rules only for broad action-blocking messages and (sometimes) specific redirections. If there are two different action-blocking rules, it’s worth deciding which takes precedence (and using ordering declarations to enforce this).
Redirections (from one action to another) don’t subvert the blocking because even if they pre-empt the original action, the target action will be blocked anyway. For example:
Instead of taking the aspirin: try eating the aspirin.
I should go back and explain why it’s a bad idea to use the “reading a command” hook here.
First, it short-circuits the parser. If the player types “dfghdfgds” and gets back the same “You’re stuck” response, it gives the wrong impression. You’re not simulating a protagonist who cannot act, but a parser which cannot parse.
Second, it’s just a terrible idea to block out the save/restore/version/undo sorts of commands. Nobody’s ever going to be happy about that sort of thing.(*)
(* For technical reasons the “after reading a command” rule doesn’t block undo. Let’s not get into technical reasons.)
Using a “first instead” rule will let the before rules run, so if you have before rules you might want to watch out for that.
(And I can report that people get annoyed when you block “version” even if you have what seems like a really good reason for it.)
In general, I agree with zarf that you wouldn’t want to block meta-commands, but actually, in this case, I do want to block meta commands. For various reasons. Anyway.
However, reason I’m posting is that, interestingly, the ‘after reading a command’ statement as written by Draconis, blocks everything except ‘undo’. I’m not entirely sure why. (oops: later edit: redacted - just re-read the end of zarf’s message about ‘technical reasons’. And ‘reasons’ is always a good reason not to go into something. Although I am curious, if ‘after reading’ bypasses the parser how it recognises undo.)
McT.
After Reading A Command rules don’t generally bypass the parser; it’s the Reject The Player’s Command phrase in Draconis’s rule that stops the parser short.
The Reading A Command activity (naturally) takes place just at the start of parsing, and most of the parsing isn’t done till after the Reading Command activity is over. However, blank input, OOPS and UNDO commands are detected and handled already during the For Reading A Command stage of the activity – stopping the ordinary course of the parser before even After Reading A Command rules are taken into account