[I7-2057] [Mantis 2094] Stored action that is a request for the player to do something results in pseudo-successful action that causes invalid history #27
Using a "the action of asking..." construction creates a stored action with the correct parts, but execution of that action has two unexpected effects if the person asked is the player:
1) The asked-for action registers as a success according to actions debugging information, but the world state does not change as would be expected in the case of action success. Normal action-processing rules seem to be being short-circuited somehow.
2) The pseudo-successful action registers as a success in the built-in world history, so "if we have..." conditions improperly evaluate as true. (Demonstrated in example code.)
Note that addition of an instead rule to block taking the boulder (included in the example code but commented out) results in the instead rule being triggered and the action registering as a failure. This is not unexpected from a naive perspective, unlike the "pseudo-success" scenario when no instead rule is active.
Steps to reproduce :
"Bug Report" by Otis the Dog
Place is a room.
A boulder is in Place.
[Following can be uncommented for comparison of results; see bug report's description section]
[Instead of taking the boulder:
say "Too heavy." instead.]
After waving hands:
say "Boulder registers as [if we have not taken the boulder]NOT [end if]taken."
After jumping:
let example be the action of asking the player to try taking the boulder;
try example.
test me with "wave/actions/jump/actions off/wave/look".
Additional information :
I'm not skilled enough to pinpoint the issue at the I6 layer, but my guess is that this case breaks the (normally correct) assumption that the actor will not be the player in an action set as a request. Given that it's legal to construct the action, the options look (to me) like:
1) Prevent this type of stored action from being constructed at compilation. (Not preferred.)
2) Make sure that action processing automatically strips the request parameter from any action that has the player as the actor and that the action processes normally from there. (Probably workable and result would be sensible from a naive perspective, since one can assume one will cooperate with oneself.) Note that this is what appears to be happening when the asked-for action is prevented by an instead rule, as explained above.
3) Take the implications of the stored action's structure to their logical (if perhaps absurd) conclusion and run with it, i.e. follow persuasion rules and then go to normal action processing of the non-request version if and only if persuasion succeeds, as happens for any other non-player character. (I would love this and am sure it would make for some fun examples in the Recipe Book, but I understand if you prefer to avoid the extra complexity.)
Reported by : otistdog
Description :
Using a "the action of asking..." construction creates a stored action with the correct parts, but execution of that action has two unexpected effects if the person asked is the player:
1) The asked-for action registers as a success according to actions debugging information, but the world state does not change as would be expected in the case of action success. Normal action-processing rules seem to be being short-circuited somehow.
2) The pseudo-successful action registers as a success in the built-in world history, so "if we have..." conditions improperly evaluate as true. (Demonstrated in example code.)
Note that addition of an instead rule to block taking the boulder (included in the example code but commented out) results in the instead rule being triggered and the action registering as a failure. This is not unexpected from a naive perspective, unlike the "pseudo-success" scenario when no instead rule is active.
Steps to reproduce :
Additional information :
I'm not skilled enough to pinpoint the issue at the I6 layer, but my guess is that this case breaks the (normally correct) assumption that the actor will not be the player in an action set as a request. Given that it's legal to construct the action, the options look (to me) like:
1) Prevent this type of stored action from being constructed at compilation. (Not preferred.)
2) Make sure that action processing automatically strips the request parameter from any action that has the player as the actor and that the action processes normally from there. (Probably workable and result would be sensible from a naive perspective, since one can assume one will cooperate with oneself.) Note that this is what appears to be happening when the asked-for action is prevented by an instead rule, as explained above.
3) Take the implications of the stored action's structure to their logical (if perhaps absurd) conclusion and run with it, i.e. follow persuasion rules and then go to normal action processing of the non-request version if and only if persuasion succeeds, as happens for any other non-player character. (I would love this and am sure it would make for some fun examples in the Recipe Book, but I understand if you prefer to avoid the extra complexity.)
imported from: [Mantis 2094] Stored action that is a request for the player to do something results in pseudo-successful action that causes invalid history