Precondition execution order. When we execute preconditions for a given action, we'll sort the list of all applicable preconditions in ascending execution order.

For the most part, the relative order of two preconditions is arbitrary. In some unusual cases, though, the order is important, such as when applying one precondition can destroy the conditions that the other would try to create but not vice versa. When the order doesn't matter, this can be left at the default setting.

Check the condition on the given object (which may be nil, if this condition doesn't apply specifically to one of the objects in the command). If it is possible to meet the condition with an implicit command, and allowImplicit is true, try to execute the command. If the condition cannot be met, report a failure and return nil to terminate the command.

If allowImplicit is nil, an implicit command may not be attempted. In this case, if the condition is not met, we must simply report a failure return nil to terminate the command.

Verify the condition. This is called during the object verification step so that the pre-condition can add verifications of its own. This can be used, for example, to add likelihood to objects that already meet the condition. Note that it is generally not desirable to report illogical for conditions that checkPreCondition() enforces, because doing so will prevent checkPreCondition() from ever being reached and thus will prevent checkPreCondition() from attempting to carry out implicit actions to meet the condition.

'obj' is the object being checked. Note that because this is called during verification, the explicitly passed-in object must be used in the check rather than the current object in the global current action.