Overview

A scopemask is how we call the set of scopes that a fragmentID (more correctly: an action) will run on.

Some examples:

• A FireWeapon fragmentID could have a scopemask containing the Weapon scope (for animating the weapon) as well as the scope representing the Torso of the character. It doesn't need to contain the other scopes of the character because it can control the torso independently of the rest of the body using additive & partial body animation.
• Standard movement fragmentIDs typically need control of the Base of the character, but nothing else. Head movement & weapon animation could be done independently.
• A fragmentID used during a fully scripted action might need full control of the body, weapon and torso included. It typically contains all scopes in the scopemask. Exceptions to this rule might be fully systemic scopes like the LookPose, described in the tutorial Controlling Looking (and Aiming) for AI in Mannequin.

Typically the scope mask is determined by the FragmentID. Each fragmentID has a scopemask associated to it. (this is set up using the FragmentID Editor and stored in the controller definition)

It is possible to specify 'overrides' and select different scopemasks based on the global tagstate and requested fragtags. See the file format section in the article on the controller definition file for more on how this is set up.

Optionally the scopemask and the overrides are overridden by the 'forced scopemask' that can be specified by the action itself.

When an action requests a fragmentID and is installed, the action will own the scopes in the fragmentID's scopemask. The system will then start playing fragments on these scopes. See Fragment Selection Process for more information.

For programmers: a scopemask has type ActionScopes which currently is just a uint32 in which each bit represents a scope. This determines the maximum number of scopes.