Chapter 14. Can Many Objects be TAKEn Before Using with TAKE-CHECK and MANY-CHECK

14.1 Introduction

There are now two final checks on the verb by PARSER. The first is to see if the given verb can automatically take objects and act upon them. The second is to see if the given verb can accept multiple objects. Both sets of checks are done on direct (and indirect if present) object clauses.

• ITAKE-CHECK (through TAKE-CHECK)
• MANY-CHECK

14.2 ITAKE-CHECK (through TAKE-CHECK): Checking TAKE and HAVE bits

• Arguments: Address to object table, LOC byte
• Returns: TRUE if objects do not need to be taken or were taken if necessary, FALSE if errors

TAKE-CHECK calls ITAKE-CHECK on each set of objects (direct objects from P-PRSO and indirect objects from P-PRSI) with the matching syntax’s LOC byte to verify if objects must be in the possession of the WINNER to be used as some verbs require this. So an object in the room but not on the WINNER is not valid. However, any verb syntax entry with a TAKE bit set in the LOC byte is allowed to automatically put any matching object in the room into the WINNER’s inventory and then act upon it. PARSER will see if any objects in an object clause that are not in the Winner’s inventory can be automatically taken. If the object’s TRYTAKEBIT is set, this would prevent PARSER from automatically taking it. For all objects without the TRYTAKEBIT set, PARSER will call the CARRY object routine to move the object into the Winner’s routine. For any objects that can’t be automatically taken, it is possible the verb can still use it. However, PARSER first checks if a HAVE flag is set in the verb syntax entry. This would require the object be in the inventory to use it in the action. If so, then the object cannot be used and an error is displayed. Any error will stop the checking of any remaining objects in the object clause.

14.3 Update: New ITAKE-CHECK

Starcross introduced a new ITAKE-CHECK which tried to catch situations where objects could not be taken. These included:

• Both TAKE and HAVE bits cleared (objects do not need to be held and can’t be taken) on syntax

• if HAVE set, then check objects
• if HAVE not set and TAKE not set then RTRUE
• if HAVE not set and TAKE set then check objects (SEe if can be taken)

• The WINNER is not the PLAYER
• The object is held by the WINNER (using HELD?)
• The object is something that can’t be taken like “pair of hands”

The new routine would also not display error messages in certain situations such as an ACTOR would try to take an object before using it. It also needed to check if the syntax had LOC TAKE set before calling ITAKE to get the object. (at least try)

Sorcerer checked if the IT-OBJECT was accessible before using it. It also checked to see if the object is held, it would then skip the rest of the routine. For any NOT-HERE-OBJECTs, it would display a specific error message. If an object exists but can’t be used, then it would also updated the IT-OBJECT value.

Seastalker also allowed “him” and “her” pronouns to be “taken” and used. But no checks on their visibility was done until Wishbringer which also added the “them” pronoun. Later games like Hollywood Hijinx would have specific checks for objects if they inside other objects (such as water inside a bucket).

More specific error and confirmation messages were created. For example, these would use the appropriate articles depending on the object and quantifiers depending on the number of objects. They would also indicate if an ACTOR did not have an object.

14.4 MANY-CHECK

• Arguments: None
• Returns: TRUE if syntax entry accepts multiple objects, FALSE if not

Some verb syntax entries allow for multiple direct or indirect objects in their usage, such as GET or IGNITE. PARSER will first check how many objects are in the direct and indirect object clauses. If there is only 1, then this check is not needed. If there is more than 1 object and the MANY token is not set for that direct object clause in the syntax entry, then an error message is displayed about the verb not being able to use multiple objects. This same check is then done on the indirect objects if necessary.

Only a few changes were made with this routine. Starting with Zork 1-R75, PARSER would run MANY-CHECK first before TAKE-CHECK which correct a bug were PARSER would attempt to take multiple requested objects first but then error out on the verb if it could not process multiple objects. By flipping the order, PARSER can quickly see if multiple objects can be used on an verb before trying to take then using TAKE-CHECK. This is mentioned in the Infocom Cabinet notes.  Deadline would assume the verb was “tell” if it was not given (occurs when the player is telling an actor to do something). Sorcerer ensured that the complete verb was displayed if the current command is the result of a merge. Finally, LGOP added a new parameter to indicate which noun clause to check. This would eliminate the need to check if a particular clause in the matched syntax can accept multiple objects.