To place an AI:
Lay out volumes (make a brush and attach it to an AIVolume). Put them on the floor. Make them tall enough to contain the AI. Don't let any world models or world geometry be inside of them.
Put an AI in the level. Be certain the AI is in an AIVolume, they will not leave volumes.
Select the AI's CharacterType and AttributeTemplate. There is only one AttributeTemplate at the moment, but they'll be more, you just wait and see.
Give the AI a goal or two. For starters you need only name the goal type and give it any needed parameters. The default goals are Attack and Investigate. For Attack you need only to choose that goal type. For the patrol you will need to create patrol nodes and set Link to point to one of them.
If you want an AI to patrol, set up some AIPatrolNodes. Each
node should point to the next node to go to. Make the chain a circuit if you want to. Otherwise the AI goes back and forth along the route.
There are different classes for each race (ie. AIAlien, AIPredator, etc.)
Selects type of game (ie. Death Match, Single Player, etc.). Same as Prop object.
unused
Handles damage properties of AI, just like Prop object.
unused
Selects the model and general character properties to use. This is a list generated from AVP2\Attributes\CharacterButes.txt.
Moves object to floor when level is loaded, just like Prop object.
When killed, a dead body will be generated if set to TRUE.
The AI's have multiple goals. Each goal has a bid, which is basically a priority. Higher bids will be acted upon first. The AI's also have goals defined in their attribute template.
See Goals section for more information on goals.
Unique name for goal (so that triggers can modify the bid for the goal).
No longer accessible in dEdit.
If goal requires an object (such as Patrol), this specifies it.
Other parameters the goal may
take.
Overrides some attribute template defaults.
Unused.
Selects a weapon for the AI to use. Weapons are drawn from AVP2\Attributes\Weapon.txt.
Selects the AI attributes. These control the AI specific properties such as Weapon type, aggressiveness, etc. Found in AVP2\Attributes\AIButes.txt.
This string is sent to the AI as a trigger when the level is loaded.
This string is sent to the AI as a trigger when the player activates the AI.
This string is sent to the AI as a trigger when the player de-activates the AI.
Currently defaults to FALSE. Set to TRUE if you want the AI to use AINodeCover
points that you have placed in the level. This results in a more cautious AI. They will use these nodes when advancing and dodging.
If true, acts as if you sent "nvrlstrgt on" to the AI. Basically, the AI will keep
chasing and attacking their target whether the target is visible or not. Aliens always have this true.
SimpleAI are actually a subset of Character. They have lower tickcounts than AI, but at a cost of functionality.
What they can do
SimpleAI are intended for melee
attacking creatures. Currently, only the
SimpleAIAlien is implemented. They activate when the player gets within
range, and try to chase him until they are killed. The SimpleAIAliens
have wallwalking turned on at all times. They will also attack someone who damages them.
What they can't do
Unlike normal AI, these guys will not use pathfinding. They also do not have any support for script
commands, goals, or senses.
Supported Trigger Commands
TRG
REMOVE
DEdit Properties
DetectionRadius: attacks when player enters this radius.
AlertRadius: when this SimpleAI has a
target, other SimpleAIs in this radius will acquire
the target if they do not have one already.
Leash Length / Point: works same as normal AIs.
SimpleAIs are now supported in
the Multispawner object.
Eggs are actually specialized spawners, but they have some attributes that warranted documenting here.
Eggs may spawn either a Facehugger or a SimpleAIFacehugger. They play a warning sound when the player gets too close. If the player does not leave the radius within a specified time, the egg will hatch. The warning sound will stop if the player gets to a safe distance.
DEdit Properties
UseSimpleAI: if set to TRUE, the egg will spawn
a SimpleAIFacehugger.
IgnoreAI: TRUE means this egg can only be
caused to spawn by players.
DetectionRadius: egg will warn and then hatch if
someone is inside this radius.
WarningTime: time delay between the warning
sound, and the actual hatching.
AIVolumes are made by
attaching an AIVolume object to a brush. Only one brush should be associated with a
volume. There is an "AI" texture under WorldTextures. It is only a convenience. The brushes will be removed when the level is
loaded, so their properties don't matter (but the AIVolume
properties do matter!).
The brushes can be any convex
shape but cannot overlap. Neighbor volumes are determined by checking faces
that fully touch (are co-planar). So if
you want an AI to know that she can go from volume to volume, be certain the
two volumes share a face! The overlapping
region has to be a rectangle. The AI
will assume it can move anywhere within the volume, so big blocky volumes are
best.
The volumes mark clear areas for
the AI. Clear means no world geometry or
world objects are inside the volume. The
AI-s will only go around Props, Players, and other AI-s within the volume.
At minimum, the volumes should be
able to contain the AI. So, for ground
based volumes, the volume should be on the floor and as tall as the tallest AI
that will use it.
The AI Volumes no longer have wall walking properties. If an AI is "using" a volume to move to a point, the AI will stand-up and walk or run there. An AI "uses" a volume if the destination is just a point in space enclosed by the volume, or if it is a node which connects to the volume (VolumeConnect true).
The AI-s will almost never leave the volumes at
this time. Likewise, the node system is
not used for "pathing" (only for marking patrol
waypoints). So if you want the AI to get
to a node, be sure to put the node inside a volume.
The door volumes are in
place. You have to explicitly set the "DoorVolume" property on the AIVolume
object. A door volume should encompass
(including height) the door, and not much more. At the moment, AITriggerable is not
checked. In the future, the volume will
check if the door has AITriggerable set. If AITriggerable is
not set, the AI will only try to go through that volume if the door is open.
The Stair flag can be set to true
if this volume encompasses a staircase or ramp. When set to true, AIs who die inside this
volume will play their falling-down-stairs death animation. You must
set the rotation of this AIVolume to point in the
direction that you want the AIs to fall.
Ground based nodes should be marked as MoveToFloor,
so that ground based AI-s can reach them.
All nodes can be wall walk only nodes. The restrictions for AINodeWallWalk
(like having to touch a face) apply to any node marked as wall walk only.
ConnectToVolume indicates whether
a volume containing that node should consider that node reachable. It is intended to keep wall walkers in the
wall walk nodes rather than short cutting through a volume.
The Neighbor fields are intended for wall walk nodes. Non-wall walk nodes may do something
intelligent with the neighbor field, but there is no guarantee. It is best to only use the neighbor stuff for
wall walk nodes.
If any of these fields is set to false, that race of AI's will not be able to use the node. Other restrictions (node is outside leash, node can only be used by wall walkers, others?) still apply.
The dimensions of the node. The dimensions are only used by wall walk nodes to determine what faces they are touching.
If true, the node will be moved to the floor. Almost all non-wall-walking nodes should do this.
If true the node will be usable by an AI from the
get-go. Otherwise the node will need to
be activated via an AINodeMgr object.
See AINodePatrol.
See AINodePatrol.
See AINodePatrol.
Indicates that this is a wall walk node. See AINodeWallWalk for requirements of wall walk nodes.
Indicates that the node should connect to the volume containing. You will usually want to leave this true. Wall walking nodes are the only time you may not want to connect to a volume.
Use these to connect nodes together or explicitly to certain volumes. You need only do this with nodes not in a volume or not having VolumeConnect turned on (wall walk nodes). When a node is connected to another node, it is assumed that the AI can reach that node by walking straight toward it.
These connections are two-way. You only need to make the connection from one node, the other node will automatically do the reverse connection.
Use this to indicate that the AI should jump to a certain node. The AI does not check for clearance! If the destination node is a wall walk node, the AI will "pounce" to that node. A "pounce" is a direct jump with no arc, and the AI is non-solid during the "pounce".
Unless you specify a TwoWayJump, this is a one-way connection. If you want the AI to jump both directions between two nodes you need to set each to jump to the other.
If true, the JumpTo property will become a two-way connection. Just like the other Neighbor fields.
A patrol goal is given a patrol node. The path formed by the linked patrol nodes
are what the AI will walk along. The
path can be circular.
The AI will wait this many seconds at this point. If the AI does wait he will face in the same direction as the node. 0 is allowed (and the node facing will be ignored).
Indicates next Patrol node the chain. If there is not a next node, AI will follow the node chain in reverse order.
When the AI reaches the patrol node, a trigger message will be sent to this object. If you want any advanced triggering (like only trigger once, delayed trigger, etc.) I would suggest setting up a second trigger to be triggered by the patrol node.
This is the message sent to the TriggerObject.
If this is non-empty, the AI will be sent a trigger with this message. I expect this to be used for having the AI's work at terminals and such.
If there is not a NextPoint,
this parameter is checked. If TRUE, the AI will follow the path in the reverse direction. If FALSE, the patrol goal will deactivate
itself. To get an AI to go back and
forth along a path, set Cycle to TRUE on both ends of the path.
This is a node used for defensive purposes. They do not link like Patrol nodes, and most
of the behavior is automatic. An AI will
choose a node and lock it until departure; these nodes are not shared with
other AIs.
EFFECT ON AI MOVEMENT
(only applies to AIs
who have their UseCover flag set to TRUE)
a) Attack goal uses these nodes to advance, instead of the standard ApproachTarget code. It will pick the nearest AICoverNode that is
in the direction of its target, AND blocks line of sight to the target.
b) Dodge behavior is enhanced by cover nodes. When fired upon, the AI will try to find a Cover Node which blocks line
of sight to the target, and go there. If
there are no such nodes in range, then the AI will fall back to the standard
dodge behavior (random left / right).
NOTE #1: Remember to use 2 nodes - one on each side of an obstacle/brush, if you want to provide cover in both directions. The AI will try to go to the one that obstructs its target's visibility.
NOTE #2: AIs may use these nodes differently, depending on their
current goal. For example, an AI in the
Attack goal will only consider nodes that help it move closer to its target.
If set to TRUE, the AI will crouch when it arrives at this node. It will then stand up and attack from this position (if possible). When it needs to reload, it will crouch to reload.
An AI must be inside this radius in order for it to choose
this node as a valid dodging destination. Default is 128 units.
Set this to true if you want the AI's to use this as a cower node.
These are to be used to get an AI to wall walk. The wall walking volumes are having many problems and should only be used on simple geometry.
The node has only neighbor link fields. The node can be linked to another AINode of any type or another volume. If a node is placed inside a volume, the volume will automatically link to it.
The wall walking AI's are able to traverse and use these
nodes just like volumes. When an AI is
using the node, it will simply move forward and turn left/right until it
reaches the node. "Reaching" the node is
defined as having the node within the AI's bounding box; so put the nodes close
to the wall.
Place the nodes near or on the wall or ceiling the AI is to be walking on.
The nodes can have up to 5 neighbors. The neighbor connections are two way; so if
node Alpha has node Beta in its list of neighbors, there is no need to list
node Alpha in node Beta's neighbor list.
If a node is placed in a volume, it will automatically
connect to that volume. AI's will know
that they can go to that volume to get to that node. If you do not want the AI's to move from a
node inside a volume to the volume set "VolumeConnect"
to false. This is sometimes needed when
several nodes need to be placed on a wall below the height of the volumes. Mark all but the last node in the chain as "VolumeConnect: FALSE", and the AI will always use the chain
of nodes (rather than highest node contained by the volume).
AI's do best when the node is placed in the middle of a brush face. If it all possible, make sure the next node(s) to go to are not directly above or below the current node.
The Snipe goal will camp out on these nodes.
The AINodeGroup field is used to
assign this snipe node to an AINodeGroup object. AIs with the Snipe
Goal may limit themselves to an AINodeGroup, if
desired (see Snipe Goal, below).
Purpose: Alarm nodes tell the AI where they can turn on the alarm for the level. Typically, this would be near some kind of button on the wall. The node needs to be aligned so that it points towards the switch.
Usage: In the node's AlarmObject field, you must specify an Alarm object that will be triggered. The node's AlarmMessage can be ON or OFF. Usually you will have multiple AINodeAlarms, but only one Alarm object on a level. This Alarm object handles the sound effect, and can trigger off other events (such as spawners).
Effect: When an AI with the Alarm goal detects the player, he will find the nearest AINodeAlarm, lock it, and run to it. When he arrives, he will rotate to match the node's forward vector. He then plays his Push_Button animation and a message will be sent to the Alarm object. All AIs will exit the alarm goal when the alarm is turned on for the level.
Similar to Snipe nodes, Alarm nodes may be assigned to an AINodeGroup.
This is just a simple little node. Use it when you just need a node.
This is intended for non-wall-walking movement.
The AI will jump from the jump node to the destination node.
The connection is one way. If the AI jumps from on volume to another and there is no other connection between the two volumes, the AI will not be able to return to the previous weapon.
If you want an AI to be able to jump from one spot to another, you need to use two jump nodes. Just set each node to be the destination of the other.
The AI is solid while jumping, so if she bumps into some geometry
while in mid-air she will not reach her destination. Jumping up onto ledges requires a little node
placement work. If the jump node is too
close to the base of the ledge, the AI will just hit the ledge and fall back
down to the base of the ledge.
The destination of the AI's jump. This must be another node. AINodeGeneric comes in handy for this.
These are nodes used by the simple aliens to help navigate indoor levels.
The simple aliens will use the nodes if they have been in a node in the past (or are currently in a node), if their target (the player?) has been in a node in the past, and if there is a path from their previous/current node to their target's previous/current node. The simple aliens will keep moving to the next node in the path until they get inside that node. They will then proceed to the next node.
Being inside the node is defined as being inside the y-dimensions of the node and within the radius of the node in the x-z plane. So the nodes form cylinders. The last node is the closest previous (or current) node which they were inside.
SimpleNodes automatically connect by having their radius and height over-lap.
In order to prevent simple ai from getting stuck when placing nodes, they must be placed so that:
a) The radius does not contain a face pointing away from the node. This gets tricky when placing nodes around the end of wall, as the radius cannot include the opposite side of the wall.
b) The connections do not go straight through a wall. The connection can cut a corner, but it cannot actually go from one side of a wall to the other. It is better if the connections does not even cut a corner.
The dimensions of the node. Only the y-dimension is used.
The radius of the node. If a character's x-z position is within this radius of the node's x-z position, and they are within the y-dims. of node, they are inside the node.
This can be used to place an offset attractor. When trying to reach a node, the simple aliens move toward the attractor. I suggest only using this to push the attractor up (toward the ceiling) or down (toward the floor) to help get them higher or lower. The nodes actual position is still used to determine if they are inside the node (and they stop moving toward the attractor as soon as they get inside the node).
The AI's have multiple goals, but only one is active at a time. Each goal has a unique name, a type (such as Patrol or Attack), a priority, and various goal specific parameters. The highest priority goal that is valid will become the active goal. Goal validity is mostly determined by whether the goal has valid parameters and whether the AI can use the goal on something (ie. the AI must have a target before Attack will become valid).
Here are how the goals become active:
Script - always valid until receives "end" or is explicitly killed.
Alarm - Valid if has a combat target and can find an alarm node. Valid until the alarm is set.
Snipe - Valid as long as the AI has a goal and an enemy is not within MinRange (see snipe goal).
Lurk - Valid if has a combat target. Valid until target is lost (very rare to lose a target).
Attack - Valid if has a combat target. Valid until does not have a combat target (killed target and can not find another).
Retreat - Valid if sees an enemy. Valid until AI does not have target (target died).
Investigate - Valid if triggered by "inv" command or one of these senses gets raises above 0 (in order of preference) : SeeDeadBody, SeeEnemyFlashlight, HearEnemyFootstep, HearAllyWeaponFire, HearWeaponImpact, HearDeath, HearAllyPain,SeeCloaked, SeeBlood (not currently working). Valid for duration of investigation routine.
Cower - Valid if one of these senses is fully triggered (reaches 1.0 SeeEnemy, SeeDeadBody, HearWeaponImpact, HearEnemyWeaponFire. Length of goal is described in Cower goal description.
IdleScript - Just like script.
Patrol - Valid if the AI has a patrol path.
Goals no longer use a priority
field in DEdit. Instead, they use a default value which currently (1/12/01) uses the
following values:
|
Script |
90.0 |
|
Alarm |
75.0 |
|
Snipe |
70.0 |
|
Lurk |
65.0 |
|
AttackSeeEnemy |
60.0 |
|
Retreat |
55.0 |
|
Investigate |
40.0 |
|
Cower |
35.0 |
|
AttackOther |
30.0 |
|
IdleScript |
20.0 |
|
Patrol |
10.0 |
I'm trying to stick with a 1 - 100 range to keep it
consistent. When you add goals in DEdit now, it doesn't matter what order you list them. They will prioritize based on the values in
this table.
Must be given an AINodePatrol object. When started, the AI will find the closest node in the chain and move towards it. When it reaches that node, the AI will wait the amount of time it is told to wait and then go to the next node in the chain. If you want the AI to follow a circuit, make a circuit. If the chain does not form a circuit, the AI will go back and forth along the chain of nodes.
Take a guess..... Yep, the AI will attack an enemy! This doesn't have any parameters at the moment. The AI will attack anything it hates. Right now, all AI's hate the player and love each other.
Attack is special. SeeEnemy, HearWeaponFire, HearWeaponImpact, and HearEnemyFootstep can activate this goal. However, only SeeEnemy will cause it to override Investigate behavior.
This is intended for AI's with melee weapons. The AI will try pretty hard to flank the player. They will also jump occasionally. The flanking and jumping parameters are set by the AI Attribute template. Note that the weapon's range determines how close the AI will approach. So if you give an AI with a rifle a melee attack they will still keep a reasonable distance back, but they will constantly try to flank the player and occasionally jump.
No longer implemented - was for debugging purposes only.
The AI will follow the script given to it. This goal is always valid and more important than any other goal. To make the goal end either explicitly kill it or give it the script command "end". See scripting below.
Same as a script goal but of lower priority, it is more important than patrol or idle, but less important than investigate, attack, lurk, snipe, and so forth.
The AI approaches aggressively as long as the target's back is turned. This AI retreats and seeks cover if the target is facing towards it.
The Retreat behavior finds the AIVolume which is furthest from the target, and moves to it. If there are no options left, the AI is considered "cornered" at which time it may attack.
This goal is the primary user of the AI Senses. AIs with this goal will become alert when a sense is triggered, and may move towards the disturbance if the stimulus is strong or lasts a long time.
Currently, this goal reacts to the following senses:
SeeBlood -
sees blood trails
SeeEnemyFlashlight
- sees flashlight use by players
SeeDeadBody - sees CBodyProp
objects
HearEnemyWeaponFire - hears weapon activation
HearEnemyWeaponImpact - hears weapons hitting
things
HearEnemyFootstep - hears footsteps
This goal does almost nothing. It can be used to get an AI to just "stand still." The AI will still go through its idle animations, so he will look like he is just standing there like any other schmoe on the real world.
This goal is valid as long as there are snipe nodes the AI can get to. If the target gets within MinRange of the AI, the snipe goal will invalidate. So put an attack or retreat goal at a priority below snipe so that the AI will do something "smart" when the player gets too close to snipe at, OR set the MinRange very low.
The AI will go to the nearest snipe node and camp out there, waiting for an enemy to show up. If the AI is shot at and there is a different snipe node available, the AI will run off to that node. He'll also change nodes if he can no longer see his target. He will try to choose the node that is closest to his target.
The goal invalidates when the target gets within this range.
If you want this sniper to use a specific AINodeGroup, then you must assign it with this
command. Ex: NG AINodeGroup0
This is a required goal for Cinematic Triggers to control AI's. If you want the AI's to follow the Cinematic Trigger, no matter what, give this goal a very high priority. If you would like the AI to attack or investigate out of a Cinematic Trigger, then set this goal at a lower priority. I don't think this is implemented anymore. (?)
This goal is used to check that AI's can path through all nodes. It should be especially useful in checking out AINodeWallWalk nodes.
The goal has one required parameter and one optional parameter which must be entered either in the parameter field in Dedit or when sending an Add Goal command. The required parameter is a radius. The AI will try to move to all nodes inside that radius. The optional parameter is the keyword "WallWalkOnly". If that parameter is sent, the AI will only check Wall Walking nodes (AINodeWallWalk and nodes generated by WallWalkOnly volumes).
When running, the AI will list all found nodes in random order and try to move to each node in the list. When he has gone through the list he will shuffle them up again and start over. If the system cannot figure out how to get to a node the node will be removed from the list. If the system cannot detects that it is stuck while trying to reach a node, the AI will move on to the next node. The AI may get stuck and not detect it. That is very bad. In that situation, you'll find the AI just hovering somewhere. If it is an AINodeWallWalk, there probably needs to be more nodes guiding the AI to that point. You can use script commands ("trigger ai_name scr (mt node_before_stuck; mt node_stuck") to see how the AI is getting stuck. I don't think this is implemented anymore either. (?)
This goal is used for AIs that try to trigger the Alarm when they detect the player. See AINodeAlarm, above, for more details.
Activates: if the SeeEnemy, HearWeaponFire, or HearWeaponImpact senses reach full stimulation, AND the alarm is currently off for this level, AND there are unlocked AINodeAlarms.
Deactivates: if the Alarm is turned off, OR there are no unlocked AINodeAlarms to move to.
Example
Place an AI on your
level with goals Alarm (1000), Attack (500), Investigate (100).
Place an Alarm object on the level and leave it with the default settings.
Place one or more AINodeAlarm objects on the
level. In the AlarmObject
field, put in the name of your Alarm (e.g. Alarm0). The AlarmMessage
defaults to ON, so leave this alone.
Start your level and walk within the AI's field of view in order to activate
the goal (SeeEnemy sense). He should run to the node closest to his position.
Also try placing two AIs and one node. One of them will enter the Alarm goal and run
to the node. The other will see that the
node is already locked, so he can't enter his Alarm goal. He will start attacking you instead, since
that is the next available goal. Once
the first AI activates the alarm, he will also drop out of his Alarm goal.
If you want this AI to use a specific AINodeGroup,
then you must assign it with this command. This will restrict the Alarm nodes that are available to him. Ex: NG
AINodeGroup0
The AI will cower when an enemy is spotted. The AI looks for the nearest cower node (cover nodes with Cower set to true) away from the enemy and runs to it. The cower nodes can be grouped and the goal can be given that group to prevent an AI from running to nodes on the other side of the level (this is highly suggested). There are attributes in the AI butes file to control the AI's behavior while cowering. Currently, they can run to other nodes after cowering for a while if the enemy is far enough away.
The cower goal will send an "inv (spot that scared me)" command to other friendly AIs. So AIs in a cower goal will alert other AI's to investigate the location that made them start to run. These other AI's need to have an investigate goal and not be in a more important goal (such as snipe) in the meantime.
If you want this AI to use a specific AINodeGroup,
then you must assign it with this command. This will restrict the Cower nodes that are available to him. Ex: NG
AINodeGroup0
AI's can be sent commands via a trigger. Capitalization is not important except for object names.
Gives the AI a new goal. It has two formats:
"AG goal_type"
"AG goal_type priority goal_name (parameters)"
If you use the first format, the game will choose the default priority for that goal.
Patrol is a special case because it requires the
(parameters). Use the link keyword to tell the AI the
starting node. The patrol nodes in the
path must be linked. Example
"AG goal_type (link AINodePatrol0)"
*** In the second format, the priority field is required, but it is currently ignored. It will require some work to make it functional. If you absolutely need to use it, email marks and I'll hook it up.
"SGP goal_name priority"
Changes the goal's priority.
"KG goal_name"
Removes the goal from AI's goal list.
"ACTIVE | 1 ]"
If set to 1 (true), the AI will be solid, visible, and responding. If set to 0 the AI will "go away." They stay in where they are, but cannot be seen, heard, touched, or smelled. Use this to activate an AI which had its properties set to start inactive.
"SCR (script_command1 params; script_command2 params; .)"
Gives the AI a script goal with a very high priority. Note that the script goal will stay active until it is given a script command "end". If the AI is already performing a script created in this way (as opposed to through Add Goal or Dedit properties) it will be aborted and replaced with this new script.
"ISCR (script_command1 params; script_command2 params; .)"
Gives the AI an idle script goal. Otherwise this is the same as "scr" above.
"SCR+ (script_command1 params; script_command2 params; .)"
If the AI has an active script or idlescript goal, these script commands will be added to the end of the script. Otherwise it is ignored
Use this to issue commands to an AI that should only be followed if the AI has not gone into another state (like attacking the player).
"killscripts"
This kills every script goal the AI currently has. If the AI is in a script, that script will be stopped. This can be used to be sure an AI has no scripts.
"TRG character_name"
Has AI target the specified character. Many goals and script commands will use this target. If the character_name is "player" then the the AI will target the closest player (this is important for multi-player situations).
"TLP (# # #)"
"TLP node_name"
Teleports the AI to the vector location or node name.
"rot (# # #)"
"rot target"
"rot player"
"rot object_name"
Rotates the AI so that her body is facing the specified thing. A vector (the first format) specifies a location to face. Player means the closest player.
"say sound_name"
The AI will play and lip sync to the sound file at "Sounds\Dialogue\sound_name.wav". Like play animation, the AI will not wait for the sound file to finish. Use reply ("RPLY") script command to get the AI to wait for the sound to finish.
"la (# # #)"
"la player"
"la target"
"la object_name"
"la off"
The AI's head will follow the specified target. Note that if the animation moves the head
around this will wreak havoc with the poor AI's head.
"sw weapon_name"
"sw none"
Sets the weapon the AI will use (or no weapons if none). Clears out all other weapons the AI had. If the AI does not have a weapon, they will not attack, so be sure they have a retreat goal or an on-damage message to make them do something when they take damage!
"aw weapon_name"
Gives the AI a weapon at lowest priority.
"sl on/off"
Turns shoulder lamp on and off. Note that the beginning of every script will turn off the flashlight, as will most other goals.
"sllock on/off"
Forces shoulder lamp to stay on. When given "sllock on" the AI will turn on its should lamp and leave it on until it receives "sllock off" or "sl off".
"sms investigate", "sms combat", etc.
"sms default"
This can be used to set the movement animation and speeds of an AI. For instance, "sms investigate" will cause the AI to use her investigate animations. Use "sms default" to return him to normal. The style name, ie. "Investigate", is set-up in AnimationButes.txt.
Every goal will reset this to "Default" when it starts and when it finishes. So I suggest only using this inside a script.
"cl on/off"
If the AI is a predator, this turns the cloaking on or off.
"nvrlstrgt on/off"
If this is on, the AI always know where their target is. Set this on when you want to make sure the player will not lose an AI. A neat trick you can do with this: When this is on and the target has an attack goal, you can send the AI a "trg player" command and the AI will start chasing the player from where-ever the heck it is. Since aliens always have this on, you can just send an alien a "trg player" command and they will start chasing and attacking the player.
Note that the automatic deactivation can still kick in. So if you have an AI on the other side of a level, don't expect them to chase down the player until they get inside the player's vis-list.
"lsh # node_name"
"lsh # object_name"
"lsh # here"
Sets the AI's leash to be # units long. The center of the zone is marked by the node or object's position at the time the message is received. If no name, or "here" is used, the AI's current position will be used.
Be sure the AI is within the leash zone when they get the command!
"seethrough 0/1"
Equivalent to setting CanSeeThrough FALSE or TRUE in Dedit. When true, AI will be able to see through things marked "AICanSeeThrough".
"shootthrough 0/1"
Equivalent to setting CanShootThrough FALSE or TRUE in Dedit. When true, AI will try to shoot her target through things marke "AICanShootThrough". AI will not necessarily be able to actually shoot through that object, she will just act as if she can.
"inv (# # #)"
"inv player"
"inv node_name"
"inv object_name"
If the AI has an investigate goal, and no other more important goal is running (such as attack or script), the AI will investigate the named location. So "inv player" would cause the AI to investigate the player's location (the player's location is determined when the AI receives the command). You can also use "inv (345 -232 557)" to investigate a location or "inv node_name" to investigate a node or "inv object_name" for an object.
"ResetSense all"
"ResetSense sense_name", where sense name is the name of one of the sense (like "SeeEnemy" or "HearAllyWeaponFire").
This command will cause the AI to trigger the 1stReaction message when the sense goes off again, even if that message had been sent already. The names of the senses are the same as the reaction names without the "1st" and "Message" or "Target". Ie "1stSeeDeadBodyMessage" is sent for the sense "SeeDeadBody".
Scripting is performed via a script goal. If another goal takes over while a script goal is active the script goal will be removed. The script goal is always valid. If it doesn't have anything to do it will just sit there (playing its idle animations) and wait for a "SCR+" command to be sent to it.
A script is a sequence of script commands separated by a semicolon. Ie (mt console0; wt 5; mt console1; wt 2; end). Yes, the parentheses are needed. Again, capitalization is only important for object names. '#' means a floating point number (ie. 112, 5.6, or 155.0).
If a command is not understood it will be interpreted as a message to self command (for any engineers reading this, it is put into a "msgself" command). This is set-up so that you can use the AI commands in a script just as if they were script commands, ie. "script (mt console_0; wait 5; target player; do something else involving player)".
"end"
When a script goal reaches this command it will terminate itself. Use this to keep a script goal from lingering after all the commands have been executed. In other words, if you don't plan to use "SCR+" to send more commands to the AI, make sure "end" is part of the script.
"mt (# # #)"
"mt node_name"
"mt player"
The first format specifies a location with a vector. The second just uses a node. Use this command in the middle of a path for smooth movement to the next destination. The AI may overshoot the point by 10% of their movement speed (usually ~10 units). Use PreciseMoveTo for exact movement.
"pmt (# # #)"
"pmt node_name"
"pmt player"
This is just like MoveTo, but it is precise. The AI will stop at exactly the point specified (except, of course, for their y axis. They have to stay on the ground!). Only use this at the end of a path. If you use this in the middle of a path the AI will stutter at the point and then move on to the next point.
"wt #"
Waits specified number of seconds.
"msg object_name trigger_message"
Sends a trigger to the named object. Note that if the message is compound (has semi-colons), you must wrap it in parenthesis, ie. "msg steam_0 ( msg Steam_0 on; delay 3 (msg Steam_0 off); delay 2 (msg Steam_0 on); delay 20 (msg Steam_0 on) )".
"pa animation_name"
The AI will play the animation and wait for it to finish. If you want the AI to do other things (like talk or move) while it is playing the animation, see Play Looping Animation or Play Interruptible Animation below.
"pla animation_name"
"pla none"
The AI will loop the named animation until either the script goal is complete, a Play Animation command is given, or "none" is given for the animation name of "pla".
"pia animation_name"
"pia none"
The AI will play the named animation until either the script goal is complete, or another Play Animation command is given, or "none" is given for the animation name of "pia". Once finished, the AI will return to its normal idle animation.
Note: you should use ModelEdit to look up the duration of the animation you are using. The duration is given in milliseconds and can be found by sliding the time slider all the way to the right. If you are going to give more commands after the pia command, add a wt X command (where X is the duration of the animation in seconds) after the pia command. In combination with using iscr to script an action, this will ensure the character plays the entire animation, yet the animation can still be interrupted if the character is attacked or sees an enemy, assuming the attack and/or investigate goals are present.
"pas animation_set"
This works like PlayAnimation ("pa") above. But instead of an animation name, it takes an animation set name. Animation sets are defined in Attributes\AIAnimations.txt. If the play chance fails, this command will be skipped.
Works just like Play Looping Animation ("pla") but takes an animation set rather than an animation name.
Works just like Play Interruptible Animation ("pia") but takes an animation set rather than an animation name.
"rply sound_name"
Works just like "SAY" above, but AI will wait for sound to finish before continuing with the script.
"fc (# # #)"
"fc player"
"fc target"
"fc object_name"
"fc off"
AI will face and continue facing the specified object or location. Player is the nearest player when the script command becomes active. The AI will stop facing when either the script goal is exitted or "fc off" occurs.
"fr (# # #)"
"fr player"
"fr target"
"fr object_name"
"fr off"
Works like "Face". AI will fire weapon at specified object or location. There are no checks for a clear line of sight (although they won't hurt an ally or themselves). The AI just starts firing in the right direction.
"fp path_base_name"
Follows a sequence of nodes named "path_base_nameX", where X is the number of the node. Eg "fp hallA" will go to nodes : "hallA0", "halla1", and "HallA2". The base name is not case sensitive.
"run"
"walk"
AI will start running or walking. So, to get an AI to run along a path you would use "run; fp run_to_exit".
"crouch"
"stand"
AI will crouch or stand-up. So, to get an AI to do a running crouch down a path use "run; crouch; fp run_to_exit". The order of run and crouch didn't matter, they just both needed to be before the followpath command.
Aliens will not obey these commands. Aliens always stand when they are moving to a point or node in a volume and they always crouch when they are moving to a wall walk node.
"jp (# # #)"
"jp node_name"
"jp object_name"
AI will jump to the specified location. This works just like the jump connections with the AINodes. The AI does not check whether the distance is reasonable. The AI does not check to be sure the jump path is clear. If something blocks the AI while jumping, the AI will not make it.
"igd"
If this command appears anywhere in a script, the script will keep running even if the AI takes damage. Note that, unlike every other script command, it is handled as soon as the AI receives the script.
If you put one of each of these objects in your level you can send messages to nodes and volumes by triggering that object. Possible trigger messages:
This will turn nodes (or volumes, if sent to the AIVolumeMgr) on or off. The node_name will be matched against the node's name (case insensitive).
AI's will start most goals walking with the default movement
style (equivalent of "sms Default"). In some, like attack, they will run rather
than walk.
When in a script, you can use the "sms"
command to get the AI's to use a different movement style. They will stay in that movement style until
they receive another "sms" command or when they leave
the script goal. You can also give them
"walk", "run", "crouch", and "stand" commands to get them to start walking,
running, etc. from point to point in the script. When they start another goal they will go
back to whatever is appropriate for that goal.
"crouch" and "stand" won't work for
wall walkers because they automatically stand up when they start moving in a
volume and automatically crouch when they start wall walking.
I would like to explain the movement styles a little
bit. The movement styles are simply a
full set of animations. These are all
set up in the animation attributes. Right now there is the "investigate" movement style, those are the animations the AI uses
when investigating.
These movement styles can be added through the bute system, no code changes. So if you want more than the current movement styles it is mostly a matter of gathering the resources (the animations) and setting up the attributes in AnimationButes.txt.
The AI's believe they can walk from one touching volume to
the next. If one volume is more than the
AI's stair step height from the other, you will see an AI walking into a ledge.
Volumes go where AI's can move. I've seen a volume put between two crates
that were 32 units apart. Don't do that!
The volumes can only touch where the AI can actually travel.
If two volumes touch in a place the AI cannot just walk to, the AI will very
likely spend all his energy trying to get to that point.
I've said it was okay to let volumes go a little outside the
geometry, but I've seen some ridiculous stuff. Do it sparingly and don't let it get more than about 100 units out. Even 100 units is
pushing it.
Here are the rules:
A wall-walk-able node has to be slightly clipping into a face, just as before. Nothing changed on that front.
A wall-walk-able node must be at least half the AI's Y-dims away an edge of the face the node is touching. So for drones and runners, that means 32 units away from the face edges! Read this to yourself 3 more times, it's very important.
You'll
want a node at least every 90 degrees of rotation; if the AI ends up being underneath the
node (like on the bottom of an overhang) or on the other side of a node (like
on the opposite wall in a room), their
chances of reliably finding the node are slim. This rule should be fairly obvious. If you put nodes about where you think they should be (following rule 2,
it is an important rule!) you'll likely get this one right.
You have the drop nodes and jumping to help you out as well. If the geometry is getting dicey enough that you can't follow rule 2, I would suggest you don't try to get an AI wall walking over that area! Note that jumping to a wall walk node is a non-solid "pounce," so they _will_ make it!
Examples from P1 and P3:
Predator Todd moves up to the node todd_dest0, targets Guard Jibber, uncloaks, and ends his script (which automatically drops him back into an attack state):
msg predator_todd (killscripts; lsh 0; scr (run; mt todd_dest0; trg guard_jibber; cl off; end;););
Predator Todd uses an idlescript to chill out. If he is attacked the use of iscr and pia will allow this script to be interrupted:
msg predator_todd (killscripts; iscr (pia Cine_4_8; wt 14.6; pia Cine_4_5; wt 16.4; msg todd_chill trigger; end;););
Drone Tony stops his attack, turns, and runs/wallwalks to wallwalk node wallwalk_A7, before deactivating.
msg drone_tony (kg attack; kg investigate; scr (rot praetorian_jump3; wt 1; run; mt wallwalk_A7; active 0;););
Guard Wayvin activates, moves to his destination node, turns to face another guard's destination node, and triggers the beginning of a conversation between himself and his pal:
msg guard_wayvin (active 1; iscr (run; mt wayvin_dest0; rot swissmenz_dest0; msg grotto_conv_start trigger; end;););
Guard Balzac activates and moves to various destinations, playing animations and pausing. The use of iscr and pia (instead of scr and pa) allows his actions to be interrupted if he sees an enemy or is attacked:
msg guard_balzac (active 1; iscr (wt 2.0; mt balzac_dest0; wt 2.0; sms investigate; mt balzac_dest1; mt balzac_dest2; pia M6I1_1; wt 5.0; mt balzac_dest3; end;););
Guard Jackie turns towards the player, plays an animation, says something, and sends a message to a trigger if he is not killed before reaching that point in the script. After that, he targets the player and ends the script, dropping him into his newly-added attack goal:
msg guard_jackie (killscripts; scr (rot player; pia Touch_Earphone; wt 1; say 29084; wt 3; msg target_seen trigger; wt 1; ag attack; trg player; end;));
Guard Bob stops his patrolling and investigating, and moves towards Repairman Joe. He looks at Joe, reactivates the investigate goal, and begins a conversation. The use of iscr ensures the script can be interrupted if Joe is attacked or sees something:
msg guard_bob (kg patrol; kg investigate; iscr (mt bob_dest0; rot repairman_joe; ag investigate; la repairman_joe; msg hurry_up_conv0 on; end;););
|
