Legacy Reference

Using Action Subcontexts

Subcontexts are a way for programmers to explicitly refer to a single logical role (out of multiple such roles) when requesting an action. Subcontexts are a convenience when dealing with FragmentIDs whose scope mask encompasses multiple scope contexts, where each context refers to a different role. For example, a car could have multiple seats, each one with its own scope and unique associated tag. Subcontexts do not affect fragments but rather provide additional contextual information when dealing with actions that involve multiple independent scope contexts.

Subcontexts are defined in the controller definition (*ControllerDefs.xml) file. Each subcontext has a unique name and exposes a scope mask and global tag state. Using the car example, the following code shows how the car's controller definition file could define different subcontexts for different seats, each seat having its own set of scopes.

<SubContexts> <Driver scopeMasks="Driver+DoorDriver" tags="Driver"/> <Passenger scopeMasks="Passenger+DoorPassenger" tags="Passenger"/> </SubContexts>

Upon entering the car, a character typically gets enslaved to either the Driver or Passenger scope context. When requesting a FragmentID that is local to one of the seats (for entering or leaving the vehicle), the game needs to state the correct subcontexts. This is done by requesting the subcontext in a mannequin action. The following snippet shows an action installed on a subcontext:

// Driver just entered the vehicle, already enslaved to it IActionController* pVehicleActionController; IAction* pEnterVehicleAction; // ... // Queue the "EnterVehicle" FragmentID with the suitable SubContext pEnterVehicleAction->SetFragment(EnterVehicle); pEnterVehicleAction->SetTagContext(isDriver ? Driver : Passenger); // Change SubContext based on which role the enslaved character is supposed to have pVehicleActionController->Queue(pEnterVehicleDriverAction);

This results in automatically adding the matching scope mask and global tags to the default state during the fragment selection process for this action. In this example, with the proper setup, Mannequin would then know which character and which door to animate when processing this action. As such, the FragmentID can be queried and resolved to different scope masks and ultimately fragments based on the given subcontext.