Library bug? Strange "verify" behavior

Authoring TADS
1

I came across this issue in the course of making my game, but danced around it and didn’t feel the leisure at the time to investigate.

Ironically, if you use a nonObvious in dobjFor {verify of a TIAction, the action will succeed even if the iobj of the current command is supposed to fail in verify!
Can anyone replicate this, and concur that this is undesirable behavior?

I think that this could be rectified by modifying VerifyResult.shouldInsertBefore so that if resultRanks are equal, it then looks at allowAction. It seems that the existing behavior allows a NonObviousVerifyResult to wind up at the beginning of the VerifyResultList, so that the action thinks the collective verify results are agreeing to allow the action (action.t, line 1404).

For instance:

safe: Thing
  dobjFor(DrillWith) { verify { nonObvious; } 
      action { "Drilled. "; } }
;
doughnut: Thing
  iobjFor(DrillWith) { verify { illogical('Try again. '); } }
;

>drill safe with doughnut
Drilled.

//This should not be happening!
1 Like