Postures by Emily Short

This topic is for discussions related to Postures by Emily Short

I’m using Postures by Emily Short, and I’m having difficulty with “preferred” postures. The documentation seems to be missing a part.

I’ve tried “step ladder allows seated and standing. step ladder prefers standing” and “…step ladder is usually standing.” but the compiler doesn’t like either of those. It looks like some of the documentation went missing due to the cut off sentence shown above, so I wonder if this was meant to be taken out?

I even scanned the source of the extension to see if I could find what it wants, but nothing popped out. This isn’t critical for my WIP but was curious if I’m missing something.

You don’t need “usually” for a single object. Just say “the step ladder is standing”.

Ah will try that. That must be what got lost in the instructions.

I’ve tweaked the documentation here and will upload a revised version.

Inspired by this post, I’ve made a pull request to the Extensions Github repository with an updated version of this extension:

github.com/i7/extensions/pull/47

Any comments are very welcome. I’ll just copy my thoughts from the PR description here:

I’m not sure what the best way is to handle responses about actions taken by NPC:s. More or less every message printed in the current code is preceded by checking “if the actor is visible,” which doesn’t seem very elegant and could potentially be slow. In the standard rules, the more common check seems to be “if the actor is the player” and then printing nothing if the actor isn’t.

But I think it is nice to get a more detailed response, such as “Clark is already standing on the folding chair,” rather than just “Clark is unable to do that,” and all those “if the actor is visible” seem to be the simplest way to achieve that without having to write a lot of separate rules just to print basically the same response.

The “convert lying down rule,” “convert sitting down rule” and “convert standing up rule” used to end with success or failure, but I’ve found that if I print a failure message such as “There [are] nothing [here] to sit on,” I have to return success, otherwise there will be a second response printed:

[code]>Clark, sit
There is nothing here to sit on.

Clark is unable to do that.[/code]
This means that the rules will now always end in success, which makes all those “rule succeeds” lines a little redundant.

One option is to provide unsuccessful attempt rules, which are run in place of report rules when an action taken by an NPC fails. (These are what give the “Clark is unable to do that” messages.) You can check whether “the reason the action failed” matches one of your rules and print a better failure message.

Specifically, they run when an NPC action performed in response to a request fails. An NPC action invoked directly from the source code like “Try Clark sitting” will not invoke unsuccessful attempt rules.

Thanks! Unsuccessful attempt rules do some of what I’m after: they provide a way to give custom responses to failed actions by NPCs. But they will still consist of duplicated code: my attempts to do what you suggested were mostly line-for-line copies of the code that runs when the actor is the player. It seems that it is easy to write “actor-agnostic” responses, but harder to use them without code duplication.

Also, after further investigation, it seems that many if not most extensions pretty much assume that the actor is the player. This actually seems to be true of some parts of the standard rules as well. For example, we have this warning in the documentation, §12.4. Persuasion:

The example code of the Postures extension also has a bug where asking the NPC to sit or stand on something that the player carries gives an empty non-response:

That can be easily fixed by another unsuccessful attempt rule, but what I’m getting at is this: implementing NPCs that can be ordered around is a bit of a rabbit hole. The support in Inform for this out of the box is pretty much a stub. Anyone who wants to make a game with an NPC that can follow instructions will always have to write lots and lots of custom code. Where is it reasonable to draw the line in providing support for this in a general-use extension like this? Well, I guess the obvious answer is: about as much as the original code of this extension did before I touched it. So that is where I should be aiming.

Maybe one thing to do is set a flag when you print the message that cuts off the unsuccessful attempt rules at the beginning:

[code]Lab is a room. Clark is a man in Lab.

Instead of an actor smelling: say “[printing failure message]There is nothing to smell here.”

Persuasion rule: persuasion succeeds.

Failure message printed is a truth state that varies.

Every turn: now failure message printed is false.

To say printing failure message: now failure message printed is true.

First unsuccessful attempt by someone doing something:
if failure message printed is true, stop;
make no decision.[/code]

(That last rule took a lot of tweaking to compile–seems like unsuccessful attempt rules need a “by” and action description even if they’re totally generic, and they can’t take “when” clauses.)

1 Like