![]() |
DI-Guy SDK Documentation
13.1
|
In a pipeline setting, (which may be a Host-IG configuration, or a DIS/HLA network), a DI-Guy user can be confronted with one or both of the following questions:
The following table shows the basic ways a DI-Guy character can have its action change on a host.
| Ways that Actions can Change | ||
|---|---|---|
| Character Mode | The way the character has its action changed. | Visual Result |
| PATH | Character has action beads on the path. | Smooth, nice transitions. |
| PATH or FREE | set_desired_action() | Smooth, nice transitions, but action will start after current action loop is complete for maximum visual quality. |
| PATH or FREE | force_action(<action name>="">, DIGUY_DEFAULT_FLOAT, 1, 0.5f, …) | Smooth transition that starts immediately. Quality of transition is not as nice as set_desired_action() but typically is quite good. |
| PATH or FREE | force_action(<action name>="">, DIGUY_DEFAULT_FLOAT, 0, 0.0f, …) | Instant transition with discontinuity. |
The recommended way to handle the host side is to use the character callback function diguyCharacter::CALLBACK_ID_CURRENT_ACTION_CHANGED(). This function is called when a new action should be commanded down the pipe.
A less desirable approach is to create a string variable called previous_action for each character, and then at every time step:
The recommended way to handle the IG side is to always call force_action() with the smooth bit determining whether to make the third and fourth arguments be (1, 0.5) or (0, 0).
Another way to do this is to use diguyMotionEngineSnapshot::get_motion_engine_snapshot(). This function returns a structure that tries to encode all the major variables that the motion engine is currently using to manage the primary action, and related transition values. The multi_channel example demonstrates this approach.
[<< DI-Guy SDK Use Cases] [Home] [Top of Page]