AI

Foreword

Motivational video: http://www.youtube.com/watch?v=8Okn7u_-oVs

An action game like Oni needs artificial intelligence driven characters ("bots") and some sort of interaction between these characters and between the character and world. The goal is to make AI look at least a bit like human being with its behavior resembling real life humans. That means giving the A.I. abilities such as moving in the game world believeably or see, hear and react on events in the game world. Different games deal with these probles in various ways, but in this article, we will take a look at Oni and its A.I.

This page serves two purposes - to give an overview of Oni A.I. and to help modders with A.I. tweaking.

Pathfinding and movement - "I think I will consult a map for a while..."

File:Pathfinding grid.JPG

An example of a pathfinding grid.

An example of the A* algorithm's work: nodes chosen as a path for A.I. are highlighted.

Oni A.I. has two ways how to make A.I. move in a game world - pathfinding-based and ???vector-based??? (needs proper term).

Pathfinding is used when A.I. driven character needs to traverse in level from one place to another. Examples of pathfinding-based A.I. movement are:

• patrol paths - A.I. driven character moves in a pre-designed fashion, see PATR
• alarm running - A.I. character is requested to go to given console and use it, see section Alarm behavior
• pursuit of target - A.I. character loses direct sight of the enemy, see section Pursuit of enemy
• running to weapons in order to pick them up, see LINK TO COMBAT BEHAVIOR

Pathfinding utilizes an A* (A-star) algorithm to design route for A.I. within the game world.

Human players see walls and obstacles placed in a way between current location and goal location, thus they can adapt their behavior thanks to the best computer so far known to a man - human brain. The A.I. on the other side has to be told where it can go and where it cannot (wall, pit, obstacle etc). Since the A* is a chart search algorithm, there is a need to have some sort of chart, conveniently mapping the environment for A.I. purposes. And that is pathfinding grid, which can be seen ingame by activating ai2_showgrids = 1 (see picture on the right).

If A.I. has to travel in the level and pathfinding is used, then a "mark" is set at the final destination and the "chart" mentioned above is consulted to get the shortest available route. After this process, the A.I. is continually fed with "traversal nodes" - temporary marks set in AKVAs A.I. is currently running through. Artificial Intelligence keeps running directly towards these marks, so when A.I. needs to turn around the corner, a number of these nodes are generated in order to make A.I. turn the corner.

Pathfinding grids are tied to AKVAs and are loaded into memory only for the time when they serve some purpose (character is inside the AKVA volume). More detailed info about various types of pathfinding grid tiles and their effects on pathfinding can be found at OBD talk:AKVA/0x24.

There used to be a short modding initiative to alter pathfinding grids manually, but it deceased due to extreme amount of labor required to do so. Currently, OniSplit can import levels and generate pathfinding grids.

Modding hints: if A.I. has to turn sharp corners, pathfinding still picks the shortest route possible. That usually results in A.I. having problems with turning corners at full running/sprinting speed - A.I. stops at corner, turns, runs past the corner, turns again to finish it and continues on its way. That is caused by low Rotation speed assigned to the character in his ONCC file.

In ONCC xml file there is <RotationSpeed> under <AIConstants>. Default is 1, but 1.5 works way better without causing any visible negative influence on the game. Rotation speed 2.0 is recommended to be the maximal because the pathfinding in the game is designed for speed 1.0 and with such a high rotation rate there raises a paradox as new problems in pathfinding may appear instead of issues being erased (mainly A.I. colliding with obstacles).

???Vector??? movement is used when

• A.I. driven character enters close combat state and goes into melee
• A.I. driven character is dodging gunfire, be it firingspreads or projectiles
• A.I. driven character is requested to run away from enemy by special setting in CMBT profile

In this mode A.I. is not given exact destination where to move. Instead it is given a "desire" to go to some direction. This mode still uses pathfinding grid, however in a bit different way than pathfinding does so glitches occur, mainly unexpected collisions and ignored tiles (A.I. runs over the edge and falls down to its death).

Unexpected Collision movement happens when A.I. runs on its own towards some destination and suddenly hits an obstacle. Ideally that should never happen as pathfinding grid should prevent it, but still...Anyway, when collision happens, the game decides what to do according to actually selected way how to move a character:

• Pathfinding - the game makes A.I. do a few steps back, rotate a bit and lets the A.I. continue its journey. There is limit of how many unexpected collisions can A.I. undergo before it gives up its destination as unreachable.
• ???Vector??? - according to the angle between A.I.'s facing and obstacle the game decides either to let the character slide along the obstacle or to stop the character completely until direction of the A.I.'s vector of movement changes.

Congitive possiblities of A.I. characters ... "COME TO YOUR SENSES!"

File:VisionFields.JPG

An example of Blue Striker's central and peripheral vision.

File:SoundSpheres.JPG

Three examples of sound spheres.

When talking about life-like A.I., senses have to be taken into an account. Sight, hearing, taste, smell, touch. Unfortunately Oni emulates only sight and hearing.

Sight is important. Without it the only option for A.I. to recognize the enemy is to be attacked by the enemy first. Unlike majority of action games, Oni A.I. characters have two visions:

• Central - enemy seen by central vision = enemy recognized and attacked.
• Peripheral - enemy seen by peripheral vision = alert risen to low and A.I. goes into pursuit mode with given enemy, see LINK TO PURSUIT

Modding hints - parameters of vision fields are stored in ONCC, under <VisionConstants>. Central vision field distance has to be greater than peripheral vision field distance, otherwise peripheral vision detection will be somehow broken (it will not detect). Since peripheral vision makes A.I. pursue the enemy but not attack it, it can be set quite large in order to surprise lousy stealth players. But be warned - nobody likes cheating A.I. ^_^.

Hearing is crucial in Oni. Majority of A.I. character interaction is done via sound system. Oni recognizes these types of sound (in brackets visualization when ai2_showsounds is set to 1):

• Unimportant (blue) - is ignored to some extent if alert level of A.I. is lull, but after some period of time A.I. will register it.
• Interesting (green) - causes alert rise to low level.
• Danger (yellow) - causes alert rise to medium level.
• Melee (orange) - causes alert rise to medium level but A.I. reacts a bit differently than in case of Danger sound.
• Gunfire (red) - causes alert rise to high level.

For more info about A.I. alert levels, see section Reaction on stimuli. These sound types are used by impact effects ONIE and danger sound type can be set in particle as a "danger radius".

Modding hints: Sound system and ONIE are mighty tools if modder knows how to use them. Even doors can be attached a sound sphere of any one of those listed above, so a modder can create doors which draw attention (sound type interesting) of nearby A.I. characters if these doors are manipulated.

Another example is a workaround for A.I. to get alerted by dead bodies -

Set dead particle in ONCC to be one special custom made - this particle will for given time keep emiting custom impact effect. That custom impact effect will have no sound or effect attached, but will be set to be hearable by A.I. as a gunfire within a large radius (200 units).

Reactions on stimuli a.k.a. "What was that?!"

In real life each human being is unique with its reactions. But even then reaction differ - when calm or when nervous or when suspicious, a man does not always react the same way. And what about Oni?

In Oni, reaction on stimulus is based on type of stimulus (see previous section) and on level of AI alert level. Oni A.I. characters have these alert levels:

• Lull
• Low
• Medium
• High
• Combat

Level of alert can be set via BSL as ai2_setalert ai_name/chr_index desired level of alert. Levels of alert play the role of "behavior modifier". Artificial Intelligence reacts on seen or heard allies/enemies according to its own level of alert. Level of alert can be increased by:

• hearing a sound which causes rise of alert level (for detailed info read previous section)
• special rise of alert level from Lull to Low is by enemy being seen by peripheral vision or by enemy causing too many unimportant sounds
• special rise of alert level to Combat is by being hit by the enemy or by alarm being triggered (see OBD:BINA/OBJC/CONS) or by script functions ai2_tripalarm, ai2_makeaware or ai2_attack (see BSL:Functions).

Alert level also affects movement mode of A.I. driven characters. There are six movement modes - creep, walk, walk_noaim, run, run_noaim, by_alert_level. Those "_noaim" movement modes are forcing A.I. character to not aim with weapon in case the A.I. is armed (so A.I. character walks or runs with the gun in hand but it does not aim with it). Movement mode can be forced via bsl command ai2_setmovementmode. Alert level affects movement mode only if movement mode is set as by_alert_level. In that case:

• Lull and Low alerts use walk_noaim
• Medium, High and Combat use run

If patrol path (PATR) is assigned to a character, it can override movement mode for patrol path purposes and for example force Lull alert character to run with aimed weapon. However, when A.I. is disturbed and starts pursuit of ally/enemy, movement mode is then chosen by coresponding alert level (given the fact the movement mode is set as by_alert_level).

Level of alert can decrease via BSL ai2_setalert or with time , exact location of timers unknown (maybe hardcoded).

Next component of A.I. reaction logic is its awareness of ally/enemy. Oni recognizes between ally (friendlythreat) and enemy (hostilethreat). Oni A.I. characters always know whether the disturbance was caused by ally or enemy. That means if player is playing as standard Konoko, shoots and some Striker gets alerted, the Striker knows which character (from CHAR) shot, which team does the character belong to and according to it the Striker reacts (but more about it later). Oni defines four levels of awareness:

firendlythreat

• Definite - A.I. is 100% sure where ally stands and ignores him. Is achieved by seeing the ally with central vision field or by being hit by his gun by accident or by being told of its presence by BSL commands ai2_makeaware, ai2_tripalarm or ai2_attack.
• Strong - A.I. has strong awareness of ally presence, but cannot pinpoint exact location of the ally character itself. Is caused by all sound types, which are described in previous section. Also if ally is off central vision field and <FriendlyThreatDefiniteTimer> runs out, A.I. decreases level of awareness from definite to strong.
• Weak - A.I. has weak awareness of the character's presence. It is caused either by seeing ally with peripheral vision or by <FriendlyThreatStrongTimer> running out.
• Forgotten - A.I. has ecountered some ally, but over time forgot about its presence. <FriendlyThreatWeakTimer> ran out.

hostilethreat

• Definite - A.I. is 100% sure where enemy stands and will go attack her/him. Is achieved by seeing the enemy with central vision field or by being hit by her/him (or her/his gun) or by being told of its presence by BSL commands ai2_makeaware, ai2_tripalarm or ai2_attack.
• Strong - A.I. has strong awareness of enemy presence, but cannot pinpoint exact location of the enemy character itself. Is caused by all sound types, which are described in previous section. If enemy manages to get is off central vision field and <HostileThreatDefiniteTimer> runs out, A.I. decreases level of awareness from definite to strong. If A.I. is allowed to investigate, corresponding pursuit behavior is excuted (more about this later).
• Weak - A.I. has weak awareness of enemy's presence. It is caused either by seeing enemy with peripheral vision or by <HostileThreatStrongTimer> running out. If A.I. is allowed to investigate, corresponding pursuit behavior is excuted (more about this later)
• Forgotten - A.I. has ecountered some enemy, but over time forgot about its presence. <EnemyThreatWeakTimer> ran out.

When A.I. character is freshly spawned, it does not have any contact with other characters (Tabula Rasa). Through sounds and vision, A.I. learns about presence of other characters and reacts on them according to team affiliation, alert level and awareness. Even when A.I. character "forgets" about ally/enemy, it does not completely abandon their existence. For example startle behavior when A.I. character sees an enemy is played only once vs this particular enemy. Even when A.I. character forgets, it won't play startle animation next time it sees this one enemy, but goes directly attack him.

Friendly warning: awareness "Forgotten" IS NOT equal to ai2_forget command. "Ai2_forget" clears A.I. character's memory back to Tabula Rasa status.

Pursuit of enemy alias "I will find you..."

Everything that was needed was explained in section above so let's take a look at pursuit behavior. Pursuit behavior in Oni emulates the situation when a man knows "somebody is here", but does not see anybody.

Oni deals with this problem by using pursuit behaviors. In Oni there are following types of pursuit behavior:

• None - simply nothing
• Forget - A.I. goes into forgotten awareness with this enemy
• GoTo - A.I. moves to the source of distrubance and executes timer-based 600 frames Look behavior (600 frames = 10 seconds)
• Wait - A.I. simpy stands and waits
• Look - A.I. rotates on spot and looks all around
• Move - unimplemented, probably was meant to be similar to Look, but with character randomly moving around
• Hunt - unimplemented, probably was meant to make A.I. purposefully look around for the enemy
• Glance - A.I. does not rotate whole body, only rotates its head

Plus there are three types of lost behavior (when A.I. has definite contact with enemy but enemy manages to get away)

• ReturnTo Job - A.I. returns to its job
• KeepLooking - A.I. does not return to its job but keeps using the last used pursuit behavior
• FindAlarm - A.I. tries to switch to alarm behavior (see section Alarm behavior), if it does not suceed, A.I. returns to its job.

In Oni, a character which is spawned in the level is a character profile from CHAR file. This CHAR profile contains links to:

• ONCC file - character class, eg. Konoko or Comguy_1
• CMBT file - combat profile for this character
• MELE file - melee profile for this character
• PATR file - OPTIONAL, patrol path
• NEUT file - OPTIONAL, neutral behavior (for example civilians giving player some powerup)

Pursuit behavior is executed only within the Pursuit range, which is a parameter <PursuitDistance> in CMBT profile attached to the A.I. character. If anything suspicious happens outside of this range, A.I. only looks in the direction of disturbance for a short time, then ignores it and returns to job.

Pursuit behavior greatly depends on level of alert. There are four parameters regarding alert levels in CHAR profile:

• Initial - A.I. is spawned with this level of alert
• Minimal - minimal alert level this A.I. can have
• JobStart - Alert level of the A.I. when it starts some job (most typically a patrol)
• Investigate - From this alert level and all greater alert levels A.I. will tend to pursue any suspicious sound it hears or any hostile peripheral contact it makes.

Also in CHAR there are five fields regarding pursuit behavior:

• Lull/Low alert level strong awareness behavior - in xml labeled as <StrongUnseen>
• Lull/Low alert level weak awareness behavior - in xml labeled as <WeakUnseen>
• Medium/High/Combat alert level strong awareness behavior - in xml labeled as <StrongSeen>
• Medium/High/Combat alert level weak awareness behavior - in xml labeled as <WeakSeen>
• Lost - behavior when A.I. had definite contact (confirmed enemy) but lost it, in xml labeled as <Lost>

If inside pursue range A.I. character registers any sound or peripheral vision contact while its alert level is below alert level set in Investigate parameter, then this A.I. will only look in a direction of disturbance for a short time, then ignores it and returns to job. However, if alert level of the A.I. is high enough, A.I. character goes into pursue mode. That means A.I. will get strong awareness of the enemy (only weak in case of peripheral contact), goes to the source of disturbance (center of sound sphere in case of sound or the spot where enemy stood in case of peripheral eye contact) and will perform pursuit mode Look for 10 seconds. After this initial Look mode expires, A.I. starts with pursuit behavior prescribed in its CHAR profile.

Length of each pursuit behavior execution depends on HostileThreat timers (ONCC file) as described in section above.

Modding hints: Pursuit mess and weird glitches

Watch this YouTube video.

Pursuit mode is quite buggy, so when altering this behavior, there are several important things modder has to have on mind.

• Pursuit distance parameter in CMBT is important in deciding whether the character should be more a pursuer or more a guard.
• Within the pursuit distance, peripheral vision pursuit runs its own league. When A.I. character sees enemy with its peripheral vision, this A.I. always goes into weak awareness mode and either just glaces at direction of this enemy (alert level was below investigate level) or moves to the spot and performs weak investigation pursuit behavior (alert level was on investigate level on higher).
• Remember there are TWO sets of pursuit behavior:
  • strong and weak pursuit for lull/low alert levels. In xml these are called <StrongUnseen> and <WeakUnseen>, however those names simply reflect how many changes were made to this part fo the game.
  • strong and weak pursuit for medium/high/combat levels, in xml called <StrongSeen> and <WeakSeen>.
• From all available pursuit behaviors GoTo, Look, Glance, Forget and Wait can be effectively used in CHAR pursuit behavior parameters. Hunt and Move are not finished code-wise.
• Remember that whole pursuit behavior is glitched and parameters from CHAR are more often ignored than actually used. This glitch is somehow connected with sight. When sight of A.I. characters is turned off via ai2_blind=1, whole pursuit mechanics work as they should. However, the moment A.I. character is allowed to see, then when pursuit should be performed it gets:
  • bugged and results in pursuit values from CHAR being ignored if pursuit mode was called while the caracter was idle or moving in a patrol path. Our A.I. character performs basic GoTo + timer-based Look for the whole time of pursuit, for both strong and weak awareness. Looks so-so but definitely is a glitch.
  • bugged and results in one GoTo + timer based Look being called, but timer for Look does not decrement, so A.I. simply stands and stares. This happens when pursuit mode is called while A.I. stand at job location in patrol path. And well... it looks really bad.
  • in roughly 10% the pursuit performs correctly. It is quite random, but looks like A.I. has to be somehow disturbed while going for the source of previous distrubance. And then Oni writes into console "pursuit mode Hunt not yet implemented" ^_^.
• The best way how to deal with pursuit sight issue is to either ignore it (so char get often glitched) or use BSL script to create a small self-looping function where ai2_blind is set to 1 for at least one second (60 frames), then set to 0 again. It can cause funny moments of A.I. completely ignoring enemy right in front of it, but it silently fixes these pursuit problems.

Alarm behavior - "She's everywhere!"

Control	Alarm	Data

In order to make A.I. look more humane, it is a good idea to grant it ability to interact with the world the same way player does. In Oni that means for example to give A.I. option to use consoles.

Watch this YouTube video.

BSL scripting provides a command to make A.I. go and use a console - ai2_doalarm ai_name/index number of console. This way A.I. can be told to use any console. But there is a method to make A.I. character use a console completely on it own.

In order to utilize those mechanics, there is a need for a console which has ALARM CONSOLE flag set (see OBD:BINA/OBJC/CONS). In XML this flag has a string IsAlarm. Such a console then can be used by A.I. characters without scripting.

Next, there are Alarm parameters in CMBT profiles which define A.I. character's alarm behavior:

• Search distance - a perimeter around the character where engine checks for any console with ALARM CONSOLE flag. In xml it is named <SearchDistance>.
• Ignore distance - a perimeter around A.I. character where this A.I. character (which is currently executing alarm behavior) acknowledges enemies. Enemies outside of this perimeter are ignored by the A.I. character. In xml it is named <EnemyIgnoreDistance>.
• Attack distance - a perimeter around A.I. character where this A.I. character (which is currently executing alarm behavior) temporarily stops its run for the console and attacks enemies if they are within this range and A.I. character sees them with central vision field. In xml it is named <EnemyAttackDistance>.
• Damage threshold - in xml named <DamageThreshold>. Time interval for which A.I. character keeps awareness of enemy who attacked it. If this enemy crosses Attack distance perimeter, A.I. temporarily stops its run for alarm and immediately attacks this enemy (does not have to see him with central vision field).
• Fight timer - in xml called <FightTimer>, duh. Numer of frames for which A.I. character should fight with the enemy before it attempts to resume its run for alarm.

Logic for alarm running is set, now how to trip it? There are three ways how to make character run and use a console without BSL. the console must have ALARM CONSOLE flag set and ust lie within Search distance perimeter:

• in CMBT: If no gun behavior set to "Run for Alarm". In xml it is RunForAlarm string inside <NoGunBehavior>. By setting this parameter, A.I. character will attempt to run and use a console when it does not have a loaded weapon or spare clips in inventory (then it reload and continues shooting). If there is no alarm console nearby, A.I. will switch to Melee.
• in CMBT: Behaviors (Long, Medium, Short, MediumRetreat, LongRetreat) can be set to be "Run for Alarm". DO NOT confuse with "Run for alarm If no gun" behavior! This behavior is never used in retail Oni, the reason probably being the fact if there is no useable console within Alarm search distance radius, then A.I. character simply stands and stares even when enemy is visible with central vision field.
• In CHAR: Lost behavior "FindAlarm" - When A.I. character makes definite contact with enemy and then enemy manages to escape, A.I. executes "Lost" behavior (see "Pursuit of enemy" section). This behavior is typically set as ReturnToJob, but FindAlarm works well with no known issues. If alarm console is not found within search distance, A.I. returns to its job.

A couple of notes regarding A.I. character:

• in order to register enemy and attack her/him pre-emptively, A.I. character must have "HostileThreatDefinite" timer set in ONCC file to some value over 60 (Oni runs 60 frames per second).
• "If no gun" behavior "Run for Alarm" can get glitched. "Alarm enemy attack distance" is set to some value, let's say 100. Now when A.I. character runs for alarm and enemy attacks it, then if in this CMBT profile there is not set melee override for range at least 100 (via melee override or by heving "Melee" set in corresponding combat ranges, see section Combat behavior), chances are A.I. will get stuck in a loop trying to reach both enemy and console at the same time.
• Similar issue can happen with combat behavior Run For Alarm as well, but this time problems rise when this combat behavior Run For Alarm is set as Short range behavior.

A couple of notes regarding target console:

• Console must be in "activated" mode. If console is in deactivated or used modes, alarm behavior will not be executed.
• Console must be directly accessible. Oni A.I. cannot use consoles in order to open path to get to the point of interest (target console in this case). Target console must be directly accessible. Still, it can be directly accessible across the whole level ^_^.

As already mentioned, Alarm behavior can be tripped by BSL command ai2_doalarm. In that case alarm behavior is executed but this time console is set by command instead of being looked for via Search distance. Also, by ai2_doalarm A.I. can be made to use any console, not only those with ALARM CONSOLE flag.

Modding hints: ability of A.I. to use consoles is an excellent tool for increasing a challenge.

• Beware of setting Run For Alarm combat behavior as close range one. Such a setup causes glitches.
• On the other side, combat behavior Run For Alarm can be deliberately used to add element of surprise to fights. In CMBT profile, set Run For Alarm as either Medium or MediumRetreat behavoir, then shorten interval between <MediumRange> and <ShortRange> values (for example set "Medium Range" to 60 and "Short Range" to 59). Thanks to this setup, A.I. can attempt to find an alarm console while still being capable of fighting even when no alarm is nearby.
• In BSL a modder can easily distinguish if console was used by player or A.I. thanks to chr_is_player(ai_name) function. All what is required is a BSL function being triggered when console is used. Here is example where console triggers a function called console1_used:

func void console1_used(string ai_name)
{
 if(chr_is_player(ai_name))
 {
  *Some code in case player used the console*
 }
 else
 {
  *Some code in case A.I. used the console*
 }
}

• Other way of using alarm mechanics is to create a feeling of cooperation - player has to achieve something and in order to do so, an A.I. driven sidekick who goes after needed console and uses it is required.

• In extreme case, A.I. character can be even made to though the level on it own, moving from one console to another. That can be used to create chasing levels - A.I. character has to activate a certain number of consoles while player is required to stop this A.I. character from doing so. Thanks to Alarm behavior the task of tripping consoles can be fully completed by A.I., no scripting needed. such a setup is on the one side prone to possible A.I. glitches, but on the other side can add element of randomness and increase replayability.

Combat behavior part 1 : "Hokey religions and ancient weapons..."

File:CombatRanges.PNG

Combat ranges of an A.I. character.

Of course an action game like Oni is not complete without guns blazing and fists flying through the air. But combat in real life is usually very fickle and everything has to be considered. How can Oni A.I. possibly deal with such a complex task?

Oni A.I. character has to have definite awareness of the enemy in order to actively attack him. Alert level of the A.I. character when in combat mode is Combat (duh). Definite awareness can be achieved by these ways:

• Enemy was seen by this A.I. character's central vision field.
• A.I. character is made to attack the enemy by BSL function ai2_attack.
• A.I. character was hurt by the enemy, be it melee or gun damage.

Once combat mode is entered, then as long as HostileThreatDefinite timer for this enemy does not reach zero, A.I. character will always know exact location of this enemy and will attempt to attack it. The moment HostileThreatDefinite timer is depleted, A.I. character loses the privilege of knowing exact location, awareness decerases from definite to strong and A.I. character either switches from combat mode with this enemy to pursuit mode with this enemy (see section Pursuit of enemy) or, in case of other enemy being present in central vision field, picks this new enemy as a target to attack and keeps old enemy in strong (and later weak and later forgotten) awareness.

Since generally method of combat depends on distance between participants, some sort of spacing is needed. Oni uses system of three ranges around A.I., called combat ranges. See picture on right. Perimeters of these ranges can be set in CMBT profile.

These ranges work as "triggers" to make the A.I. character execute various behaviors, based on enemy's position. Moreover, Oni can distinguish between states when enemy entered specified range or exited specified range. So all range possibilities in Oni which can be assigned some combat behavior are:

• Short - enemy is closest to the A.I. character
• Medium - enemy is approaching the A.I. character and crossed from Long Range into Medium Range.
• Long - enemy is approaching the A.I. character and starts from the Long Range.
• Medium Retreat - enemy is retreating from Short Range into Medium Range.
• Long Retreat - enemy is retreating from Medium Range into Long Range.

Well of course nothing is perfect and in Oni there is a bit of an issue with proper switching between combat ranges, so Long and Medium ranges are used only once at the beginning of enemy approach. Only Short, Medium Retreat and Long Retreat ranges are used on regular basis in a combat. Even when enemy runs into Long Retreat and goes back to to medium range, engine does not switch A.I. behavior range to Medium, but (contrary to its name) to Medium Retreat.

OK, we have positioning, now for actual behaviors A.I. character can be set to execute within these ranges. There are fourteen possible combat behaviors (in brackets are xml strings):

• None (None) - simply nothing
• Stare (Stare) - A.I. character stands and stares, does not even rotate to face enemy
• Hold and fire (HoldAndFire) - A.I. character stands still and fires a weapon. If this character does not have a weapon, then she/he switches to melee.
• Firing charge (FiringCharge) - A.I. character runs towards the enemy and fires a weapon. If this character does not have a weapon, then she/he switches to melee.
• Melee (Melee) - A.I. character always uses melee, even when she/he holds a loaded weapon.
• Barabbas shoot (BarabasShoot) - A.I. character stands still and fires a weapon with hardcoded three seconds pause between shots. If this character does not have a weapon, then he switches to melee. If this character meets certain conditions, she/he can start health regeneration. More detailed info about regeneration mechanics can be read HERE.
• Barabbas advance (BarabasAdvance) - A.I. character runs towards the enemy and fires a weapon with secondary fire mode (as if player pressed right button). If this character does not have a weapon, then she/he switches to melee. If this character meets certain conditions, she/he can start health regeneration. More detailed info about regeneration mechanics can be read HERE.
• Barabbas melee (BarabasMelee) - A.I. character uses melee, even with loaded weapon in hand. If this character meets certain conditions, she/he can start health regeneration. More detailed info about regeneration mechanics can be read HERE.
• Superninja fireball (SuperNinjaFireball) - Mukade's long range behavior. With this behavior A.I. cannot shoot weapons and cannot use melee, simply runs towards the enemy. However, if weapon is held, character can use melee (probably something from weapon melee override). A.I. character is occasionally teleported into the back of the enemy (AnimType 222 - Teleport In) if distance to enemy is greater than 100. It seems like it should work regularly once distance to enemy exceeds 100, but in reality something screws this teleport mechanics ^_^. Anyway, to add more to this behavior A.I. executes two special TRAM animations:
  • AnimType 224 - Ninja Fireball, after the use there is 20 seconds pause before then this TRAM is used again.
  • AnimType 225 - Ninja Invisible, grants 10 second cloak, after the use there is 20 seconds pause before this TRAM is used again.

IMPORTANT There is an annoying problem with this behavior. When it is called, it checks character's position height-wise from the origin of the game world (coordinates 0,0,0) and if the height is below 550, this character is automatically moved to height 550 (which in almost all cases means death by falling).

• Superninja advance (SuperNinjaAdvance) - Mukade's medium range behavior. With this behavior A.I. cannot shoot weapons and cannot use melee, simply runs towards the enemy. However, if weapon is held, character can use melee (probably something from weapon melee override). This behavior gives ability to use AnimType 225 - Ninja Invisible which grants 10 seconds invisibility. In order to be able to use this ability, A.I. has to be at least 50 (or 40?) units far from its enemy. Cooldown for this special technique is 20 seconds. Again, annoying over 550 height check is present.
• Superninja melee (SuperNinjaMelee) - Mukade's short range behavior. With this behavior A.I. cannot shoot weapons but can use melee. This behavior gives ability to use AnimType 225 - Ninja Invisible which grants 10 seconds invisibility. In order to be able to use this ability, A.I. has to be at least 50 (or 40?) units far from its enemy. Cooldown for this special technique is 20 seconds. This behavior also grants ability to teleport away from enemy to certain distance (around 100 units) if any one of these conditions is met:
  • About 35 points of damage dealt to this character in a short time (exact amount of damage and exact timing not known).
  • This character get thrown by any throw.

Again, annoying over 550 height check is present.

• Run for alarm (RunForAlarm) - see section Alarm behavior.
• Mutant Muro melee (MutantMuroMelee) - A.I. character is only allowed to melee, will not fire weapons. This behavior casts chenille (overpower effect) on the user. Of course in order to see visible effect character has to have set <HasDaodanPowers> to 1 in ONCC. This chenille mode does not grant damage overpower effect, melee attacks deal their usual damage. If ONCC has set both <HasDaodanPowers> and <HasSuperShield> to 1, the chenille mode called by this behavior grants super shield.

Chenille mode lasts forever if it is not terminated either via BSL or by A.I. character performing a TRAM which has a DisableShield flag. After 10 seconds interval, chenille is turned back on. Another specialty of this behavior is automatic backwards evasion move when about 35 points of damage or a throw are applied on the A.I. character. Chenille mode is turned off if this A.I. character switches to some other combat behavior because the enemy moved to some other combat range.

• Mutant Muro thunderbolt (MuroThunderbolt) - Upon initial contact A.I. chracter turns on chenille mode and runs towards enemy. If chenille mode is turned off, then until definite awareness of the enemy is lost this behavior will not cast chenille mode again. This behavior also allows the A.I. character to use special long range attack - chracter turns off chenille, goes into AnimState 69 (Thunderbolt) and loops special TRAM animation of AnimState 69 (Thunderbolt) and AnimType 231 (Muro_Thunderbolt). That lasts for 10 seconds. Then A.I. makes 5 seconds pause during which it runs towards enemy. If after those 5 seconds A.I. character is still executing Mutant Muro thunderbolt behavior, A.I. character starts again looping the TRAM animation which has AnimType 231 and AnimState 69.

This behavior's special (looping TRAM animation) lasts even when enemy enters some other combat range with the exception of Short range. If enemy enters Short range while the looped animation is running, the loop is forced to stop and A.I. character starts using Short range behavior.

Modding hints: Combat behaviors can have severe impact on A.I. performance in a fight but can as well hinder the A.I.

• Remember: due to a glitch, crucial behaviors for combat are Short, MediumRetreat and LongRetreat. Long And Medium are used only at the beginning of an ecounter.
• In general, use common sense. There is little use in setting Firing Charge as Short range behavior.
• Barabbas Shoot and Barabbas Melee behaviors have access to heal ability which can be a great asset for introducing mutants or stronger enemy units. However, remember that Barabbas Shoot limits rate of fire to one shot per three seconds.
• Barabbas Advance is the only behavior which allows A.I. to fire a weapon with secondary fire mode. However the behavior is quite glitched (A.I. character often looks away and fires stray shots). Still, with proper gun and proper setup it can be useable for boss fights.
• Superninja's behaviors sound excellent for cunning enemy units, however annoying check for character's minimal allowed height from world origin and subsequent forced repositions severely impact these behaviors' usefulness. Despite the height limit, with deliberately designed level which is uplifted enough on purpose, the behavior will not cause random A.I. character repositioning. Then it can be used to its fullest.

One other important thing about these behaviors - if A.I. character does not have required TRAMs in her/his TRAC, the A.I. character can get stuck if she/he uses these behaviors.

• If there is no console with ALARM CONOSLE flag within Alarm sarch distance, then behavior "Run For Alarm" will make A.I. enemy just stand and stare. Set this behavior with caution and consider using a workaround where medium and short combat ranges have very close diameters with Run For Alarm being MediumRetreat behavior, so Run For Alarm behavior is executed only for a brief amount of time as A.I. practically immediately switches to LongRetreat. However even one frame is enough because if alarm is found, A.I. character is requested to perform alarm run which can override combat (see section Alarm behavior for more info).
• MutantMuro melee can be used to create tricky foes which have to be eliminated from distance because if player comes up close, these enemies will turn on their (super)shield and won't put it away (no TRAM with DisableShield flag). That means player has to put some distance between him and these A.I. characters in order to make them disable the shield.
• MutantMuro thunderbolt should NEVER be assigned to Short range behavior as that will negatively affect its special attack. Set it as LongRetreat or MediumRetreat. This kind of behavior (with proper TRAMs) can be used to create foes who will perform special long range attack if player tries to keep a distance. This ranged attack does not have to be the same as Muro's tractor thunderbolt. For quick example, A.I. character can be made to fire a sort of aggressive plasma beam.

Combat behavior part 2 : "Guns or not, my fists are hot."

Combat ranges and various A.I. combat behavior was discussed in previous section. Even with combat ranges, there are still other parts of combat to be taken care of - picking up weapons from the ground, melee overrides of weapons, behavior if character is unarmed and of course, firing weapons or using hand to hand combat. Files inspected in this section will be CMBT profiles and ONCC files.

"Melee override" (CMBT profile) - similar to BSL command chr_dontaim, this behavior bids the A.I. character to use hand to hand animation varient (see TRAM) and to switch from whatsoever other behavior to melee combat. This field was probably added to deal with conflicts when multiple A.I. behaviors are applied on character. Possible values are (xml strings in brackets):

• None (None) - no override is used.
• If Punched (IfPunched) - melee override applied when A.I. character is melee attacked by its enemy. Does not work when the character is invincible (cheat).
• Cancelled - unfinished stuff, does nothing. Remains only the question what it was meant to be...
• Short (ShortRange) - Melee override is applied when enemy is within Short range.
• Medium (MediumRange) - Melee override is applied when enemy is within Medium or Short range.
• Always melee (AlwaysMelee) - Melee override is applied withing all combat ranges

This override can affect:

• Alarm running - It is even required if alarm run is called via "If no gun" alarm run behavior, otherwise glitches will appear.
• Retreating behavior - When "If no gun" is set as "Retreat", unarmed A.I. character will try to run away from its enemy. However, if enemy meets Melee override parameter (for example get into Short range while Melee overrride is set to ShortRange), then this A.I. stops running away and starts attacking the enemy.
• Weapon firing - If distance between A.I. character and its enemy is smaller than minimal shooting distance, A.I. tries to run away from its enemy (still facing the enemy) till distance between characters is greater than minimal shooting distance. However, this backpedal behavior can be overriden by "Melee override" if all conditions are met - A.I. character then starts using melee (even with loaded weapon in hand) for at least 10 seconds (hardcoded timer) After ten seconds A.I. tries to restore its previous behavior. If enemy is still too close, Melee override is immediately applied again.
• Weapon pickup - if A.I. is trying to pick up a weapon and enemy crosses the range specified in MeleeOverride, then weapon pickup behavior is overridden by melee.
• Maybe some other aspects of A.I. behavior?

"If no gun" behavior (CMBT profile) - this parameter tells A.I. character what kind of action A.I. should do if it is unarmed or has empty weapon and no spare clips. Possibilites are (xml strings in brackets):

• Melee (Melee) - A.I. character attacks enemy with hand to hand combat
• Retreat (Retreat) - A.I. character runs away from its enemy (a bit glitchy, but works)
• Run For Alarm (RunForAlarm) - see section Alarm behavior. Remainder: this alarm calling behavior requires Melee override set as ShortRange, MediumRange or AlwaysMelee, otherwise alarm behavior gets glitched and A.I. character gets stuck. If no alarm console is found within Alarm search distance, A.I. character resorts to melee.

File:GoForGun.JPG

A.I. character moving to a weapon.

Weapon pickup behavior (ONCC file) - when in combat mode, unarmed A.I. character can be told to move to a loaded weapon and pick it up or to switch held empty gun for a loaded gun which is lying on the floor. Overall, A.I. characters only register pickable weapons which are lying around them up to a distance of 60 units (hardcoded). Weapons which are lying further than 60 units from the A.I. character are ignored. In ONCC file these parameters can be set to alter gun pickup behavior (xml tags in brackets ):

• Chance for pickup (GoForGunChance) - percentual chance of A.I. being told to go and pick up a weapon. It seems that the weapon closest to the A.I. character is always chosen to be picked up.
• Running pickup (RunPickupChance) - percentual chance of A.I. picking the weapon by performing an evasion move (melee dodge move).

Getting up after being knocked down (ONCC file) - if A.I. character is knocked to the ground, it stays on the ground for a while (simulation of concussion) then gets up. In ONCC file there are two parameters regarding getups (xml tags in brackets):

• Knockdown minimal number of frames (DazedMinFrames) - minimal number of frames for which A.I. character stays on the ground.
• Knockdown maximal number of frames (DazedmaxFrames) - maximal number of frames for which A.I. character stays on the ground.

If knockdowned A.I. character gets hit by melee, it gets up immediately after the hit. Being hit by weapons does not make A.I. character instantly get up. Standard getups are simple ones (as if knockdowned player hit some direction key). If A.I. character is in melee combat mode, its MELE profile has getup attacks listed and enemy is within the required range, chance is this A.I. character will use getup attacks or instead of simple getups.

Making sure enemy is dead (ONCC file) - yes, even this is a part of Oni combat Artificial Intelligence.

When enemy is defeated in hand to hand fighting, A.I. character stands for a while and "checks" if enemy is dead. During this interval A.I. character can utter a short victory speech if corresponding sound slot in ONCC is filled and percentual chance roll is successful. Also during "check body" time interval A.I. character can perform a taunt animation if percentual roll is successful. Here are listed all related fields from ONCC file (xml tags in brackets):

• Investigate body (InvestigateBodyDelay) - time interval for which A.I. character stands next to its defeated enemy and stares at him.
• Dead taunt chance (DeadTauntChance) - percentual chance of performing taunt animation.
• Check body sound probability (CheckBodyProbability) - Percentual chance of playing victory speech.
• Check body sound (CheckBodySound) - link to Oni Ambient sound file (OBD:OSBD/OSAm).

If the enemy is defeated by weapon, then A.I. character keeps shooting this dead enemy for some extra time to "make sure" the enemy is dead, then comes close to investigate the body. No taunts, no win phrases. Parameters of this behavior are:

• Dead make sure (DeadMakeSureDelay) - time interval for which A.I. character keeps shooting the dead enemy
• Investigate body (InvestigateBodyDelay) - it is the same as the one listed above.

Modding hints - behaviors enlisted in this section can be combined to achieve quite impressive results.

• Unfortuantely, Oni does not provide (code-wise) any A.I. routines to deal with dynamic holstering and unholstering of possessed weapons. Thus, melee overrides are the only way how make armed A.I. character somehow defend itself when enemy gets too close.

Nevertheless, BSL provides function to make character holster or unholster a weapon - chr_forceholster. In order to make a character holster the held weapon, this character has to be using pistol or rifle animation variant (see TRAM). Since A.I. characters can use walk_noaim and run_noaim movmement modes (which disable weapon variant i.e. aiming with weapon), the weapon variant should be explicitly coerced via BSL function chr_dontaim. Unholster is easier, simply character has to be be executign some overlay-comaptible animation at the moment when chr_forceholster is executed. That means standing/running/crouching/walking/jumping is OK and function will succeed, but attack animations or animations of getting hit are not OK and function will fail.

• IMPORTANT NOTE: The A.I. character must be "active" all the time in order to perform BSL animation checks (chr_wait_animation/animtype/animstate checks). Remember that Oni was made back in years 2000/2001, so various tricks were used to save memory and enhance performance. One of these feints is making invisible characters (behind wall, behind closed doors etc) go into INACTIVE mode, which means they are only stored in a RAM memory as a structure, but no physics, no checks for collisions and no drawing functions are applied on them in order to save system resources (BTW yes, that means inactive characters can walk in air and pass through walls). On the contrary when character is ACTIVE, it is fully operational, physics working, collisions being checked and character being ready in graphics memory to be drawn anytime. To make sure character stays active means either applying individually "chr_lock_active ai_name", or (since now is year 2011 ^_^) simply applying "chr_all_active=1" to make all characters be ready to be drawn anytime.

Here is a simple example of a BSL scripted holster behavior. Character is given a gun, then weapon is holstered. When this A.I. character notices enemy and plays startle animation, then unholster is called. THIS YouTube video shows the script in action.

 #Setup of A.I. - gets spawned, forced to be always active, weapon gets holstered.
 ai2_spawn A_t48
 chr_giveweapon A_t48 w1_tap
 chr_lock_active A_t48
 sleep 1
 chr_dontaim A_t48 0
 chr_forceholster A_t48 1
 sleep 1
 #Surprise behavior - unholster weapon when A.I. character is startled
 chr_wait_animtype (A_t48, Startle_Forward, Startle_Back, Startle_Left, Startle_Right)
 chr_forceholster A_t48 0
 #Aftermath - A.I. is usually walking only if it is not in combat mode, so let's use it as a trigger that weapon can be holstered.
 chr_wait_animtype (A_t48, Walk, Walk_Backwards)
 chr_dontaim A_t48 0
 chr_forceholster A_t48 1

• Melee override can be used together with "Go For Gun" behavior and properly sized Short combat range to create A.I. characters who jump the gun each time they have a chance yet they are not allowing enemy to land free hits in the process (If enemy gets too close, Short range melee override kicks in).

• "If No Gun" behavior "Retreat" works in a rather simple manner - if unarmed, A.I. character is given a desire to run as far away from the enemy as possible. This behavior can look a bit awkward, but is useful for making more life-like civilians. Combined with Melee override at "short range" or "if punched" and a bit of BSL scripting to deliberately switch between "combatant" and "non-combatant", a modder can achieve impressive yet lightweight (on game engine) results. See this YouTube video.

• Setting short getup times is a good way to make A.I. driven character formidable opponent in hand to hand combat. However, too short getup times can introduce problems. It is a good idea to experiment with getup parameters till the character feels "natural".

• Don't overextend "Check body" and "Dead make sure" timers. It looks silly and on top of that it makes A.I. characters easy targets of a surprise rear throw.

Combat behavior part 3: "They see me shootin', they hatin'..."

Back in 2001 Oni was highly praised for its mixture of shooting and hand to hand combat. Now what could A.I. designers of Oni possibly do to make A.I. characters aim, pull a trigger or to make them avoid being hit by enemy? In this section, ONWC, together with ONCC and PAR3 will tell the story.

First let's look into ONCC file. In XML file, under <AIConstants>, there's a tag named <Flags>. In binary file it is a bitset, so more than one flag can be written into it. XML strings for flags are:

• noStartleAnim - Disables startle animation when A.I. sees the enemy for the first time.
• EnableMeleeDodge - Enables firingspread/projectile dodging when A.I. is in pathfinding mode or combat melee mode
• RunAwayDodge - Enables firingspread/projectile dodging even when A.I. itself is shooting a gun. A.I. character stops shooting and tries to move away from the danger area.
• ShootDodge - Enables firingspread/projectile dodging even when A.I. itself is shooting a gun. A.I. character keeps shooting its enemy while at the same time attempts to move away from the danger area.
• NotUsed - Some ONCC character have this bit set, however it looks like it does nothing.

File:Firingspread.PNG

Example of a firingspread.

File:Projectile.PNG

Example of a projectile with A.I. dodge radius (blue sphere).

Gunfire dodging mechanics. Gunfire dodging mechanics is a quite interesting part of Oni A.I. system. Interesting because the retail version features little to no such a behavior displayed which is sad because it gives a feeling of challenge to a gunplay. In order to make A.I. character perform dodge mechanics, this A.I. must be in combat mode with some enemy. Without combat mode and some enemy, A.I. character won't dodge. Next, A.I. characters perform dodge when the character intersects with:

• Firingspread - can be seen by ai2_showfiringspreads=1. Firing spread is an invisible prism (dimensions set in ONWC) which can be created when a weapon is fired. Not every gun has a firingspread as for some guns firingspread is useless (SCRAM cannon, SuperBall gun). If A.I. character can dodge gunfire and intersects with a firingspread, this A.I. character starts gunfire dodging mechanics.
• Projectile - epic win of Oni modders, can be seen with ai2_showprojectiles=1. In retail version of Oni, projectile dodging is defunct due to a couple of bugs in a projectile dodging code. Since the engine hackers/modders fixed this issue, A.I. characters can execute gunfire dodge mechanics versus PAR3 particle, if these A.I.s are in combat mode with some enemy and the particle has set <AIDodgeRadius> to a positive non-zero value.

A.I. parameters regarding gunfire dodging are set in ONCC (xml tags in brackets):

• Dodge reaction delay (DodgeReactFrames) - a delay in number of frames. This delay makes A.I character wait a bit inside danger zone before this A.I. character starts its reaction on firingspred/projectile.
• Dodge timescale (DodgeTimeScale) - how long should the A.I. character's gunfire dodge reaction last.
• Dodge weight (DodgeWeightScale) - how strong is the desire (???length of vector???) of this A.I. character to dodge a gunfire. Dodge can add together with other "vector" movements and a sum of all vectors is the direction in which A.I. character will try to move.

Parameters of firingspread in ONWC are (xml tags in brakets):

• Firingspread length (FireSpreadLength)
• Firingspread width (FireSpreadWidth)
• Firingspread skew (FireSpreadSkew)

Parameter of projectile dodging in particle system PAR3 is A.I. dodge radius (AIDodgeRadius).

A.I. character's prowess with guns. Still in ONCC, there are data how "skillful" this A.I. character should be with each weapon in the game. Weapons are indexed (starting from zero) as follows:

• w0_sec (0) - Only Bungie West emplyees know what this weapon was supposed to be.
• w1_tap (1) - TCTF automatic pistol
• w2_sap (2) - Syndicate submachinegun
• w3_phr (3) - plasma rifle
• w4_psm (4) - phase stream projector
• w5_sbg (5) - grenade launcher alias SuperBall Gun
• w6_vdg (6) - stun gun (Van De Graaf gun)
• w7_scc (7) - scram cannon (swarm of small homing rockets)
• w8_mbo (8) - Freddie Mercury bow
• w9_scr (9) - Screaming cannon
• w10_sni (10) - Mukade's Devil star (annoying red ball) as a holdable weapon; probably a relic from game development
• w10_ba1 (11) - Barabus's gun
• w11_ba2 (12) - Barabus's gun; this one cannot be shot and is probably just a development relic.

For each one of these weapons, there are in ONCC defined these parameters (xml tag in brackets):

• Recoil compensation (RecoilCompensation) - How much the A.I. cahracter compensates the recoil of the weapon. Setting this to 0.0 mean no compensation, setting this to 1.0 means full compensation.
• Best aiming angle (BestAimingAngle) - In radians, but question is whether it really affects aiming.
• Shoot group error (ShotGroupError) - Random deviation of A.I.'s aim within the target spot. Incorporated to simulate human inaccuracy. Can be set more than 1.0.
• Shoot droup decay (ShotGroupDecay) - Random deviation of the target spot. Target spot is always loosely based on enemy's position. Can be set more than 1.0.
• Shooting inaccuracy multiplier (ShootingInaccuracyMultiplier) - How much can A.I. stray with its aim from the target. Not clear how much it really affects aiming.
• Minimal shooting delay (MinShotDelay) - Minimal pause between reload and the beginning of a gunfire for this A.I. character.
• Maximal hooting delay (MaxShotDelay)- Minimal pause between reload and the beginning of a gunfire for this A.I. character.

Targeting and prediction of enemy's movement. Apart from majority of other games, Oni A.I. does not "cheat" by being 100% accurate and then having some kind of additive error (even tough additive error is present in Oni, see above). It is a bit inverse - there's a bit of a problem making A.I. being a reasonably precise marksman ^_^. A.I. character is given input parameters such as distance between characters, present velocity of its enemy (vector) and velocity of held gun's projectile (number, not a vector). From this data, A.I. logic computes a prediction of enemy's location and ideal aiming direction in order to hit the enemy.

ONCC parameters for targeting and prediction (xml tags in brackets):

• Predict amount (PredictAmount)- Some sort of multiplier for prediction mechanics.
• Predict position delay (PredictPositionDelay) - In frames, delay before prediction is applied, so A.I. characters always uses a bit outdated prediction result.
• Predict delay frames (PredictDelayFrames) - In frames, delay before prediction is computed. Must be set at least to 1.0.
• Predict velocity frames (PredictVelocityFrames) - Number of frames interval but meaning not 100% sure. Maybe enemy's velocity data are obtained and used for prediction algorithm during the interval? Must be set at least to 2.0.
• Predict trend frames (PredictTrendFrames) - Number of frames interval but meaning not 100% sure. Maybe a trend (sort of extrapolation of enemy's movement) is computed with data from this interval? Must be set at least to 2.0.

ONWC parameters for targeting and prediction (xml tags in brackets):

• Prediction speed (PredictionSpeed) - More precisely "projectile prediction speed". This value is taken by prediction algorithm as a speed of a projectile fired with the corresponding fire mode of the ONWC weapon. Thus when actual PAR3 projectile's speed is changed, prediction behavior produces misleading values (A.I. is unable to hit moving targets).
• Maximal inaccuracy angle (MaxInaccuracyAngle) - Maximal allowed deviation of aim from the enemy's character pelvis in order to keep firing the weapon. If exceeded, A.I. ceases fire and corrects aiming, the resumes fire. Pelvis is taken as a root point of the character, so without any extra chages done to targeting origin and targeting vector (see ONWC) A.I. characters always target pelvis of the enemy.
• Aim radius (AimRadius) - no idea what it does.
• Ballistic projectile speed (ProjectileSpeed) - special prediction can be used if weapon is meant to fire relatively slow but gravity affected projectiles (grenades). A.I. then adjusts aiming in order to hit enemy with the projectile according to the ideal (parabolic) ballistic curve. This is a horizontal speed component.
• Ballistic projectile gravity (ProjectileGravity) - vertical gravity attraction for the projectile.

• Targeting direction (Direction) - Vector with three components (x, y, z) which gives orientation of a firingspread. When set to wrong values, firingspread will not cover area where the weapon shoots, but will be pointing in some other direction ( can even point backwards ^_^). Friendly advice: do not alter unless needed.

• Targeting origin (Origin) - Vector with three components (x, y, z) which tells A.I. where to fire according to enemy's pelvis position. When armed A.I. is in combat mode with the enemy and shoots him, the A.I. searches for pelvis (see TRIA) as the pelvis is the only bone recognized by A.I. system. For A.I., pelvis is a representation of a whole character. Now when A.I. fires at its enemy, the A.I. aims for pelvis. The vector described in this parameter tells A.I. where and how much to deviate from enemy's pelvis position.

So when the vector is set as (0, 0, -2), A.I. will aim and fire at enemy's pelvis position + two units above. That means A.I. will fire ABOVE the pelvis position. Here is described effect of setting "x,y,z" from SHOOTER's point of view. First to positive, then to neative value:

• x - deviate forward/backward (does not have much of an effect)
• y - deviate right/left
• z - deviate down/up (headshots, anyone?)

Miscellaneous ONWC A.I. setup - there are a few more parameters in ONWC which affect A.I. behavior with the weapon. They are (xml tags in brackets):

• Minimal shooting distance (MinShootingDistance) - defines how close can enemy be to the armed shooting A.I. character. If enemy comes closer than this distance, A.I. stops shooting and tends to move back a bit (vector type of movement, see HERE) until the distance is again equal or greater than Minimal shooting distance. Then A.I. opens fire again. To witness the effect, see some A.I. operating an SBG when its enemy is close to it.

IMPORTANT - for some unknown reason, value from this field is divided by 2. So when 100 is set, ingame A.I. starts backing when its enemy is 50 units close to it.

• Maximal shooting distance (MaxShootingDistance) - contrary to the parameter described above, this limits how far can enemy be till the A.I. stops shooting and tends to come closer. See some A.I. character shooting with w2_sap at distant enemy.
• Fight timer (FightTimer) - a bit similar to timer-based BSL command chr_dontaim. Defines in frames for how long should A.I. switch from a weapon varient (shooting) to a melee varient (hand to hand combat) if this firing mode was used (don't forget, weapon can has two firing modes) and certain conditions were met. See below for KnockdownSwitcher and StunSwitcher flags explanations.

• basic parameters of a weapon (pistol or rifle type, type of ammunition etc.) can be set as a various flags in ONWC flags field (<Flags> in xml). These three flags from them affect A.I. behavior (xml tags in brackets):
  • NoHolster - apart from holster disabled, this flag also makes A.I. character ignore this weapon on the ground. One exception is w10_ba1 when A.I. character has set Superammo flag (InfiniteAmmo in xml) in its CHAR profile, then this A.I. character can pick up WMC cannon. If A.I. character is given the weapon it will fire it, but if the weapon is lying on the ground and A.I. character does not have superammo flag, this A.I. character will never pick it up.
  • Stun switcher (StunSwitcher) - if the enemy is within armed A.I. character's shooting distance and was knockdowned, stunned or blownupped, the A.I. character switches to a melee for a time specified in the weapon's Fight timer (see above). The flag was designed specially for w6_vdg weapon.
  • Knockdown switcher (KnockdownSwitcher) - Similar to Stun switcher, but only knockdown or blownup makes A.I. switch to melee. Tailored for w4_psm, probably to avoid A.I. abuse of an unfair advantage the w4_psm weapon grants (enemy cannot get up as long as she/he is shot).

Modding hints: Phew, what a long section. Described material has plenty of modding possiblities. Still, modders should be aware of a few things:

• Don't set too strong dodge vector (DodgeWeightScale) and don't overdo it with dodge timer (DodgeTimeScale, the smallest possible value is 0.4; lower is not registered). Delay before gunfire dodging (DodgeReactFrames) should be minimal, otherwise it can happen A.I. won't start dodging till shooter's weapon is empty.

As a side note, there is a glitch in gunfire dodging. It is not a coding bug, but simple limitation of a "vector" type of movement. When A.I. starts gunfire dodge, it tries to get away from the source of danger (be it firingspread or projectile). And because vector movement works as a "desire" to go to some direction, it can happen A.I. will express a "desire" to go into wall. In such a case, character stops until the desire to move into a wall stops (in other words, until enemy stops shooting the A.I. character). When A.I. character is unarmed, she/he will try to switch between pathfinding movement (to go to enemy and attack him with melee) and vector projectile dodge movement, so it kind of looks like the A.I. still tries to dodge the gunfire. If weight of a gunfire dodge is set to be smaller than standard vector movement type weight, then A.I. even does not have to get stuck as it will run in zig-zag pattern towards the armed enemy.

In case A.I. is armed with a loaded weapon, there is no point in A.I. running towards enemy. That means if the A.I. character starts dodging and meets a wall, this A.I. character gets "stuck" until enemy's gunfire stops. In case this character has set "ShootDodge" in ONCC, it will at least fire back at the enemy shooter. But in case the character has set "RunAwayDodge", then it simply stands near the wall and stares and waits till enemy's gunfire ceases.

From the text above it can be seen that gunfire dodge parameters should be set to make A.I. dodge but to not make dodge vector outweight the vector for moving towards the enemy.

• A.I.'s skills with weapons (in ONCC) can be used greatly to create sharpshooters or rookies who cannot hold a gun properly. For example by setting "ShootGroupError = 10.0" for w1_tap, we create a total amateur who's hand shakes all over the place when he fires Campbell equalizer.

• Unless really needed, do NOT alter ONCC prediction parameters. Bungie set them quite reasonably and if they are messed, A.I. character loses the ability of prediction.

• In ONWC, Prediction speed is used for a calculation of A.I.'s aim. The value should be exactly the same as the value of this weapon's projectile. Projectile's velocity is usually set in a emitter of a projectile particle (PAR3). That means Prediction speed and actual speed of a particle used as weapon's projectile may differ, the most significant case being w3_phr (plasma balls accelerate rapidly).

If Prediction speed is set lower than the speed of a projectile is, A.I. will tend to shoot too much in front of the moving enemy since it will assume projectile is slower than it really is. On the other side, setting this value higher means A.I. will shoot more directly at the moving enemy (and probably miss) as the A.I. will assume projectiles are fast enough to hit the target.

• Similar to Prediction speed, there are Ballistic projectile speed and Ballistic projectile gravity. When these two are set non-zero, A.I. assumes ballistic projectiles (grenades) and tries to shoot projectiles according to an ideal parabole (the solution with shorter fly time is always chosen). In order to make A.I. sucesfully hit enemy's pelvis, these two must again corespond with PAR3 particles's speed and particles's gravity attraction, but they can be used for modding purposes as well. For example if projectiles's gravity attaction is 0.5 but in ONWC Ballistic projectile gravity is set as 0.3, A.I. will shoot projectiles at enemy's feet as it will assume that gravity attraction of the projectile is lower thus it does not have to aim so high in order to hit the pelvis (credits to Gumby). Remember: for A.I. system, pelvis is a representation of a whole character.

• Targeting origin vector (ONWC) can be utilized to make A.I. fire not directly at pelvis, but for example higher (negative "z" component), so A.I. can score headshots. So far such a change does not have any purpose as characters don't have damage multipliers for bodyparts. But maybe in future...or with Paradox's headshot mod / material dependent damage mod ideas (see HERE).

• One thing purposefully left out in main talk about weapons is that there is an option for A.I. chracters to make "startle" misses - when startled, A.I. fires at some random direction. Parameters for this behavior are in ONCC and ONWC, but overall this feature is so subtle it does not need any special modding attention.

• Remember: in ONWC, Minimal shooting distance is divided by 2. Reason is unknown, maybe some bug in a code.

• Through modification of Minimal shooting distance in conjunction with BSL scripting, a modder can achieve pseudo-dynamic holster behavior. If enemy gets too close, A.I. start moving away, facing the enemy. Since simply backing away is almost never used by armed A.I. (it usually move to the side), it can be detected via BSL function chr_wait_animation and subsequent script makes A.I. character holster held weapon. To unholster, different animation check has to be used, for example a check for a taunt animation. In MELE, modder can set up approppriate melee profile which makes A.I. character taunt only at safe distance.

Drawback of this modification is is that enemy will not fire the weapon at point blank range and also it limits Melee override in CMBT to be only None or IfPunched, otherwise instead of backing away, A.I. character goes directly into melee.