[x] Ensure that the implicit-taking attempt message is printed before the actual code that carries it out:
[x] In lib_classes.i &rarr: liquid &rarr: VERB give.
[x] Look for similar out-of-order messages in the whole Library, and fix them.
[x] Fix Issue #78 — removing the useless IF clauses for verifying that implicit taking was successful.
This is the current definition of the give VERB on liquid:
EVERY liquid ISA OBJECT
...
VERB give
WHEN obj
DOES ONLY
-- >>> implicit take >>>
IF THIS NOT IN hero
THEN
IF vessel OF THIS = null_vessel OR vessel OF THIS IS NOT takeable
THEN "You can't carry" SAY THE THIS. "around in your bare hands."
ELSE LOCATE vessel OF THIS IN hero.
"(taking" SAY THE vessel OF THIS. "of" SAY THIS. "first)$n"
END IF.
END IF.
-- <<< implicit take <<<
IF THIS IN hero
-- i.e. if the implicit taking was successful
THEN
"You give" SAY THE vessel OF THIS. "of" SAY THIS.
"to" SAY THE recipient. "."
LOCATE vessel OF THIS IN recipient.
END IF.
-- There is no ELSE statement in this last IF clause, because the previous
-- `IF THIS NOT IN hero` clause already takes care of the ELSE
-- alternative.
END VERB give.
I see some potential issues with the above definition (which need to tested):
The implicit taking action is first trying to move the vessel into the Hero's inventory, and then report the attempt:
ELSE LOCATE vessel OF THIS IN hero.
"(taking" SAY THE vessel OF THIS. "of" SAY THIS. "first)$n"
But the message should always precede an implicit taking attempt because, as we've discovered (see #57), failure to dislocate an object that is being blocked by an EXTRACT clause will abort the execution of the current VERB (with or without a message, depending on the EXTRACT code) — hence the need to ensure that in every implicit taking the attempt-message should precede the actual dislocation code.
Also, an EXTRACT clause could print a message of its won (even if not blocking the action), in which case the attempt message would be out-of-order, following the taking response instead of preceding it.
The IF clause that verifies if implicit taking succeeded is useless, for it would never be executed due to VERB abortion:
IF THIS IN hero
-- i.e. if the implicit taking was successful
THEN
...
END IF.
The surround IF ... END IF. clause should be removed and replaced with a comment that clarifies that if the preceding implicit-taking attempt failed, the VERB would have aborted and this code never be executed.
This was already proposed in #78, here I'm just remind us that we should do something about it.
This might also apply to other VERBs, so we should check and fix all occurrences of implicit taking reports that follow the code that handles it.
lib_classes.i
&rarr:liquid
&rarr:VERB give
.IF
clauses for verifying that implicit taking was successful.This is the current definition of the
give
VERB onliquid
:I see some potential issues with the above definition (which need to tested):
The implicit taking action is first trying to move the vessel into the Hero's inventory, and then report the attempt:
But the message should always precede an implicit taking attempt because, as we've discovered (see #57), failure to dislocate an object that is being blocked by an
EXTRACT
clause will abort the execution of the current VERB (with or without a message, depending on theEXTRACT
code) — hence the need to ensure that in every implicit taking the attempt-message should precede the actual dislocation code.Also, an
EXTRACT
clause could print a message of its won (even if not blocking the action), in which case the attempt message would be out-of-order, following the taking response instead of preceding it.The
IF
clause that verifies if implicit taking succeeded is useless, for it would never be executed due to VERB abortion:The surround
IF ... END IF.
clause should be removed and replaced with a comment that clarifies that if the preceding implicit-taking attempt failed, the VERB would have aborted and this code never be executed.This was already proposed in #78, here I'm just remind us that we should do something about it.
This might also apply to other VERBs, so we should check and fix all occurrences of implicit taking reports that follow the code that handles it.