Guide: Siege University - 217: Actor & Party Commands

Introduction

"Actor and Party Commands" refers to the set of gizmos that specifically affect Actors and Party Members: either changing their AI behavior, modifying their properties, or manipulating their inventory. For the purposes of this tutorial, we'll divide these gizmos into three categories:

1. AI Commands
2. Manipulation Commands
3. Party Commands

AI Commands are a set of gizmos that give basic "orders" to an Actor, including Party Members. The orders include "move", "attack target", "patrol", "equip", etc; and can be assigned either to a specific Actor or to a trigger catalyst. While there are many AI Commands, only a few of them were actually used in DS1.0, since more complex behaviors were handled in other ways (like skrit).

Manipulation Commands also affect Actors, but these gizmos affect the Actor's properties in some way instead of assigning AI behavior. These gizmos can change the visibility, hostility, invulnerability, and other properties of the Actor; and also manipulate the Actor's inventory. There are only a few gizmos in this category:

• cmd_alignment_changer
• cmd_animation_command
• cmd_inventory_changer
• cmd_selection_toggle

Finally, Party Commands assign behaviors to the entire Party, all at once, no matter where they are in the world. These three commands are used almost exclusively in Single Player:

• cmd_move_party
• cmd_stop_party
• cmd_wrangle_party

What You Need For This Tutorial

• Dungeon Siege v1.1 or newer
• Siege Editor from the Dungeon Siege Tool Kit
• The "map_world" map converted to bits
• A test map to experiment with different commands

What This Tutorial Assumes You Have Already Learned

• Siege University: 100 - The Basics of the Siege Editor
• Siege University: 200 - Dungeon Siege Concepts and Terminology
• Siege University: 201 - Templates
• Siege University: 203a - Triggers I
• Siege University: 203b - Triggers II
• Siege University: 208a - Non-Player Characters

AI Commands

<Back to Table of Contents>

AI Commands are gizmos that can assign a wide variety of behaviors to any Actor, including Party Members. Most of these behaviors mimic the orders you can give to your Party Members with your mouse, like "move", "stop", attack", etc. These behaviors, or Jobs that the Actor performs, stack up in the Actor's Command Queue for execution.

AI Commands are assigned to Actors in one of two ways:

1. Gizmo assigns a Job to the catalyst of a trigger (Catalyst AI Commands)
2. Gizmo assigns a Job to a specific Actor designated by SCID (Target AI Commands).

Both sets of gizmos are virtually identical, with minor exceptions, and have the same component block that defines their properties: the [cmd_ai_dojob] block.

We'll talk about Jobs, the Command Queue, and the [cmd_ai_dojob] block in the section below.

Some Definitions

The AI Job

First, let's look at the "AI" definition as listed in Siege U 200, specifically pulling out the "Jobs" description:

Jobs: The lower level of AI. Jobs are responsible for handling specific functions, using chores to accomplish those tasks. Jobs manage:

• Movement: Following, moving in formation, guarding, moving

• Attacking: How to get there, what animations to use

• Item manipulation: Getting items, dropping, equipping

• Talking to other actors: Selecting the appropriate conversation, syncing dialog and animations, playing any special actions that occur as a result of the conversation

• Other actions: Using, drinking, going unconscious/conscious, special monster behaviors, fleeing, dying

The thing to take away here is that when an Actor is performing an action, he is doing a "Job". Jobs have names like "jat_move" and "jat_attack_object", and every Actor template associates these names with particular AI skrits (place any Actor in SE and look at its [mind] block). The AI Command gizmos tell the Actor to run one of these skrits. The Actor must support the Job that a gizmo attempts to assign.

For this lesson, there are really only two things to remember about Jobs:

1. AI Command gizmos assign a specific Job to an Actor, and
2. Incoming Jobs are placed into an Actor's Command Queue for execution.

The Command Queue

The Command Queue is the list of internal queued Jobs that an Actor uses to drive its behavior. The Actor will execute the first Job in its queue, then the second, and so on, until all Jobs in its queue are completed; then the Actor will revert to its default AI. An easy way to see this in action is to select a Party Member within the game, hold down SHIFT, and click several times on the ground. The Party Member will travel to the first click location (a Move Job), then the second, and so on, until the sequence is complete.

During the move sequence, the Party Member will not do anything else except move to the waypoints, even if an enemy attacks. This is because Player-given commands are not interruptible, i.e. the Party Member is incapable of making a different AI decision while under the influence of a Player command. AI Command gizmos are by default non-interruptible, but this property may be changed in the gizmo instance.

Speaking of the gizmo instance…

The [cmd_ai_dojob] Block

Do the following:

1. Open your test map in SE
2. Place a catalyst move command (cmd_ai_c_move)
3. Place a target move command (cmd_ai_t_move)
4. Look at the [cmd_ai_dojob] block in the properties of each gizmo.

Even though there is a lot of confusing component fields, you might notice that the component fields are identical between the two gizmos. When using AI Commands, there are only a few of these fields you will ever need to use:

• next_scid: (SCID) The SCID of the next linked AI Command, if any (see Linking Catalyst AI Commands and Linking Target AI Commands below).
• placement: This field determines where in the Actor's command queue this command will be placed. There are 3 values of interest (qp = queue placement):
  • qp_front (default): The command is put the front of the queue, becoming the active command. All pre-existing commands are bumped down one slot, and they will still execute after the new command terminates.
  • qp_back: The command is put at the end of the command queue, and will execute after all pre-existing commands have terminated.
  • qp_clear: The command queue is cleared, and the new command is inserted as the only command in the queue. This is desirable when you do not want the Actor to return to any previous commands after the new one terminates (for example, let's say you have a bounding box that intercepts a moving Actor and tells him to go somewhere else. If qp_clear is not set, the Actor will arrive at the new destination, but then resume his previous move job and try to walk to the original destination. If the trigger was not one-shot, then the Actor can bounce back and forth indefinitely, until his original move job completes or is cleared).
• target1: (SCID) Use depends on the gizmo. Usually is the target of an AI Target Command.
• target2: (SCID) Use depends on the gizmo. Usually used when multiple targets need to be specified.
• slot: This field is used when the command references an object the Actor is holding or wearing (i.e. cmd_ai_c_drop). (NOTE: To manipulate items in the Actor's inventory, use the "cmd_inventory_changer" instead, listed under Manipulation Commands, below.) The "equip slot" is the location of the specified object. Valid slot names can be found under the "Equip Slot" dropdown menu on the "Equipment" tab of any Actor's properties, or use the following list:
  • es_weapon_hand
  • es_shield_hand (default)
  • es_forearms
  • es_feet
  • es_chest
  • es_head
  • ring# (where # is 1-4)
  • primary_spell
  • secondary_spell
• setJobTraitInterruptable: (true/false) If true, job is interruptible. If false, is not. Default: false.

Now that we've covered some common ground between Catalyst and Target Commands, let's go over them in detail.

Catalyst AI Commands

These Commands are found in SE under "Game Objects/Gizmos/Commands/ai/catalyst_commands".

Catalyst AI Commands are used to assign an AI behavior to an Actor. Instead of specifying a specific Actor in SE, you'll pass a catalyst to the Command with a Spatial Trigger (see Siege U 203A and 203B for information on catalysts and spatial triggers). The catalyst will be sent along with a "we_req_activate" message.

Do the following in your test map:

1. Place a trigger_generic gizmo, then place a cmd_ai_c_move gizmo at some distance away.
2. Give the trigger an "actor_within_sphere" condition, and send a "we_req_activate" message to the move gizmo.
3. Paste the Condition ID of the sphere condition into the "Message Broadcast" field of the Action, or set the field to "all_conditions".
4. Save Objects, and then run your map in game.
5. Walk your character into the trigger area.

Your character should walk into the trigger area, and then, because he is now the catalyst of the spatial trigger, immediately walk to the location of the cmd_c_ai_move gizmo. (After arriving at the waypoint, your character may try to walk back to the point where you initially clicked. This is because your initial move order was not cleared; setting the "placement" value in the move gizmo to "qp_clear" should prevent this behavior.)

As previously mentioned, most Catalyst AI Commands were never used in the game. Practically the only Catalyst AI Commands used are the Move and Patrol commands. The other commands should work just fine, but since they haven't been used or tested for so long, your mileage might vary. Most of these gizmos are self-explanatory, especially since the "Documentation" fields do a good job of describing their function and use. Rather than duplicating these fields, we'll look at some of the special cases:

(NOTE: In the current SE version, the development name/description for all Catalyst AI Commands do not use the _ai portion of the actual template name. For example, the actual template name (and the name found in the .gas files) for "cmd_c_move" is "cmd_ai_c_move". This naming oversight will hopefully be fixed in a future SE version.)

Gizmo Notes:

• cmd_ai_c_animate: This was only used a few times in DS, mostly because it was replaced by the "cmd_animation_command" gizmo. Use "cmd_animation_command" under the "specialized" subdirectory instead of this gizmo, which can support both catalysts and targets (see Manipulation Commands, below).
  
• cmd_ai_c_attack_object: This command requires both a catalyst (derived from a spatial trigger) and a target (SCID of an object pasted into the "Target1" field). When activated, the catalyst will attack the specified object.
  
• cmd_ai_c_drop/equip/give: Each of these commands references an inventory object that the catalyst drops/equips/gives. These objects must come from or be going to an equip slot. The SCID of the object is pasted into the target1/target2 field (depending on the gizmo), and the location or desired location of the object is entered into the "slot" field. Note that the "cmd_inventory_changer" duplicates much of this functionality, plus allows you access to regular inventory items (see Manipulation Commands, below).
  
• cmd_ai_c_move: If multiple Actors are given this command, they will all move onto the gizmo, possibly standing on top of each other. If you want to move the Player's Party Members in formation, use "cmd_move_party" under the "specialized" subdirectory instead (see Party Commands below). Also, Actors will not attack enemies they encounter while moving to a cmd_c_move waypoint (use cmd_c_patrol instead for move-attack orders).
  
• cmd_ai_c_move_orient: Same as above, except the Actor(s) will face in the direction of the gizmo's arrow upon completion of the command.
  
• cmd_ai_c_patrol / cmd_ai_c_patrol_orient: Same as the above two gizmos, except that Actors will attack enemies along their route.

Linking Catalyst AI Commands:

Catalyst AI Commands can be linked--much like NIS cameras--resulting in the catalyst being passed from one Catalyst Command to the other, upon completion of the previous Command. In this way, a catalyst can be given new AI commands without needing a new spatial trigger to redefine the catalyst.

To link Catalyst AI Commands, either paste the next Command's SCID into the first Command's "next_scid" property, or right-click on the first Command, select "Link Object", and left-click on the second Command.

Target AI Commands

These Commands are found under "Game Objects/Gizmos/Commands/ai/target_commands".

Target AI Commands are used when you know the exact SCID of the Actor to manipulate. They are mostly identical to Catalyst AI Commands except they require the target's SCID be pasted into the gizmo's "Target1" field, and they do not usually require a catalyst. Actors without a SCID, like the starting player character or a monster from a generator (basically any Actor that was not placed within SE), cannot be the targets of a Target AI Command. Like the Catalyst AI Command, the Target AI Command executes when it receives a "we_req_activate" message.

Do the following in your test map:

1. Place a trigger_generic gizmo and a cmd_ai_t_move gizmo.
2. Place a dwarf worker NPC at some distance from the move gizmo (Game Objects/actors/good_characters/townspeople/regular/dwarf_worker).
3. Give the trigger a "player_within_sphere" condition, and send a "we_req_activate" message to the move gizmo.
4. Paste the SCID of the dwarf_worker into the "target1" field of the move gizmo.
5. Save Objects, and then run your map in game.
6. Walk your character into the trigger area and watch the dwarf worker.

When your character enters the trigger area, a "we_req_activate" message is sent to the move gizmo. Because the dwarf_worker's SCID is the target of the move gizmo, the dwarf_worker moves to the gizmo's location.

Gizmo Notes:

Most Target AI Commands are identical to their Catalyst Command counterparts, except they require a SCID in their "Target1" field.

Just like Catalyst Commands, many Target AI Commands were never used in the game. Practically the only Target AI Commands used are Move, Patrol, and Attack Catalyst.

• cmd_t_animate: Use "cmd_animation_command" under the "specialized" subdirectory instead, which can support both catalysts and targets. NOTE: There are TWO instances of "cmd_t_animate" in the SE list as of the latest version (1.09.2.318). The second instance is named incorrectly-if you place it, you will see that it is actually "cmd_ai_t_die".
  
• cmd_t_*_catalyst: These commands (attack, face, guard) require both a target (pasted into the "Target1" field) and a catalyst (sent from a spatial trigger). When activated, the target will perform the specified action on the catalyst.
  
• cmd_t_die: Incorrectly listed (in SE v1.09.2.318) as a second "cmd_t_animate".
  
• cmd_t_follow_catalyst: Incorrectly listed (in SE v1.09.2.318) as a second "cmd_t_follow".

Linking Target AI Commands:

Like Catalyst AI Commands, Target AI Commands can also be linked. However, the SCID of the target must be pasted into every gizmo in the chain-the next gizmo will not inherit the previous gizmo's SCID. Note that linked Target AI Commands do not have to refer to the same SCID; each successive linked gizmo can refer to an entirely different Actor. This is sometimes useful in timing events.

Manipulation Commands

These Commands are found under "Game Objects/Gizmos/Commands/specialized".

"Manipulation Commands" is just an arbitrary name to talk about a few commonly used gizmos that affect Actors. Rather than assigning an AI job, most of these gizmos change Actor properties in useful ways.

We'll talk about these four gizmos:

• cmd_alignment_changer
• cmd_animation_command
• cmd_inventory_changer
• cmd_selection_toggle

The Alignment Changer (cmd_alignment_changer)

The name of this gizmo belies the fact that it is a highly versatile and useful gizmo for Actor manipulation. It accomplishes many basic functions necessary to control Actor behavior, especially during scripted sequences. A single alignment_changer can only affect a single Actor.

In addition to changing the alignment of an Actor, the gizmo can also toggle the following:

• Whether the Actor animates
• Actor invincibility
• Whether the Actor can be hit with weapons or spells
• Whether the Actor can attack or be attacked
• Actor visibility
• Whether the Actor can be "selected" (i.e. can be interacted with by the mouse)

The alignment_changer can be set to one of three basic states at any time, where each state sets one or more Actor properties. The three states are keyed to the reception of the "we_req_use", "we_req_activate", and "we_req_deactivate" messages. There is no using, activating, or deactivating going on; these three messages only serve to change the state of the gizmo, and may as well be named "1", "2", and "3". The gizmo can receive any number of these messages in any order, changing the Actor's properties each time. Let's look at how this works, by checking out the cmd_alignment_changer's properties.

The [cmd_dumb_guy] Block

The [cmd_dumb_guy] block is the component block within the cmd_alignment_changer's properties that controls its function. After a field to identify the target Actor's SCID, there are three blocks of redundant fields, each setting Actor properties for the three messages (we_req_use, we_req_activate, we_req_deactivate). Finishing the block is a number of fields that allow/disallow types of property changes, as well as setting the initial state of the gizmo.

The Target

• target_actor: SCID of the target Actor. This gizmo will begin affecting the Actor immediately once they are both loaded into the frustum, unless told otherwise (the "start_state" value).

The "we_req_use" State

The "we_req_use" state is commonly used to "suspend" an Actor as soon as he spawns, waiting for either an activate or deactivate message to change his properties. The default values for this state reflect this suspension, but the settings can be changed to any desired value. The Actor's properties will be changed to these values when the cmd_alignment_changer receives a "we_req_use" message.

• alignment_spawn: (aa_good / aa_neutral / aa_evil) Sets the alignment of the Actor to this value when the gizmo receives a "we_req_use" message. The default for we_req_use is "neutral", ensuring that this Actor will not attack good or evil Actors, or be attacked by them. Default: aa_neutral.
• life_state_spawn: (ls_ignore, ls_alive_conscious) This value affects whether the game engine considers the Actor to be "alive" or not. According to the engineers, this property was never meant to be exposed in a gizmo; it was supposed to remain an internal engine thing. As a result, nobody is entirely sure what the repercussions are of setting this to "ls_ignore" are. The good news is, because the "may_attack" and "may_attacked" flags now exist, it is never necessary to set this value to "ls_ignore" in order to force other Actors to ignore the target Actor. The "we_req_use" block sets "ls_ignore" by default however; you may consider setting it back to "ls_alive_conscious". Default: ls_ignore.
• update_anim_spawn: (true / false) Determines whether the Actor can run animations. Default: true.
• invincible_spawn: (true / false) Determines whether the Actor is invincible or not. Default: false.
• collide_spawn: (true / false) Determines whether the Actor can be hit by weapons or spells. Default: true.
• may_attacked_spawn: (true / false) Determines whether the Actor can be attacked by any other Actor. Default: false.
• may_attack_spawn: (true / false) Determines whether the Actor can attack another Actor. Default: false.

The "we_req_activate" State

The "we_req_activate" state repeats the same properties as the "we_req_use" state with slightly different names ("*_activated" instead of "*_spawn"). The activated state is commonly used to turn an Actor into a normal, evil, attackable monster, and the defaults reflect this.

The "we_req_deactivate" State

The "we_req_deactivate" state repeats the same properties as the previous two states, again with slightly different names ("*_deactivated"). The default values are the same as the activated state: they set an Actor to normal, evil, attackable qualities.

Toggles

The final section of the [cmd_dumb_guy] block tells the gizmo which properties in the above three states to actually change, and which values to ignore. In this way you can limit the gizmo to only changing the alignment and nothing more. This block also allows you to set whether the Actor is selectable or invisible on a we_req_use, and lets you set which state the Actor spawns in.

• change_alignment: (true / false) Allows/disallows changes to Actor alignment. Default: true.
• change_life_state: (true / false) Allows/disallows changes to Actor life state. Default: true.
• change_selection: (true / false) This value does not have a corresponding value in the above three states. If "true", this setting causes the target Actor to be non-selectable (i.e. you cannot interact with the Actor with the mouse, or even get mouse-over text) in the "we_req_use" state only. Default: true.
• change_visibility: (true / false) Like the previous value, this does not have a corresponding value in the above three states. If "true", this setting causes the target Actor to be invisible in the "we_req_use" state only. Default: false.
• change_invincibility: (true / false) Allows/disallows changes to Actor invincibility. Default: false.
• change_collide: (true / false) Allows/disallows changes to Actor collision. Default: false.
• change_may_attacked: (true / false) Allows/disallows changes to the "may_attacked" property. Default: false.
• change_may_attack: (true / false) Allows/disallows changes to the "may_attack" property. Default: false.
• start_state: (0-3) This is an important property, since it allows you to set which state the Actor will be in when he spawns. Default: 0.
  • 0: No change to Actor.
  • 1: The Actor will start in the "we_req_use" state.
  • 2: The Actor will start in the "we_req_activate" state.
  • 3: The Actor will start in the "we_req_deactivate" state.

How to use this gizmo?

This gizmo is used in NIS's all the time, and is useful for many scripted sequences. The most common way to use this gizmo is to change a speaking "evil" actor from aa_neutral to aa_evil after his speech (e.g. Gresh, Swanny, Gom). Another common usage is to make an Actor invisible and non-interactive until needed (e.g. the spider in the intro NIS, Norick, the Goblin Inventor). Once an Actor is finished with, you can make him invisible and non-interactive (e.g. the intro spider and Goblin Inventor again-in fact, there are three different Goblin Inventors in the SP NIS… one on the pipe, and two on the platform: one for going down, and another that appears when the Robosuit is destroyed. Each instance of the GI is made visible/invisible by a cmd_alignment_changer).

The Animation Command (cmd_animation_command)

The animation_command was created after the Catalyst and Target AI "animate" commands, and is a much more powerful gizmo. This command has already been touched on in the "NPC Animations" section of SU: 208A.

This gizmo is useful in calling specific animations for the target Actor. As mentioned in SU:208A, the Actor's base template must have the FourCC animation listed in its [chore_misc] block.

The [cmd_animation_command] Block

Many of the components of this block are adequately documented, and should make sense. Let's go over the more important fields:

• animate_catalyst: (true / false) If true, the client_scid property is not used. Instead, any catalyst passed to this gizmo with a spatial trigger will be animated instead. Default: false.
• chore: (chore block) Which [chore_*] block of the Actor's [chore_dictionary] to look in for the FourCC animation. This is almost always "chore_misc". Default: chore_misc.
• animation: (FourCC animation) This field is where the FourCC animation code is entered. SE will convert this value into a number string. To see the original FourCC text description on later viewings, make sure the FourCC box is checked at the top of the Template Properties tab of the Object Properties window.

The Inventory Changer (cmd_inventory_changer)

This is another important gizmo, simply because it allows you to perform a drop, equip, or delete action on any object in an Actor's inventory--whether the Actor is a catalyst or a target, whether the object is equipped or sitting in general inventory, and whether you are targeting the object by SCID (specific object) or by template (specific kind of object). These qualities make this gizmo much easier to use than the Catalyst AI or Target AI inventory commands.

This gizmo only operates on a single object, even if the gizmo is targeting by template and there are multiple instances of the same templated object in the Actor's inventory. If you know the SCID of the object, it is better to target by SCID.

It seems that the inventory_changer is a one-shot gizmo, meaning that it will perform its action on the target object once only. During testing for this article, it was impossible to have the target Actor drop the same item more than once, even if he picked it up and walked through the "drop" trigger again.

The only bit of trickery in using this gizmo is in triggering it effectively. This gizmo absolutely requires a catalyst in order to operate; otherwise the inventory_changer doesn't know which Actor it should be operating on. We'll talk about this after looking at the [cmd_inv_changer] component block.

The [cmd_inv_changer] Block

This is a short and simple block.

• object_scid: (SCID) SCID of the target object. Only used if "go_within_sphere" is false.
• go_within_sphere: (true / false) If true, the "template_name" value is used to target the inventory object. If false, the object SCID is used for identification. Default: false.
• template_name: (template_name) The template name of the target object. Only used if "go_within_sphere" is true.
• msg_type: (message) A message to send to "msg_scid" when performing a delete job. This is useful when you want to delete an object from the Player's inventory and then make a corresponding object "appear" in the environment at the same time. Default: we_req_activate.
• msg_scid: (SCID) SCID of the object to send the "msg_type" message to when performing a delete job.
• job1: (drop / equip / delete) Which job to execute on the target object. These values are case-sensitive.
  • drop: Actor drops the target object onto the ground.
  • equip: Actor equips the target object.
  • delete: The target object is deleted.

Wiring the Inventory Changer

By itself, the inventory_changer does nothing. You can send it a we_req_activate message from a trigger, and nothing will happen. The inventory_changer needs to know where to look to find the target object, and so needs a catalyst-but there is some flexibility over who the catalyst actually is. This flexibility comes from the fact that we can derive a catalyst from either a normal spatial trigger (i.e. actor/player_within_sphere/bounding_box/node) or the "has_go_within_inventory" condition.

Wiring with a Normal Spatial Trigger

Let's look at an example:

1. Place the following objects in your test map:
   1. 1 trigger_generic gizmo
   2. 1 cmd_inventory_changer gizmo
   3. 2 cudgels (Game Objects/weapons/clubs/cudgel) away from the trigger_generic
2. Configure the inventory_changer:
   1. Copy the template name from one of the cudgels (cb_g_c_r_1h_avg)
   2. Open the cmd_inventory_changer and paste the value into the "template_name" field.
   3. Set "go_within_sphere" to "true".
   4. Set "Job1" to "drop".
3. Configure the trigger_generic:
   1. Copy the SCID of the cmd_inventory_changer.
   2. Open the trigger_generic and add a "party_member_within_sphere" Condition.
   3. Send a "we_req_activate" message to the inventory_changer (paste the SCID).
   4. Set the catalyst for the trigger by setting the "Message Broadcast" field to "all_conditions" (or paste the Condition ID of the party_member_within_sphere condition here).
4. Save the map and run it.

Once in the game, pick up one of the cudgels and walk into the trigger area. When you walk into the sphere, the cudgel should drop out of your character's inventory to the ground. Note that if you pick up the cudgel and walk back into the trigger, nothing will happen.

If you have the Release DS executable (the .exe with access to the dev console), try the following:

1. Reload GOs ("reload gos" at the console)
2. Mouse over valid terrain and add another party member ("add p farmboy" at console)
3. Give each Party Member a cudgel.
4. Walk one of the Party Members into the trigger area.

Only the character that walked into the trigger area drops the cudgel, because he is the catalyst of the "party_member_within_sphere" condition-the cmd_inventory_changer gizmo looks at the catalyst to see if the target object is in his inventory, and if it is, the catalyst drops it.

Wiring with "has_go_in_inventory"

Let's look at another more complex example:

1. Open the same test map from the previous example.
2. Add a new Condition: has_go_in_inventory. The "party_member_within_sphere" Condition is now the first in the list.
3. Paste the template name of the cudgel (cb_g_c_r_1h_avg) into the "Template name filter" field of the "has_go_in_inventory" Condition.
4. Change the catalyst by pasting the Condition ID of the "has_go_in_inventory" Condition into the Action's "Message Broadcast" field.
5. Save the map and run it (or, if the game is still running, just type "reload gos" at the console to update the game to your latest map).
6. Give one of your Party Members a cudgel.
7. Walk the second Party Member (without the cudgel!) into the trigger area.

When the first Party Member walks into the trigger area, the second Party Member, who is not in the trigger area, will drop the cudgel.

The first Condition is true when a Party Member walks into the trigger area, but the second Condition is true when ANY Party Member (in SP) has the cudgel, and the trigger will not fire until BOTH Conditions are true. Because the catalyst has been set to the result of the "has_go_in_inventory" Condition, the cmd_inventory_changer gizmo will operate on the Party Member with the cudgel, whether or not he was the one who walked into the trigger area.

If you change the catalyst by pasting the Condition ID of the "party_member_within_sphere" into the Action's "Message Broadcast" field and repeat the above experiment, the second Party Member will NOT drop the cudgel. The catalyst is now the result of the sphere Condition, and that Party Member does not have a cudgel.

The Selection Toggle (cmd_selection_toggle)

This is a confusing gizmo, since it appears to duplicate part of the function of the alignment_changer. The difference is that the alignment_changer MUST operate on an Actor, whereas the selection_toggle can work on any object.

This gizmo is very similar to the alignment_changer, except that there are only two states instead of three, and you can define which messages toggle the two different states. The selection toggle can change the following properties for any object:

• Selection: This sets whether the mouse can interact with the target object, including whether a mouse-over description is seen.
• Usability: This sets whether an Actor can "use" the object, like a door or switch. The object is still visible; it just cannot be used as normal.
• Visibililty: This sets whether the object is visible or not. This is the only gizmo that can toggle the visibility on a non-Actor object. Note that while an object can be invisible, it may still be selectable, and produce a mouse-over description and a cursor color change.
• Invincibility: This sets whether the object takes damage or not.

The documentation on the gizmo component fields does a good job of explaining the particulars of the gizmo.

Party Commands

These Commands are found under "Game Objects/Gizmos/Commands/specialized".

There are three commands that fall into the "Party" category:

• Party Move (cmd_move_party)
• Party Stop (cmd_stop_party)
• Party Wrangler (cmd_wrangle_party)

Each of these commands acts only on Party Members, but their behavior changes depending on if you are playing in Single Player (SP) or Multiplayer (MP).

• In SP, every Party Member belongs to a single Party, so these gizmos act on every Party Member at once, regardless of where they are in the world.
• In MP, each Player is their own Party, so these gizmos will only act on the Party Member who is the catalyst.

That being said, Party Commands are almost exclusively used in the SP game, specifically during NIS's. All Party Commands require a catalyst in order to function, and require reception of the "we_req_activate" message.

The Party Move Gizmo (cmd_move_party)

The primary purpose of this gizmo is to move the entire Party to a single point on the ground. The Party will orient themselves in a delta formation on arrival (preventing overlap), and they can be optionally made to face in a particular direction. All Party Members in the same frustum as the gizmo will receive the command.

This is the preferred method of forcing the Party to move to a spot, rather than the "cmd_ai_c_move" command, which results in unsightly overlap.

The [cmd_party] Block

The only parameter worth changing in the [cmd_party] block is the FacePoint parameter. If you want the Party to face in a particular direction on arrival, set this value to the SCID of an object within the frustum. The party will then face this object when they get to the Party Move waypoint.

Contrary to the existing documentation, the "move_to_point" functionality does not work, and should not be used. Setting "move_to_point" to true will result in the Party bunching up near the gizmo, and should be avoided.

The Party Stop Gizmo (cmd_stop_party)

The Party Stop gizmo is identical to the Party Move command in every way, except it orders Party Members within the same frustum as the gizmo to "stop" instead of move. Characters that receive a "stop" command will immediately revert to default AI and animations, just as if the Player had issued a "stop" command with the keyboard (S).

The Party Wrangler Gizmo (cmd_wrangle_party)

The Party Wrangler gizmo has already been covered in detail in the "Party Wrangler" section of SU 207: NIS.

Conclusion

We've covered the important Actor and Party Commands available for use within SE. While each of these gizmos is incredibly useful, many of them were not used much in DS1, because they were either tricky to use, did not always work, or nobody knew how they worked. A lot of more complex behavior ended up being driven by other systems, such as skrit.

Luckily, this document you are reading has a lot of information that just wasn't available while the game was being built, so you should have better luck! For most applications, these commands are highly versatile and will get you the behavior you want without too much complication. This document should give you a much-needed "leg up" on understanding how these commands work and how to implement them.

Good luck modding!