On adv3's use of mainReport() instead of reportFailure() for blocked actions

Authoring TADS
1

Is there some philosophical rationale behind adv3’s consistent use of mainReport() instead of reportFailure() for blocked actions?

As near as I can tell, the documentation (i.e. the Action Results article) suggests that using reportFailure() is optional (“not strictly necessary”), but I don’t see (and can’t really think of) any reason why it shouldn’t be used when possible.

For example, Actor.checkTakeFromInventory() looks like:

    checkTakeFromInventory(actor, obj)
    {
        /* don't allow it - show an error and terminate the command */
        mainReport(&willNotLetGoMsg, self, obj);
        exit;
    }

…but if there’s a pebble in Alice’s inventory and the player tries >TAKE PEBBLE (and no special provision has been made for this circumstance) the pebble won’t be taken, but gTranscript.isFailure will be nil.

I’m in the process of doing a bunch of nonsense around NPC scripting, and I’m trying to build a mechanism for generically testing if an actor attempting a command (that is a command string, instead of an Action instance) would succeed or not. So I’m considering combing through adv3 and monkey patching everyplace this sort of thing happens.

Just wondering if there’s some situation in which it would be undesirable to use reportFailure() for this kind of thing.

1 Like
2

Perhaps it’s an oversight on the library’s part?
The docs say this:

If a check() routine (in a dobjFor() or iobjFor() group) terminates
the command with ‘exit’, the parser now automatically marks the action
in the transcript as having failed. This is the same thing that the
reportFailure() macro does, so this means that it’s never necessary
to use reportFailure() from within a check() handler.

but checkTakeFromInventory is called from the Actor’s beforeAction method… perhaps MJR missed that?

3

There are also places where it happens in an action handler’s action() method as well, as in Actor.dobjFor(Kiss) for example. And I think whether or not a lot of the default conversational responses should be considered “failed” actions is open to debate—an NPC not reacting to the player trying to talk to them probably shouldn’t be considered a failed action (the action succeeded, just nothing happened) but I think for example defaultGiveResponse() probably should be marked as a failed action (the player tried to give the NPC something and that didn’t happen).

Anyway, I agree it’s probably oversight. I’m just wondering if there are any hidden gotchas to putting together a bundle of patches that replace a bunch of mainReport()s with reportFailure()s.

I can’t think of any, but I can’t think of a lot of things.

1 Like
4

My instinct is to agree… if the action does not occur as the player requested, marking it as isFailure doesn’t seem problematic.

5

I went ahead and put together a little module to address the examples of this kind of thing that I’ve discovered: moreFailureReports github repo.

I’ll probably end up tinkering with this more as I try to write more actual game code, but since this is mostly just replacing instances of mainReport() with reportFailure() it’s something that (hopefully) shouldn’t interfere with existing code.

1 Like