This isn’t actually a report. What’s going on under the hood is that “Ask penguin for ocean” gets converted into asking the penguin to try giving you the ocean–what would happen if you typed “Penguin, give me the ocean.” From the specification of the “Asking it for” action in the standard rules:
So the error message that you get here is the error message you get from an unsuccessful attempt to persuade someone of something.
In many other cases it makes sense to have the command clarification break occur so you can see what the error message pertains to. Let’s say I try to wear a hat someone else is wearing:
This makes it clear that the action failed at the taking step, which might be important if later I can get the hat away from Stagger Lee and I need to wear it. (Also, if you know the story of Stagger Lee, it lets me know that I need to watch my ***.)
Maybe more important, this works much better than running the ordinary report rules when the action is successful. Let’s say we suppressed the message and let the implicit take run “out loud” instead of silently, so it ran its report rules:
If you really don’t like the clarification messages, you can rewrite the responses so those messages don’t appear… maybe you could put the message for a successful implicit take in one of the rulebooks that does run for an action tried silently.
Yeah, I’m not sure about this one–sometimes things like this are legacies of an old treatment. I guess one advantage is that it saves you from having to disambiguate in some cases–if Casey is here and so is a 78 rpm record of “Casey Jones” by Vernon Dalhart,* “kiss Casey” will match the person but not the record, without getting tangled up in disambiguation. If you want to handle it with block rules you can define a new Understand rule that matches “kiss [something],” I guess.
*Originally this was a 45 rpm of “Casey Jones” by the Grateful Dead, but I said the heck with it, if I’m going to go with archaic formats I’m going OLD SCHOOL.
Yeah, there are just so many actions and scenarios for implicit actions that it would take a long time to rewrite them all, but I’m neurotic enough that I’ll probably do it. I like them for successful situations (like the hat example) because it clarifies the change in ownership, but I really can’t stand them for an action doomed to failed.
Yeah, the disambiguation thing is quite handy, but it brings many problems with it and (theoretically, although it seldom works for me) you can use ‘Does the Player Mean’ to fix the ambiguity anyway, so it’s redundant.
flarping is an action applying to one thing.
Understand "flarp [container]" as flarping.
If you try something like “flarp self” or “flarp button” you’ll get varying responses from ‘You can’t see any such thing’ (even though it’s in the room) to ‘That noun did not make sense in this context’. Not that I think I’m revealing anything anyone didn’t already know, it’s just my preferences and musings.
Can’t really complain though, as it’s all fixable and someone wrote this awesome language to use for free, and everyone here is super helpful, so… it’s definitely nitpicking.
Inform anticipated OCD authors a bit and one of the main laws for rule processing is that the more specific rules win over more general ones, meaning it is incredibly easy to write exceptional rules (and any associated understand clauses) to handle any nit-pick corner cases. Understand clauses themselves may also be conditional and these conditions may further reduce the problem of ambiguity.
There’s the extension Implicit Actions by Eric Eve, which changes the reporting based on whether the action succeeded or failed. I don’t know if it’ll cover this particular case (with persuasion rules) but it makes the reporting much nicer in general. ("(first taking the key, then trying to unlock the cabinet) That seems to be locked.")
Yes, my experience is I have a problem, I try to solve it with DTPM, and now I have two problems.
I tried this to achieve the effect you want–print the “(first taking)” message only if the take succeeds–but it was fiddly, and it probably isn’t robust. For one thing, if you put in a message consequent to the take (like in an “after taking” rule) it’ll print out of order. To get that to happen correctly, you probably need something like the Implicit Actions extension, which I think tries the action hypothetically to determine whether it succeeds–otherwise you don’t know whether to print anything until you’ve already printed any messages that resulted from the taking action. (…which I guess explains why the Standard Rules don’t try doing it this way.)
[code]Test Room is a room.
For implicitly taking something (called the target):
if the person asked is not the player:
try silently asking the person asked to try taking the target;
if the person asked holds the target:
say “([the person asked] first taking [the target])[command clarification break]”;
try silently taking the target;
if the player holds the target:
say “(first taking [the target])[command clarification break]”.
The coat is a wearable thing in test room. The penguin is a person in the test room. The penguin can be unreceptive or receptive. The penguin is unreceptive.
Instead of jumping:
say “The penguin seems pleased and pliable.”;
now the penguin is receptive.
Persuasion rule when the person asked is the receptive penguin:
test me with “penguin, wear coat/wear coat/drop coat/jump/penguin, wear coat/wear coat”. [/code]