Post by Zlixine on Sept 23, 2015 21:04:32 GMT
ORIGINALLY MADE BY DEEZIRE.
NOT RECOMMENEDED TO USE FOR BEGINNERS IF YOU ARE A BEGINNER USE THE AI EDITING TOOL.
Red Alert 2 AI.INI Guide
Sections Covered
• [TaskForces]
• [ScriptTypes]
• A Note On Structure Numbers
• [TeamTypes]
• [AITriggerTypes]
• A Note On AI Pool Teams
• Some Tips On Making A Better AI
This file controls the Artificial Intelligence employed by the game engine when it assumes the role of a computer controlled player. Red Alert 2 utilizes 'scripted' AI (that is, a system based on pre-determined actions and scripts rather than a 'heuristic' system, i.e. one which intelligently responds to player actions and attempts to forecast future player actions by recording a log of previous ones in a bid to nullify them thus giving itself a tactical advantage).
An attempt has been made to give the impression of heuristics in Red Alert 2 by implementing a success/failure delta system, where the computer keeps a record of instances where previous scripts were or were not successfully executed to completion, thus influencing the likelihood of them being used again. See the AI Trigger Weighting Parameters section in the RULES.INI Guide for details of these deltas.
TIP: to get more out of the AI and to make more effective use of the changes you make to this file, I recommend referring to the [AIGenerals] section (see the RULES.INI Guide). That section provides an ideal way to define specific overall playing styles and strategies for the AI - use of that technique will ensure that the AI relies less on simply playing the game in the same continual scripted manner regardless of the state of the battle and how its doing.
AI.INI is perhaps the least modified file but one which provides immense scope for mod writers as it allows customization through the game engine 'scripting' language in a similar manner to map files. The file contains the scripts which make the computer controlled armies function, and these are in addition to any supplementary scripts that may be contained within specific map files. Production and replacement of units, their generic behavioural characteristics as well as the specific missions that those units will go on are all controlled through this file.
In simple terms, the scripted system works like this;-
• The computer uses objects, or groups of objects, known as TaskForces...
• ...whose generic behaviour and unique properties are controlled by allocating them to TeamTypes...
• ...to carry out an action, or series of actions, controlled by ScriptTypes...
• ...which may or may not be triggered by predefined game events known as AITriggerTypes.
It should be noted that the AI.INI file provides great scope for modification in Red Alert 2. This is for several reasons - if you take a look through the file, it becomes clear that the computer is instructed to prioritize only certain types of attacks, only to use certain units (some are not used), and heavily favors ground based attacks (naval units are seldom used). Primarily however, the computer initially relied upon heavy ground assaults to overwhelm enemies because of the fact that its only enemies were humans, thus would not attack other computer controlled armies before the 1.004 patch. Despite that change however, the AI.INI file remained unmodified, and is less than half the size of than the Tiberian Sun one. NOTE: There is so much of the game engine unused within this file, that time spent on it will be well worthwhile - the Red Alert 2 engine is very powerful and versatile. A lot of this logic is residual from Red Alert and also from the enhancements made by Tiberian Sun - this is one reason why some features do not entirely work correctly in the Red Alert 2 engine.
To say that the AI in Red Alert 2 is poor is very wrong - as you will see, it is merely incredibly under utilized. You will be amazed at what is possible with a little time and effort. Note that to unleash the full potential of the AI, it is well worth studying the AI specific statements in RULES.INI too which offer a high degree of control of the generic AI behaviours - see the RULES.INI Guide. Editing the AI.INI file is not for the faint hearted, and I would suggest that you need a good command of the other INI files (particularly RULES.INI and map files) before embarking upon this!
NOTE: the use of '-G'as a suffix to the numbers throughout this file indicates that this is a 'global' value, meaning it will be used throughout the game regardless of any other conditions placed upon its use. In this case, duplicate use of the same number for the same purpose (for example on two different ScriptTypes or TaskForces) either in this file or within a map file will lead to an Internal Error. This means that you can call any of the TeamTypes, TaskForces or ScriptTypes defined in the AI.INI file from a map file without having to define it again in that map file. This is handy if you want to use something that has already been defined in the AI.INI file, thus reducing the size of your map file.
[TaskForces]
This section takes the form of a list of all TaskForces to be used by the computer generically across all games. The list is numbered starting at 0, new ones should be simply added to the end of the list. If you want the computer to make use of new units, or to use more units, then this section is the one to modify. Each entry in the list takes the form of a hexadecimal numbered string which is the unique identifier for each of the TaskForces - like other lists in the INI files, the game code requires that each entry in this list is defined with its own section in this file. For convention, it is wise to stick to this hex numbering system, although any string appears to be parsed.
An example is detailed below;-
[TASKFORCE]
Name=
a=x,UNIT
b=x,UNIT
c=x,UNIT
...
Group=
[TASKFORCE] - this is the unique identifier name used to define the section for this TaskForce and should also be contained in the above mentioned list.
Name= - this is simply a string name used for identification purposes only, it is not required by the game, although it is useful to leave this in for debugging and troubleshooting your AI.INI file - as a point of interest, this statement does not even get parsed.
n=x,UNIT - this is used to define which units are in this TaskForce. This is in the form of a list, and for each different unit you want in your TaskForce, you must have a separate line in the list. Each line consists of a number (how many of the unit) followed by a comma and then the name of that unit from the [BuildingTypes],[InfantryTypes],[VehicleTypes] or [AircraftTypes]lists from RULES.INI. Note that the numbering must start at 0. For example, to define a TaskForce with 5 GI's and 2 Grizzly Tanks, you could use;-
[TASKFORCE]
Name=5 GI's and 2 Grizzly Tanks
0=5,E1
1=2,MTNK
Group=-1
Group= - defines the default grouping for the units in this TaskForce which is therefore used when it has executed (or does not have) a ScriptType. This is over-ridden by the Group= setting in the associated TeamType. The following values can be used;-
-1 Lose Transports - any transports are dissolved
?? Lose Units, Lose Transports - all units dissolved
?? Keep Units, Keep Transports - all units retained
?? Lose Units, Keep Transports - only transports retained
?? Keep Units Farthest - only units furthest away are retained
?? Keep Units Nearest - only nearest units are retained
?? Greatest Threat - group together at object posing greatest threat
-40094 Least Threat - group together at object posing least threat
[ScriptTypes]
This section takes the form of a list of all ScriptTypes which can be used by TaskForces. The list is numbered starting at 0, new ones should be simply added to the end of the list. Each entry in the list takes the form of a hexadecimal numbered string which is the unique identifier for each of the ScriptTypes - like other lists in the INI files, the game code requires that each entry in this list is defined with its own section in this file. For convention, it is wise to stick to this hex numbering system although again this is not strictly necessary. The section entries describe what the TaskForce is going to do and consists of a list of action codes.
An example is detailed below;-
[SCRIPT]
Name=
a=x,y
b=x,y
c=x,y
...
[SCRIPT] - this is the unique identifier name used to define the section for this ScriptType and should also be contained in the above list.
Name= - this is simply a string name used for identification purposes only, it is not required by the game, although it is useful to leave this in for debugging and troubleshooting your AI.INI file - as a point of interest, this statement does not even get parsed.
n=x,y - this defines the action to be performed by the TaskForce to which this ScriptType is allocated. This takes the form of a list, and for each action you want the TaskForce to perform, you should have a new line in your script. Think of this like writing a computer program - for everything you want the computer to do, you add a new line to your program - its the same idea here. Again, by convention, the numbering must begin at 0. These scripts can become very complex and powerful tools, and provide one of the ultimate levels of editing potential in the game.
The first value, x, contains the action to perform. Some actions require a parameter, y, which provides information for the action - they mean different things for different actions. Here's an example of a script, the first line tells the computer to attack any enemy vehicles, and the second line tells the computer to attack anything when its finished the first line (i.e. after it has destroyed one vehicle);-
[SCRIPT]
Name=Attack any vehicle then attack anything
0=0,5
1=0,1
Here's a list of the script actions and their respective parameters (where appropriate);-
0,n = Attack Target Type, n = target type to attack
This instructs the TeamType to use the TaskForce to approach and attack the target specified by the second parameter. The following are the target types which can be used;-
0 N/A cancel attack mission
1 Anything anything (usually the first enemy object they encounter) - utilizes threat rating logic
2 Structures any enemy [BuildingTypes]
3 Ore Miners any enemy [VehicleTypes] with Harvester=yes set
4 Infantry any enemy [InfantryTypes]
5 Vehicles any enemy [VehicleTypes]
6 Factories any enemy [BuildingTypes] with a Factory= setting
7 Base Defenses any enemy [BuildingTypes] with IsBaseDefense=yes set
8 Base Threats any enemy objects approaching (or already in) its base and which are in an attack mission
9 Power Plants any enemy [BuildingTypes] with positive Power= values set
10 Occupiable any [BuildingTypes] with CanBeOccupied=yes set (usually neutral structures)
11 Tech Buildings any [BuildingTypes] with NeedsEngineer=yes set (usually NeutralTechBuildings=)
NOTE: in Yuri's Revenge, Occupiable structures are defined by having CanOccupyFire=yes set instead of CanBeOccupied=yes.
1,n = Attack Waypoint, n = waypoint number to attack
This instructs the TeamType to use the TaskForce to attack the waypoint number specified by the second parameter. If any members have Infiltrate=yes set they will enter the structure at the waypoint. Members with Engineer=yes set will capture the structure provided it does not have Capturable=no set or if it has NeedsEngineer=yes set. Members with Agent=yes set will spy on the structure if it has Spyable=yes set. Members that do not have Assaulter=no set will garrison the structure if it has CanBeOccupied=yes set. Members with C4=yes set will blow up the structure if does not have CanC4=no set. If there is no building at the specified waypoint, the TaskForce will move to the waypoint and will just remain in their last mission. Waypoints are used to define specific places (cells) on the map - see the Map Editing Guide for a detailed explanation of waypoints. At this point however, its worth noting that Red Alert 2 usually assigns waypoint number 98 to define the place where the player starts in single player games (also known as the 'home cell'), waypoint number 99 for the center of the map, and waypoint numbers 0 - 7 to define the starting places for the 8 players.
2,0 = Go Berzerk
Forces infantry units with Cyborg=yes set to go berserk (they consider all objects, including friendly units, equally in their threat scan).
3,n = Move To Waypoint, n = waypoint number to move to
This instructs the TeamType to use the TaskForce to move to the waypoint number specified by the second parameter. Waypoints are used to define specific places (cells) on the map - see the Map Editing Guide for a detailed explanation of waypoints. At this point however, its worth noting that Red Alert 2 usually assigns waypoint number 98 to define the place where the player starts in single player games (also known as the 'home cell'), waypoint number 99 for the center of the map, and waypoint numbers 0 - 7 to define the starting places for the 8 players. TIP: you could use this script action to get a TeamType to move to Waypoint= number 99 (just about every map has this defined as the center point) - that will mean it will always strive to get to the center of the map, providing a good vantage point from which to perform further script actions and giving the impression that the computer is scouting for enemies.
4,n = Move Into Specific Celltag, n = celltag to move into
This instructs the TeamType to use the TaskForce to move into the CellTag specified by the second parameter. This is used when you want the TeamType to trigger a specific Action (when the game tests for the CellTag being entered). CellTags are attached to cells and are used to trigger Events and thus fire Actions when that cell is entered by a unit (or any unit from the TaskForce). The CellTag parameter should be the waypoint parameter for that CellTag from the [CellTags]listing in the map file, hence this script action is only of use on specific map files. See the Map Editing Guide for a detailed explanation of CellTags and their use.
5,n = Guard Area, n = time to guard area in tenths of a minute (multiples of 6 seconds)
This instructs the TeamType to put the TaskForce into Guard Mode (same effect as selecting a group of units and pressing the Guard Mode key as defined in KEYBOARD.INI or clicking the relevant button on the Advanced Command Bar). Units will move to attack enemy units that fall within their Sight= range.
6,n = Jump To Script Action, n = number of script action to jump to
This is used to repeat actions within the ScriptType. The second parameter is the action number of the ScriptType that you want to jump to. Remember that the first action of a ScriptType is numbered 0 so if you jump to this (by using n=6,0 for example) you get the TaskForce to repeat all the commands it has, looping forever. This is used by the waypoint system in the game for setting up patrols. You don't have to repeat all the actions as you could jump to say action 3, which would ignore the first three action commands (remember, the numbering starts at 0) and just go to the fourth.
7,0 = Force Player Win
Forces a game win condition for the owner of the TeamType (they win the game).
8,n = Unload, n = type of unloading
If the TaskForce contains a unit or units that have a valid Passengers= value set, and those units contain passengers, this command will make the units inside the transport(s) disembark. Note that once the passengers have disembarked, the transport itself is suspended until given a new mission and is therefore no longer considered a part of this TaskForce - this means that you cannot, for example, get units to disembark, do something, then get back into the transport in the same script. The second parameter can be used to control what happens to the transport after it 'deploys' its cargo;-
0 Keep transports and units - all remain in the team and execute the remainder of the script
1 Keep transport and lose the units - only the transport will execute the remainder of the script
2 Lose transport and keep units - only the units will execute the remainder of the script
3 Lose transports and lose units - nothing executes the remainder of the script
9,0 = Deploy
If the TaskForce contains a unit or units that are able to deploy (for example a unit which DeploysInto= a [BuildingType] or has any of Deployer=yes, DeployFire=yes, DeployToFire=yes set) then this action causes them to deploy at the current cell they are occupying (same effect as selecting a unit and pressing the Deploy key as defined in KEYBOARD.INI or clicking the relevant button on the Advanced Command Bar).
10,0 = Follow friendlies
This command causes the TaskForce to follow the nearest friendly unit when it moves although it will not function as if it is 'guarding' the unit. The following is not permanent, when the TaskForce is assigned another mission it abandons the following. TIP: If the support TeamType has this as the first line in its ScriptType, then it will escort the first TeamType.
11,n = Assign New Mission, n = new mission type
The objects in the TaskForce are all assigned the new mission defined by the second parameter. Not all of them work, some are made obsolete by other action commands, some do not work because an object in the TaskForce may not support that action. Because these are the same 'behaviours' to which objects can be assigned when initially placed on the map some apply only to structures. The following are valid settings for the second parameter, you should refer to the Mission Control section of the RULES.INI Guide for a more detailed explanation of the missions and how they work;-
0 Sleep object sits around and plays dead, will not acquire targets
1 Attack special attack mission used by AI team types (utilizes threat rating logic)
2 Move simply moving to destination
3 QMove special move to destination after other queued moves occur
4 Retreat object runs away (may even leave the map)
5 Guard object sits around and will engage an enemy that falls within its weapon range
6 Sticky just like guard mode, except the object will engage enemies but not pursue them
7 Enter enter building or transport
8 Capture engineer entry logic used by MultiEngineer
9 Eaten when object is being repaired (applies only to structures)
10 Harvest the loop controlling harvesting of Ore and dumping at a Refinery
11 Area Guard guard the general area where the object starts at
12 Return return to co-ordinating object (e.g. spawned object returns to the spawner)
13 Stop stop moving or firing at the first available opportunity
14 Ambush force fire (units with Infiltrate=yes will enter target if possible)
15 Hunt scan for and attack enemies wherever they may be on the map
16 Unload while dropping off cargo (e.g. Landing Craft unloading passengers)
17 Sabotage unit runs to place C4 on a building or Ivan goes to place bomb on object
18 Construction structures use this when building up after initial placement
19 Selling structures use this for deconstruction after being sold
20 Repair used when repairing an object (e.g. Service Depot)
21 Rescue special team over-ride mission
22 Missile Nuke Silo special launch missile mission
23 Harmless object doesn't fire and is not considered in any threat scan
24 Open while opening or closing a gate to allow passage
25 Patrol patrol a series of waypoints
26 Paradrop Approachobject is approaching the paradrop site
27 Paradrop Overfly object is flying over the paradrop site (i.e. dropping the paratroopers)
28 Wait paused and awaiting next mission
29 Move (special duplicate) used when Chrono units are moving to destination
30 Attack (special duplicate) used when units are deployed to fire (e.g. weapons with an area fire effect)
31 Spyplane Approachobject is flying towards target (YR)
32 Spyplane Overfly object is flying over the target (YR)
NOTE: there is a difference when using Area Guard as opposed to Guard. Units with an Area Guard mission are more aggressive and will pursue enemy units that fall within their Sight= range and continue that pursuit until they can attack the target. Then the units will return to their original position unless they catch the target within their initial guard zone (in which case they will attempt to destroy it). Units in an Area Guard mission are not recruited 'from the field' when a create team Action is executed, although units in a standard Guard mission will be gathered to create the new team if they are required.
12,n = Set Global, n = global number to be set
The global number specified in the second parameter is defined as being 'set' (it is allocated a value of '1' or 'true'). This should be employed in specific map files only. This is part of the boolean logic employed by the global variables system in the game engine - refer to the Map Editing Guide for a more detailed explanation of global and local variables. The Global Variables are defined in RULES.INI - see the RULES.INI Guide.
13,n = Play Idle Anim Sequence, n = sequence number
If the TaskForce contains a unit or units that are SHPs (i.e. infantry) then the relevant idle SHP sequence is displayed as defined by the frame numbering system in ART.INI.
14,0 = Load Onto Transport
If the TaskForce contains a unit or units that have a valid Passengers= value set, and units whose Size= and PhysicalSize= settings allow them to be carried by that transport, this command will make the units enter the transport.
15,n = Spy On Structure At Waypoint, n = waypoint number
Should be used only for units with Infiltrate=yes and Agent=yes set. This instructs the TaskForce to enter the structure at the waypoint number specified by the second parameter and spy on the structure if it has Spyable=yes set. If there is no building at the specified waypoint, the TaskForce may not activate correctly and will just remain in their last mission. Waypoints are used to define specific places (cells) on the map - see the Map Editing Guide for a detailed explanation of waypoints. At this point however, its worth noting that Red Alert 2 usually assigns waypoint number 98 to define the place where the player starts in single player games (also known as the 'home cell'), waypoint number 99 for the center of the map, and waypoint numbers 0 - 7 to define the starting places for the 8 players.
16,n = Patrol to waypoint, n = waypoint number
This is similar to Move to waypoint. This instructs the TeamType to use the TaskForce to move to the waypoint number specified by the second parameter. The difference is that the units in the TaskForce will move out of their patrol route to actively go and engage any enemy objects that are within their Sight= as they move to the waypoint. NOTE: this action eats up processor time, because the TaskForce will scan for enemy objects with each movement. If you have a lot of TaskForces (or lots of units in them) engaged in this action, you will experience slowdown in the game - this is one reason why the single player missions are comparatively slow, they use this action a lot. The rate at which the scanning for targets whilst in this mission is controlled by the PatrolScan= statement in the [AI]section of RULES.INI (see the RULES.INI Guide). Waypoints are used to define specific places (cells) on the map - see the Map Editing Guide for a detailed explanation of waypoints. At this point however, its worth noting that Red Alert 2 usually assigns waypoint number 98 to define the place where the player starts in single player games (also known as the 'home cell'), waypoint number 99 for the center of the map, and waypoint numbers 0 - 7 to define the starting places for the 8 players.
17,n = Change Script, n = script number to execute
Very handy and under utilized - this instructs the TaskForce to execute another ScriptType. The second parameter specifies the number of the ScriptType to execute as listed in the [ScriptTypes]table (consider the table as being numbered starting at 0 for this purpose).
18,n = Change Team, n = team number to join
This instructs the TaskForce to join another TeamType. The second parameter specifies the number of the TeamType to join as listed in the [TeamTypes]table (consider the table as being numbered starting at 0 for this purpose).
19,0 = Panic
If the TaskForce contains a unit or units that have Fraidycat=yes set then they will run around aimlessly, using the Panic= animation from their sequence as defined in ART.INI. Normally used for the civilian units. Units that do not fulfil this criteria lie down and act as if prone.
20,n = Change House Ownership, n = house number of new owner
Used in single player missions on specific map files only, this changes ownership of the entire TeamType to the House= number specified by the second parameter. See the Map Editing Guide for details of [Houses] and their numbering.
21,0 = Scatter
This instructs the TaskForce to scatter (same effect as selecting a group of units and pressing the Scatter key as defined in KEYBOARD.INI).
22,0 = Afraid & Run To Shroud
This instructs the TaskForce to behave in a scared manner and it will run to the nearest shrouded cell. The TaskForce will not actively engage in combat, will not acquire targets and will not retaliate (it will scatter instead if attacked).
23,0 = Force Player Loss
Forces a game loss condition for the owner of the TeamType (they lose the game).
24,n = Play Speech From EVA.INI, n = number of speech to play
This instructs the TaskForce to play one of the Sofia or EVA voices (depending upon the ParentCountry= or the owner of this TaskForce). The second parameter is the number of the sound to be played from the [DialogList] in the EVA.INI file (note that you should consider this list as being numbered from 0 instead of 1 to get the correct numbering convention).
25,n = Play Sound From SOUND.INI, n = number of sound to play
This instructs the TaskForce to play one of the generic in game sounds from the [SoundList] in the SOUND.INI file (note that for all in game Action and Trigger purposes this number is from an internal table - see the Map Editing Guide).
26,n = Play Movie
This instructs the TaskForce to play one of the movies from the [Movies] list in the ART.INI file (note that for all in game Action and Trigger purposes this number is from an internal table - see the Map Editing Guide).
27,n = Play Theme From THEME.INI, n = number of theme to play
This instructs the TaskForce to play one of the game soundtracks from the [Themes] list in the THEME.INI file (note that for all in game Action and Trigger purposes this number is from an internal table - see the Map Editing Guide).
28,0 = Reduce Ore
Reduces the amount of Ore in the cell that the TeamType is occupying. Used by the special 'weapon' that is inherent with Ore Miners.
29,0 = Begin Production
Forces the owner of the TeamType to begin the auto-production process (the AI's behaviour in skirmish games). Should only be used on AI controlled houses.
30,0 = Force Sale
Forces the 'fire sale' of all remaining structures owned by the House= to which the TeamType belongs.
31,0 = Suicide
This instructs the TaskForce to destroy itself. In effect it commits suicide, usually accompanied by an explosion.
32,n = Start Weather Storm In...
This initiates the Weather Storm intro effect (when the screen goes dark prior to the clouds appearing) and is set to be delayed by the number of seconds specified by parameter 2.
33,0 = End Weather Storm
This forces an end to the Weather Storm intro effect (when the screen goes dark prior to the clouds appearing).
34,n = Center Map On Team
This will center the screen on the TeamType. The same effect as hitting the Home key as defined in KEYBOARD.INI when the screen centers on your MCV (or the unit defined by the BaseUnit= statement in RULES.INI). The second parameter determines the speed at which the 'camera' switches view to the TaskForce with 0 being instant.
35,n = Shroud Map For Time Interval, n = time to remain shrouded
This action will shroud the entire map except for the area around the players MCV's (if they have one). The second parameter determines the number of frames for which the map should remain shrouded (1 second = approximately 15 frames) after which the explored areas are revealed again.
36,n = Reveal Map For Time Interval, n = time to remain revealed
This action will reveal the entire map. The second parameter determines the number of frames for which the map should remain revealed (1 second = approximately 15 frames) after which the map is shrouded again.
37,0 = Delete Team Members
This forces dissolved members of the TaskForce to leave the map after which they are deleted (for example aerial transports after their passengers have disembarked).
38,n = Clear Global, n = Global number to be cleared
The global number specified in the second parameter is defined as being 'clear' (it is allocated a value of '0' or 'false'). This should be employed in specific map files only in which the global variable has been defined. This is part of the boolean logic employed by the global variables system in the game engine - refer to the Map Editing Guide for a more detailed explanation of global and local variables. The Global Variables are defined in RULES.INI - see the RULES.INI Guide.
39,n = Set Local, n = Local number to be set
The local variable number specified in the second parameter is defined as being 'set' (it is allocated a value of '1' or 'true'). This should be employed in specific map files only in which the local variable has been defined. This is part of the boolean logic employed by the local variables system in the game engine - refer to the Map Editing Guide for a more detailed explanation of local and global variables.
40,n = Clear Local, n = Local number to be cleared
The local variable number specified in the second parameter is defined as being 'cleared' (it is allocated a value of '0' or 'false'). This should be employed in specific map files only in which the local variable has been defined. This is part of the boolean logic employed by the local variables system in the game engine - refer to the Map Editing Guide for a more detailed explanation of local and global variables.
41,n = Unpanic
If the TaskForce contains a unit or units that have Fraidycat=yes set which are currently assigned the Panic= mission then this action nullifies that effect and the unit(s) adopt their default behaviour.
42,n = Change Facing, n = new direction to face
This instructs the TaskForce to turn and face the new direction specified by the second parameter. The facings are as follows;-
0 North
1 North East
2 East
3 South East
4 South
5 South West
6 West
7 North West
43,0 = Wait Until Fully Loaded
This is always used after members of the TaskForce have entered a transport in the same TaskForce and serves two purposes. The effect of this is that the transport will be used to carry out any subsequent movement or deploy actions but after that it is no longer considered a part of this TaskForce and as such is available to be recruited into new TeamTypes. It is this action which enables use of the TransportsReturnOnUnload=yes statement in the corresponding TeamType entry. The second purpose is to flag the transport as being 'loaded' with passengers and thus is considered in the AI's targeting logic as a potential threat (see the ContentScan= entry in the RULES.INI Guide). This action also orders the transport to wait until it is fully loaded before executing any subsequent script actions.
44,0 = Unload TRUCKB > TRUCKA
Used purely for a graphical effect and applicable uniquely to the [TRUCKB] unit, this has the effect of converting [TRUCKB] into [TRUCKA] to give the impression that the unit has unloaded its cargo. NOTE: this is residual from Tiberian Sun and as such may not work correctly since [TRUCKA] refers to the Demo Truck image in Red Alert 2 which has no 'unloaded' image. Changing the image for the Demo Truck and assigning new units to [TRUCKA] and [TRUCKB] enables use of this logic.
45,0 = Load TRUCKA > TRUCKB
Used purely for a graphical effect and applicable uniquely to the [TRUCKA] unit, this has the effect of converting [TRUCKA] into [TRUCKB]to give the impression that the unit has been loaded with cargo. NOTE: this is residual from Tiberian Sun and as such may not work correctly since [TRUCKA] refers to the Demo Truck image in Red Alert 2 which has no 'unloaded' image. Changing the image for the Demo Truck and assigning new units to [TRUCKA] and [TRUCKB] enables use of this logic.
46,n = Attack Enemy Structure, n = structure number (see note below)
Members of this TaskForce attack the enemy structure specified by the second parameter. This action depends upon the type of units in the TaskForce and if certain members have Infiltrate=yes set. Members with Engineer=yes set will capture the structure provided it does not have Capturable=no set or if it has NeedsEngineer=yes set. Members with Agent=yes set will spy on the structure if it has Spyable=yes set. Members that do not have Assaulter=no set will garrison the structure if it has CanBeOccupied=yes set. Members with C4=yes set will blow up the structure if does not have CanC4=no set.
47,n = Move To Enemy Structure, n = structure number (see note below)
Members of this TaskForce move and stay adjacent to the enemy structure specified by the second parameter.
48,0 = Scout
Causes members of this TaskForce to move to a pre-determined point on the map in an attempt to scout an area. The effect is that the TaskForce will move in one randomly chosen direction until it is no longer able to do so which can make it very useful or a waste of time depending on the direction chosen. If you want to continually scout the map, you should loop this script action.
49,0 = Repeat Until Success
This is typically used after an Attack Target instruction. This forces the TaskForce to carry out its previous action in the script continually until all of the target types specified by that previous instruction no longer exist, at which point the TaskForce moves on to the next instruction after this one. The action is continually executed until any condition on its use can no longer be met (for example if the previous action was Attack Vehicles and all vehicles have been destroyed, the script moves on to the next action). In other words, this can be used to set a 'success' condition on the script.
50,n = Flash (visual effect), n = number of flashes
This causes the TaskForce to 'flash', the visual effect you get on an object when you order something to attack it. The second parameter is the number of times to flash the unit 'white'.
51,n= Play Animation, n = animation number
This instructs the TaskForce to play one of the animations from the [Animations] in the RULES.INI.INI file (note that for all in game Action and Trigger purposes this number is from an internal table - see the Map Editing Guide).
52,n = Display Talk Bubble, n = talk bubble number
Should be used for single-unit TaskForces only, this causes a 'talk bubble' to appear above the unit. The second parameter determines which type of talk bubble to display;-
1 * general speech
2 ? question
3 ! shouting or statement
Note that the length of time for which the talk bubble is displayed is controlled through the TalkBubbleTime= statement in RULES.INI - refer to the RULES.INI Guide for details of this and the steps to take to enable its inclusion in Red Alert 2 as this remains residual from Tiberian Sun:Firestorm.
53,0 = Gather (at enemy base)
This causes the TaskForce to gather together (sometimes used when members of the TaskForce move at different speeds and you want the faster ones to stop while the slower ones catch up) after the previous action has been executed. If the TaskForce is in an attack mission and moving towards an enemy base, this command is usually executed when the first member of the TaskForce reaches the distance from that base defined by the AISafeDistance= statement in RULES.INI - see the RULES.INI Guide.
54,0 = Regroup (at friendly base)
This causes the TaskForce to regroup, if for example any of its members have become engaged in a base defense mission or strayed away whilst in guard mode, or even the TeamType itself has been suspended for whatever reason. The members regroup directly next to each other leaving no 'gaps' at the nearest available point with sufficient space, and is used, for example, prior to activating the Iron Curtain so that all applicable members are affected (i.e. they fall within its range of effect).
55,0 = Activate Iron Curtain on TaskForce
If the owner of the TaskForce to which this ScriptType is attached also has the Iron Curtain fully charged then it will be fired at this TaskForce. Note that the use of the Iron Curtain in this manner depends on the percentage chance of the AI incorporating them into its actions as defined by the AIMinorSuperReadyPercent= statement in RULES.INI - see the RULES.INI Guide for more details.
56,n = ChronoSphere TaskForce, n = structure number to be Chronoshifted to (see note below)
If the owner of the TaskForce to which this ScriptType is attached also has the Chronosphere fully charged then it will be used on the TaskForce before moving on to the next action. Note that the use of the Chronosphere in this manner depends on the percentage chance of the AI incorporating them into its actions as defined by the AIMinorSuperReadyPercent= statement in RULES.INI - see the RULES.INI Guide for more details.
57,n = ChronoWarp TaskForce, n = target number to be Chronoshifted to (see note below)
If the owner of the TaskForce to which this ScriptType is attached has been Chronosphered then it will be used on the same TaskForce to shift them to the enemy structure number specified in the second parameter before moving on to the next action. Note that the use of the Chronosphere in this manner depends on the percentage chance of the AI incorporating them into its actions as defined by the AIMinorSuperReadyPercent= statement in RULES.INI - see the RULES.INI Guide for more details.
58,n = Move To Friendly Structure, n = structure number (see note below)
Members of this TaskForce move and stay adjacent to the friendly structure specified by the second parameter. The structure can be one owned by the owner of the TaskForce or any of its allies.
59,n = Attack Structure At Waypoint (Yuri's Revenge only)
Members of this TaskForce attack the structure at the Waypoint= specified by the second parameter. This action is very similar to action number 43 although this action does not test for ownership of the structure itself - thus the inclusion of this action allows, for example, InfantryTypes with Engineer=yes set to enter structures owned by the same side for the purposes of repair. This would be the most appropriate action to use to get the AI to repair bridges. Use of this also means that the TaskForce will attack the structure with one of its weapons meaning, for example, that units with C4=yes set will not C4 the building but shoot at it instead. This is useful if you want to get a TaskForce to destroy a nearby occupiable structure instead of entering it in a bid to prevent the enemy getting old of it - a tactic used in the Yuri's Revenge AI.
60,0 = Enter Grinder (Yuri's Revenge only)
Members of this TaskForce will enter the nearest structure with Grinding=yes set if it is owned by the owner of the TaskForce or any of its allies.
61,0 = Occupy Tank Bunker (Yuri's Revenge only)
Any VehicleType members of this TaskForce which do not have Bunkerable=no set will enter the nearest vacant structure with Bunker=yes set if it is owned by the owner of the TaskForce or any of its allies.
62,0 = Enter Bio Reactor (Yuri's Revenge only)
Any InfantryType members of this TaskForce will enter the nearest structure with InfantryAbsorb=yes set if it is owned by the owner of the TaskForce or any of its allies and has space available.
63,0 = Occupy Battle Bunker (Yuri's Revenge only)
Any InfantryType members of this TaskForce with Occupier=yes set will enter the nearest structure (which they own) with CanOccupyFire=yes set.
64,0 = Garrison Structure (Yuri's Revenge only)
Any InfantryType members of this TaskForce with Occupier=yes set will enter the nearest (neutral) structure with CanOccupyFire=yes set. This action is used specifically for this purpose due to action #59 (see above) since the logic in Yuri's Revenge has changed so that the units weapon is transferred to the structure. Use of this action also allows the computer to repair those structures by sending an InfantryType with Engineer=yes set into them and also allows the AI to differentiate between attacking such a structure and entering it, which is useful if you want the AI to use infantry to destroy an occupiable structure thus preventing its enemy from using it.
• A Note On Structure Numbers
When used in ScriptTypes, the structure number takes any of several formats and is derived by finding the structure in the [BuildingTypes] list of RULES.INI and subtracting ONE from this structures' number in that list (equivalent to renumbering the list from 0) - this is the explicit number of that structure and is the number to use as the second parameter of the action. Any one of several amendments can be made to this number;-
• add 131072 to the number, so GAPOWR (number 1 in RULES.INI thus number 0 for this purpose) becomes 131072
• add 196608 to the number, so GAPOWR (number 1 in RULES.INI thus number 0 for this purpose) becomes 196608
• add 65534 to the number, so GAPOWR (number 1 in RULES.INI thus number 0 for this purpose) becomes 65534
It has not been determined what significance or effect the different numbering systems have (if any). Changing them at random appears to have no effect although it is thought that there is additional logic attached to them.
[TeamTypes]
This section defines the TeamTypes, which connect a ScriptType with a TaskForce while adding some generic behaviour parameters (ie behaviours which apply to every member of the TaskForce) whether they are how the TeamType is created, or how it behaves after it has been created. These behavioural modifiers make it difficult to entirely predict or determine the TeamTypes behaviour. The maximum number of TeamTypes which can be in existance at any one time is controlled with the TotalAITeamCap= statement in RULES.INI - refer to the RULES.INI Guide for a more detailed explanation of this and many other statements relating to the AI. These can be created in any of several ways;-
• within individual map files by an Action when some pre-determined condition is met by the game code (known as an Event) - see the Map Editing Guide
• when a generic game event occurs that may not be specific to a particular map, scenario or House (known as an AITriggerType, again these can be employed and even defined in individual map files)
• based on time rather than an Event or a Trigger, the TeamType is automatically created and used, known as Autocreate - this process is inherent in the game code in skirmish games with the frequency of this process being controlled by the TeamDelays= statement in RULES.INI (see the RULES.INI Guide). In map files, you must trigger this process yourself through the relevant Action (see the Map Editing Guide).
The section takes the form of a list of all TeamTypes. The list is numbered starting at 0, new ones should be simply added to the end of the list. Each entry in the list takes the form of a hexadecimal numbered string which is the unique identifier for each of the TeamTypes - like other lists in the INI files, the game code requires that each entry in this list is defined with its own section in this file. For convention, it is wise to stick to this hex numbering system although again this is not strictly necessary. The following statements can be used;-
Name=
This is simply a string name used for identification purposes only, it is not required by the game, although it is useful to leave this in for debugging and troubleshooting your AI.INI file - as a point of interest, this statement does not even get parsed.
VeteranLevel=
Is used to determine the level of 'veterancy' that each member of the TaskForce used by this TeamType has. Use 1 for 'Little Experience' (default), 2 for 'Veteran' and 3 for 'Elite'. Higher numbers can be used if you edit RULES.INI - see the Veteran Factors section of the RULES.INI Guide for more details.
(YR) MindControlDecision=
Determines what a member of the associated TaskForce will do if it 'mind controls' its target. This only works if that has been placed in an 'attack' type mission, as it gets over-ridden by other specific script actions. The decisions are;-
0 = nothing (default behaviour) used to indicate that the TeamType should not use this logic
1 = add to AI's side as Recruitable=yes for further teams
2 = send it to a structure with Grinding=yes set for sale (e.g. Grinder) if owned
3 = send it to a structure with InfantryAbsorb=yes and/or UnitAbsorb=yes set (e.g. Bio Reactor) if owned
4 = set object in 'Hunt' mission
5 = do nothing
The percentage chances of each of those actions as well as the parameters used to assist the decision can be customized through the AICaptureNormal=, AICaptureWounded=, AICaptureLowPower=, AICaptureLowMoney=, AICaptureLowMoneyMark=, and AICaptureWoundedMark= statements in RULESMD.INI (see the RULES.INI Guide).
Loadable=
Can be set to 'yes' or 'no' and is used to determine if the associated TaskForce should reload when any of its members run out of Ammo= . This is required in case a particular unit has to dock with a co-ordinating structure to reload, a process which is a mission in itself and thus could interrupt (and possibly cause havoc with) the actions for the TeamType as defined by the associated ScriptType as 'nesting' missions in this manner could cause Internal Errors - objects can only be in one mission at a time. This logic is residual from Red Alert (where it was used primarily for the Mine Layer code) and may be obsolete in Red Alert 2.
Full=
Should be used only in map files, this can be set to 'yes' or 'no' and determines if any units within the associated TaskForce should be initially 'full' as determined by the PipScale= statement in their RULES.INI entry - this applies only to Ore Miners and transport type units in Red Alert 2. If the TaskForce contains a Transport and other units, the units are automatically placed in the Transport for reinforcement purposes.
Annoyance=
Can be set to 'yes' or 'no' and is used to determine if destroyed members of the associated TaskForce are automatically replaced by the AI and allocated the same ScriptType, the supposed effect being that this TeamType annoys the player with its persistence.
GuardSlower=
Can be set to 'yes' or 'no' and has the effect of increasing the default value of BaseDefenseDelay= as defined in RULES.INI specific to this TeamType so that members of the associated TaskForce in a base defense mission take longer to respond to any threats to themselves or any objects they are guarding. The factor by which that value is increased has not been determined.
House=
Should be used within map files and simply defines the House= to which ownership of this TeamType is automatically passed upon creation. For general AI.INI TeamTypes this should be set to <none>. TIP: In Yuri's Revenge, this can be used to refer to multiplayer (including human) houses by specifying individual player houses at any of the 8 starting Waypoints= on the map. For example, to specify the player at the first starting waypoint, you can use House=<Player @ A>. The letters A to H can be used to represent Waypoint= numbers 0 - 7 inclusive, thus it is possible to provide reinforcements to human players in multiplayer games. For map file Trigger, Event and Action purposes, the multiplayer houses are numbered 4475 - 4482, again representing the House= at each of the Waypoints numbered 0 - 7 inclusive.
Recruiter=
Can be set to 'yes' or 'no' and determines if this TeamType can be created by using any objects required to assemble the associated TaskForce that already exist on the map (provided they are not already part of an existing TeamType).
Autocreate=
Can be set to 'yes' or 'no' and specifies whether or not this TeamType should be created based on time rather than any form of trigger. The AI.INI file usually defaults to 'no' - this is because a TeamType with Autocreate=yes set is, obviously, subject to being automatically created. Each House= can, independently, have this function activated through the relevant Action within a map file. As mentioned above, the frequency of this process is controlled by the TeamDelays= statement in RULES.INI (see the RULES.INI Guide).
Prebuild=
Can be set to 'yes' or 'no' and determines if an inactive duplicate of the associated TaskForce should be created before it may be needed. This is used in case the TeamType has a high Priority= setting so that the AI has a backup should the original be destroyed (useful if the TaskForce contains an object which is expensive or takes a long time to produce). This is how the AI can sometimes appear to produce expensive units very quickly in some single player missions.
Reinforce=
Used in map files only for single player missions, this can be set to 'yes' or 'no' and determines if this TeamType forms reinforcements, in other words if set to 'yes' then the TeamType is expected to be created from off the map rather than on it.
Droppod=
Can be set to 'yes' or 'no' and determines if the TaskForce should be delivered by the AircraftType defined by the name [DPOD] in RULES.INI. This is entirely residual from Tiberian Sun (where that unit was simply a placeholder for this purpose which used the Drop Pod Locomotor=) and may be linked to and used by the Paradrop logic in some way by Red Alert 2. The DPOD unit must have Passengers= and SizeLimit= values set accordingly (to allow it to carry the TaskForce) and for this purpose should also have Spawned=yes set. See the relevant entries in the RULES.INI Guide for more details of customizing the Drop Pod effect.
UseTransportOrigin=
Can be set to 'yes' or 'no' and determines whether or not this TeamType should be created at the point of origin of its transport, if the transport itself already exists and has been recruited into this TeamType. This is used in map files to create reinforcement teams from off the map that will arrive on a transport.
Whiner=
Can be set to 'yes' or 'no' and is used only by 'pool' TeamTypes (see AITriggerTypes) to determine if destroyed members of the associated TaskForce are automatically replaced by the AI. This is because 'pool' TeamTypes are normally assigned to base defense missions or generic missions such as guarding, hunting or scouting and their members are always made available for recruitment into further teams (a mechanism which ensures that the AI doesn’t always have to produce every team from scratch since it will have a pool of units from which to assemble future teams).
LooseRecruit=
Can be set to 'yes' or 'no' and determines whether or not this TeamType should be dissolved after completion of its assigned ScriptType if that mission was successful (in other words the members of its associated TaskForce are then free to be recruited into another TeamType).
Aggressive=
The TeamType will execute orders regardless of enemy action and will not stop to engage in combat with enemy objects, although it may retaliate and return fire on the way. The supposed effect is that the associated TaskForce will doggedly aspire to complete its assigned ScriptType.
Suicide=
The TeamType will execute orders regardless of enemy action and will not stop to engage in combat with enemy objects and will not retaliate or return fire. It will ignore Sight= ranges and the GuardRange= of any enemy objects and will not be recruited into any subsequently created TeamTypes on the presumption that its associated ScriptType will invariably lead to the destruction of the associated TaskForce.
Priority=
This is used to determine the priority of this TeamType being chosen for creation when the AI is deciding what to do next. The lower the number, the greater the likelihood of the AI using this TeamType above others. For simplicity, Red Alert 2 uses multiples of 5 for this setting (Tiberian Sun used multiples of 4) so it is best to stick with this convention although other values between 1 and 50 can be used. Note that the setting of the SuspendPriority= statement in RULES.INI uses this value to determine whether or not this TeamType will be suspended during base defense missions (see the RULES.INI Guide for more details).
Max=
This serves two purposes. Firstly, it serves as a trigger to create the TeamType - when set to '1', it will automatically be created by the AI regardless of whether or not it is already triggered for creation through an AITriggerType or otherwise only if IsBaseDefense=no is set for this TeamType (see below). Secondly, it serves to indicate the maximum number of instances of this TeamType that can exist at the same time only if Autocreate=yes has been set for this TeamType (see above).
TechLevel=
This is obsolete in Red Alert 2 and is unused. In previous C&C games, this was used as a method of restricting AI auto production by determining the lowest TechLevel= at which this team could be employed by the AI, however the TechLevel= setting in Red Alert 2 has become all but obsolete as this can no longer be determined by players. Leave this set to its default of 0 (see the AITriggerTypes section for a further explanation of how the TechLevel= setting is used by the AI as a result of a change in the game engine code for Red Alert 2) .
Group=
This defines a specific grouping for the units in this TaskForce which is used when executing its ScriptType. This over-rides the Group= setting in the associated TaskForce. The following values can be used;-
-1 Lose Transports - any transports are dissolved and do not execute the script
?? Lose Units, Lose Transports - all units dissolved, nothing executes the script
?? Keep Units, Keep Transports - all units retained and all execute the script
?? Lose Units, Keep Transports - only transports retained to execute script
?? Keep Units Farthest - only units furthest away are retained
?? Keep Units Nearest - only nearest units are retained
?? Greatest Threat - group together at object posing greatest threat
-40094 Least Threat - group together at object posing least threat
Tag=
Used in map files only, this is used to determine which of the [Tags] is attached to this TeamType if there is a map-specific Event and Action attached to it (e.g. it gets destroyed or should be created). See the Map Editing Guide for further details on [Tags] and their use. This is not ordinarily used in AI.INI.
Waypoint=
Used in map files only, this is used to determine the waypoint at which the TeamType is to appear. You should ensure that the waypoint you specify here is included in the [Waypoints]section of the map file. See the Map Editing Guide for a detailed explanation of waypoints. This is not ordinarily used in AI.INI although its worth noting that Red Alert 2 assigns waypoint number 99 for the center of the map and waypoint numbers 0 - 7 to define the starting places for the 8 players in multiplayer maps.
OnTransOnly=
Can be set to 'yes' or 'no' and determines whether or not this TeamType should only execute its associated ScriptType if that ScriptType contains a 'load on transports' action. If that action is not successfully completed, the TeamType is dissolved and the members of the associated TaskForce are made available for recruitment into further TeamTypes . This is used to ensure that the TaskForce only carries out its mission if it has a transport or can be transported (as it may depend upon it).
TransportWaypoint=
Used in map files only. Can be set to 'yes' or 'no' and specifies the waypoint at which the transport for this TeamType is created if its at a separate place to the rest of the TeamType.
AvoidThreats=
Can be set to 'yes' or 'no' and determines whether or not this TeamType should take evasive action, meaning it will avoid, where possible, Sight= ranges and the GuardRange= of any enemy objects. If set to 'no', the TeamType will engage and return fire on any enemy objects it encounters during execution of its ScriptType (if, of course, it is able to do so).
IonImmune=
Can be set to 'yes' or 'no' and determines whether or not members of the associated TaskForce are immune to the effects of Weather Storms. This is probably obsolete in Red Alert 2 as it is residual from Tiberian Sun, where the occurrence of an Ion Storm would instantly destroy any airborne objects - this tag would nullify that effect for this TeamType.
TransportsReturnOnUnload=
Can be set to 'yes' or 'no' and determines whether or not any transports within the associated TaskForce should return to their point of origin upon deployment of their contents provided they have been released from that TaskForce by use of the 'dissolve transport' action or using an appropriate second parameter on the 'unload transports' action (see above). The purpose of this is primarily due to the fact that most transports are unarmed and thus unable to carry out any other mission, so by returning to their point of origin they are made immediately available for recruitment into further TeamTypes.
AreTeamMembersRecruitable=
Can be set to 'yes' or 'no' and determines whether or not members of the associated TaskForce are available to be recruited into further TeamTypes when they have completed the actions detailed in the associated ScriptType. This is used because you can't actually recruit units that are already in a TeamType.
IsBaseDefense=
Used mainly for 'pool' teams (see AITriggerTypes). Can be set to 'yes' or 'no' and determines whether or not this TeamType should assume a base defense mission based on the actions detailed in its associated ScriptType. The number of TeamTypes which can be assigned to this at any one time is controlled by the MinimumAIDefensiveTeams= and MaximumAIDefensiveTeams= statements in RULES.INI (see the RULES.INI Guide). TIP: A TeamType which has IsBaseDefense= set to 'yes' will also rush to the aid of any units owned by the same House= which have ToProtect=yes set (the only examples of this in Red Alert 2 are the Ore Miners).
OnlyTargetHouseEnemy=
Can be set to 'yes' or 'no' and determines whether or not members of the associated TaskForce will also attack 'neutral' units (e.g. civilians or other objects belonging to a House= with Side=Neutral set) and consider such objects in its threat scan.
Script=
The unique identifier name used to determine the ScriptType to use for this TeamType and should also be contained in the [ScriptTypes]list and have its own section defined.
TaskForce=
The unique identifier name used to determine the TaskForce to use for this TeamType and should also be contained in the [TaskForces]list and have its own section defined.
[AITriggerTypes]
This section defines which of the TeamTypes should automatically be created in response to specific game events or other triggers in the game. Most of these are created by the AI in an attempt to ensure that it always deals with certain things, for example 'its a good idea to destroy an enemy Nuke Silo' or 'it would be good to capture or destroy the enemy Construction Yard'. In effect, this section is the very essence of the scripted AI.
This section also constitutes the full list of 'global' AI triggers used by the computer in single and multiplayer games. Individual map files can indicate whether or not this list should be used with use of the IgnoreGlobalAITriggers= statement in their [Basic] section (setting that to 'yes' means this list will not be used in games played on that map) and can also define their own AI triggers to be used only in games played on that map by including their own [AITriggerTypes] section which simply appends the new ones to the end of this list. Additionally, map files can also specify which of these triggers should be used in games played on that map on an individual basis with use of the [AITriggerTypesEnable] section which effectively allows each individual trigger to be enabled or disabled - this is used in Red Alert 2, for example, to ensure the AI makes use of Naval type attack forces on maps which have a high water content and does not try to attack with ground based units. See the Map Editing Guide for more details.
The section simply forms a list of each AITriggerType and in a break with convention it is not numbered and each entry contains its own data. Note that this may partly be due to the fact that individual AITriggerTypes listed here can each be enabled or disabled through map files (see the Map Editing Guide) so for example, the computer will not waste time and resources building a TeamType specifically to capture your Construction Yard if you can't even acquire one in the mission.
Each entry takes the following format;-
[ID]= A,B,C,D,E,F,G,XX.000000,YY.000000,ZZ.000000,X1,Y,X2,Z,H,D1,D2,D3
[ID]
Takes the form of a hexadecimal numbered string which is the unique identifier for this AITriggerType. DO NOT change this as the [AITriggerTypesEnable] section in most map files depends upon these values in order to enable/disable this particular AITriggerType as required. If you want to add or modify one, copy an existing one and add it to the end of the list with a new ID.
A = Name
This is simply a string name used for identification purposes only. In this section, you should leave this in.
B = TeamType
Determines which of the TeamTypes should be used for the actions associated with this trigger. If a TeamType is not required then this should be set to <none>.
C = Owner
Determines which House or Country is associated with using this trigger. This is to ensure, for example, that Soviet armies do not use TeamTypes containing Allied units and vice versa as this serves as an override to the Owner= statement for each object in RULES.INI. You should set this to <all> if it pertains to no particular or specific House=.
D = TechLevel
Determines the TechLevel= setting which is required in order for this trigger to be used. Although the TechLevel= setting is partly useless to human players in Red Alert 2, this is used by the AI when it assembles TaskForces. The trigger will only be used when the AI has reached this TechLevel= setting through construction of the required structures in its tech tree - setting this value below that required for a particular unit can often lead to the AI using units for which it has not met the Prerequisite= requirements. It is best to set this to at least the setting required to build any units in the associated TaskForce(s).
E = AITriggerType
Holds the type of AI trigger. This holds values between 0 - 7 with '-1' representing a special case for 'pool' teams.
-1 AI pool team trigger (autocreated thus not attached to the AIGenerals)
0 trigger when enemy owns the Unit Type or Tech Type (min quantity specified by parameter AABBCCDD)
1 trigger when computer owns the Unit Type or Tech Type (min quantity specified by parameter AABBCCDD)
2 trigger when enemy has low power (power is in Yellow)
3 trigger when enemy has low power (power is in Red)
4 trigger based on number of Credits held by enemy (min quantity specified by parameter AABBCCDD)
5 trigger when Iron Curtain is charged to amount specified by AIMinorSuperReadyPercent= in RULES.INI
6 trigger when Chronosphere is charged to amount specified by AIMinorSuperReadyPercent= in RULES.INI
7 trigger when neutral owns the Unit Type or Tech Type (min quantity specified by parameter AABBCCDD)
TIP: Use AI Trigger Type number 4 to fire triggers based on the number of credits held by the player - this will add to the 'unpredictability' of the AI as it wont be creating a TeamType based on the existence of something else. This will also allow you to target the player with most money (usually a sign of 'turtling') in which case destroying/capturing their refineries and hunting their Ore Miners as well as capturing Oil Derricks make good strategies for the AI. In Yuri's Revenge, this also makes a useful trigger for launching AI attacks with Floating Disks against Refineries.
F = Tech Type
Determines which object in the game will cause the AI to use this trigger. Should be any object from the [BuildingTypes],[InfantryTypes],[VehicleTypes] or [AircraftTypes]lists from RULES.INI. If the trigger is not fired based on a unit or tech type, <none> should be used instead (one example is for the creation of 'pool' teams). TIP: If you want the AI to defend against a tank rush, make the trigger fire upon the existence of the enemy Weapons Factory rather than the tanks themselves - this means the AI will have its defense ready by the time the tanks hit it.
G
Determines what to do in response to the unit or tech type defined in parameter 'F' (above). Takes the following format;-
AABBCCDD-EEFFGGHH-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
• AABBCCDD holds a number (represented by 4 hex bytes, in reverse) for each subsequently specified condition that must be satisfied for the trigger to be fired.
• EEFFGGHH holds a value between 0 and 5 and fires the trigger in response to one of the following condition types;-
• 5 = fire the trigger if not equal to
• 4 = fire the trigger if greater than
• 3 = fire the trigger if greater than or equal to
• 2 = fire the trigger if equal to
• 1 = fire the trigger if less than or equal to
• 0 = fire the trigger if less than
If both numbers are set to '00000000', this signifies the creation of a 'pool' type team (see below).
The long string of numbers represented by X's are usually all set to '0' - no exceptions to this have been observed and their use or significance has not been established.
XX.000000 = Weighted Probability
This determines the percentage probability that this AITriggerType will be used so that a weighted distribution of triggers is employed rather than all of them being executed one at a time as if in a list. High values such as 5000.000000 are used to ensure absolute certainty. The 'predictability' of the Red Alert 2 AI is due partly to the fact that the same values (10, 20, 40, 50, 70, 500, 5000) are usually employed throughout the triggers.
YY.000000 = Minimum Weighted Probability
This determines the minimum percentage probability that this AITriggerType will be used when amended by the AI Trigger Weighting Parameters in RULES.INI so that a weighted distribution of triggers is employed rather than all of them being executed one at a time as if in a list. High values such as 5000.000000 are used to ensure absolute certainty. The 'predictability' of the Red Alert 2 AI is due partly to the fact that the same values (10, 20, 40, 50, 70, 500, 5000) are usually employed throughout the triggers.
ZZ.000000 = Maximum Weighted Probability
This determines the maximum percentage probability that this AITriggerType will be used when amended by the AI Trigger Weighting Parameters in RULES.INI so that a weighted distribution of triggers is employed rather than all of them being executed one at a time as if in a list. High values such as 5000.000000 are used to ensure absolute certainty. The 'predictability' of the Red Alert 2 AI is due partly to the fact that the same values (10, 20, 40, 50, 70, 500, 5000) are usually employed throughout the triggers.
X1 = Skirmish Availability Flag
This should be set to '1' if the trigger is to be made available to the computer in skirmish mode and '0' if not.
Y = Not Known
Unknown but is always set to '0'. Possibly used to associate this trigger with a specific AI General although this is difficult to substantiate (see the [AIGenerals] section of the RULES.INI Guide for more details).
X2 = Side Ownership
This value is what gives ownership of the trigger itself to a particular Side=, since several Houses= could belong to the same Side=. This is what enables generic scripts to be used, for example any Soviet army to create Dogs to guard against Spies rather than, say, just Russia. This value should be set to 1 if this AITriggerType applies to an Allied army, '2' if it applies to a Soviet army and '3' if it applies to a Yuri army (in Yuri's Revenge only). TIP: Setting this parameter to '0' allows any AI controlled House= or Side= to use this trigger, regardless of the Owner= setting on the units in the TeamType, meaning that any AI player could use the same trigger in the game.
Z = Base Defense Flag
This should be set to '1' if the trigger is used for AI base defense and '0' if not. Helps the AI to decide what to do when it adopts a specific behaviour dictated by the AIGenerals (see the RULES.INI Guide) and also means the AI will create the associated TeamType even if it has not yet chosen an enemy. This is also attached to the UseMinDefenseRule= tag (see the RULES.INI Guide).
H = Support TeamType
This is what gives the AI some degree of 'smartness' - if the AI simply used the AITriggerTypes without this, it would appear to be boring and predictable as all it would effectively be doing is sending a series of attacks at the players 'list fashion'. This second TeamType is used if, for whatever reason, the first TeamType comes under attack or is otherwise deemed as being likely to fail its associated ScriptType. In that instance, this second TeamType is despatched to support the first, either by eliminating the threat to it or by attacking something else in a bid to create a distraction. This second TeamType is sometimes despatched prior to the first - for example the second TeamType could be instructed to destroy any AA defenses prior to the first being an air-ground assault. This is a much under-utilized feature which allows for the possibility of combined assaults on players. TIP: If you have a TeamType which is performing a 'rush', give it a support TeamType which can deal with any Aircraft or Base Defenses which may pose a threat to it thus rendering it useless.
D1 = Difficulty #1
Flag which should be set to 1 or 0 and indicates if this AITriggerType can be used on the easiest (or Easy) skill level setting in the game.
D2 = Difficulty #2
Flag which should be set to 1 or 0 and indicates if this AITriggerType can be used on the medium (or Normal) skill level setting in the game.
D2 - Difficulty #3
Flag which should be set to 1 or 0 and represents of this AITriggerType can be used on the hardest (or Brutal) skill level setting in the game.
• A Note On AI Pool Teams
Its worth noting that the AI is frequently triggered to create 'pool' teams. These are teams which tend to be created based on time rather than any specific event (although some pool teams are still triggered for creation by events) - this is done automatically in skirmish mode by the 'autocreate' process with the frequency of this being controlled by the TeamDelays= statement in RULES.INI (see the RULES.INI Guide). The members of these teams usually assume some default behaviour such as guarding the AI's base, and the main reason for their creation is simply to make units available for the AI so that it doesn't play the game in a scripted, linear fashion. Use of pool teams also ensures that, for example, the AI always has something with which to defend its base or guard its Ore Miners.
Members of teams created as pool teams are also used to fill other teams (in other words they are 'recruitable') so that the AI does not always have to build every team from scratch. Whilst awaiting recruitment, the pool teams assume a default behaviour (usually defense) until any or all of their members individually or collectively are recruited to join another AI team that has a specific script to perform, although some members may never be recruited into another team.
For those reasons, it is always well worth ensuring that you have the AI create quite a few pool teams, otherwise you will find its actions slow and infrequent as it will have to build almost every team from scratch.
TIP: its well worth putting pool teams into a default mission of 'Guard' rather than 'Guard Area', as teams in a 'Guard Area' mission are not recruited 'from the field' when making new teams (see the note above under the relevant script action). This will also speed the game up a little as 'Guard' requires less processor time than 'Guard Area'. Exploit the autocreation of 'pool' teams - you don't have to put these teams into a generic mission such as base defense - you could, for example, make an autocreated pool team that simply attacks the enemies Construction Yard or hunts enemy Ore Miners. The autocreate process for pool teams means that the AI will always conduct such attacks at regular intervals with the pool team you have defined.
NOT RECOMMENEDED TO USE FOR BEGINNERS IF YOU ARE A BEGINNER USE THE AI EDITING TOOL.
Red Alert 2 AI.INI Guide
Sections Covered
• [TaskForces]
• [ScriptTypes]
• A Note On Structure Numbers
• [TeamTypes]
• [AITriggerTypes]
• A Note On AI Pool Teams
• Some Tips On Making A Better AI
This file controls the Artificial Intelligence employed by the game engine when it assumes the role of a computer controlled player. Red Alert 2 utilizes 'scripted' AI (that is, a system based on pre-determined actions and scripts rather than a 'heuristic' system, i.e. one which intelligently responds to player actions and attempts to forecast future player actions by recording a log of previous ones in a bid to nullify them thus giving itself a tactical advantage).
An attempt has been made to give the impression of heuristics in Red Alert 2 by implementing a success/failure delta system, where the computer keeps a record of instances where previous scripts were or were not successfully executed to completion, thus influencing the likelihood of them being used again. See the AI Trigger Weighting Parameters section in the RULES.INI Guide for details of these deltas.
TIP: to get more out of the AI and to make more effective use of the changes you make to this file, I recommend referring to the [AIGenerals] section (see the RULES.INI Guide). That section provides an ideal way to define specific overall playing styles and strategies for the AI - use of that technique will ensure that the AI relies less on simply playing the game in the same continual scripted manner regardless of the state of the battle and how its doing.
AI.INI is perhaps the least modified file but one which provides immense scope for mod writers as it allows customization through the game engine 'scripting' language in a similar manner to map files. The file contains the scripts which make the computer controlled armies function, and these are in addition to any supplementary scripts that may be contained within specific map files. Production and replacement of units, their generic behavioural characteristics as well as the specific missions that those units will go on are all controlled through this file.
In simple terms, the scripted system works like this;-
• The computer uses objects, or groups of objects, known as TaskForces...
• ...whose generic behaviour and unique properties are controlled by allocating them to TeamTypes...
• ...to carry out an action, or series of actions, controlled by ScriptTypes...
• ...which may or may not be triggered by predefined game events known as AITriggerTypes.
It should be noted that the AI.INI file provides great scope for modification in Red Alert 2. This is for several reasons - if you take a look through the file, it becomes clear that the computer is instructed to prioritize only certain types of attacks, only to use certain units (some are not used), and heavily favors ground based attacks (naval units are seldom used). Primarily however, the computer initially relied upon heavy ground assaults to overwhelm enemies because of the fact that its only enemies were humans, thus would not attack other computer controlled armies before the 1.004 patch. Despite that change however, the AI.INI file remained unmodified, and is less than half the size of than the Tiberian Sun one. NOTE: There is so much of the game engine unused within this file, that time spent on it will be well worthwhile - the Red Alert 2 engine is very powerful and versatile. A lot of this logic is residual from Red Alert and also from the enhancements made by Tiberian Sun - this is one reason why some features do not entirely work correctly in the Red Alert 2 engine.
To say that the AI in Red Alert 2 is poor is very wrong - as you will see, it is merely incredibly under utilized. You will be amazed at what is possible with a little time and effort. Note that to unleash the full potential of the AI, it is well worth studying the AI specific statements in RULES.INI too which offer a high degree of control of the generic AI behaviours - see the RULES.INI Guide. Editing the AI.INI file is not for the faint hearted, and I would suggest that you need a good command of the other INI files (particularly RULES.INI and map files) before embarking upon this!
NOTE: the use of '-G'as a suffix to the numbers throughout this file indicates that this is a 'global' value, meaning it will be used throughout the game regardless of any other conditions placed upon its use. In this case, duplicate use of the same number for the same purpose (for example on two different ScriptTypes or TaskForces) either in this file or within a map file will lead to an Internal Error. This means that you can call any of the TeamTypes, TaskForces or ScriptTypes defined in the AI.INI file from a map file without having to define it again in that map file. This is handy if you want to use something that has already been defined in the AI.INI file, thus reducing the size of your map file.
[TaskForces]
This section takes the form of a list of all TaskForces to be used by the computer generically across all games. The list is numbered starting at 0, new ones should be simply added to the end of the list. If you want the computer to make use of new units, or to use more units, then this section is the one to modify. Each entry in the list takes the form of a hexadecimal numbered string which is the unique identifier for each of the TaskForces - like other lists in the INI files, the game code requires that each entry in this list is defined with its own section in this file. For convention, it is wise to stick to this hex numbering system, although any string appears to be parsed.
An example is detailed below;-
[TASKFORCE]
Name=
a=x,UNIT
b=x,UNIT
c=x,UNIT
...
Group=
[TASKFORCE] - this is the unique identifier name used to define the section for this TaskForce and should also be contained in the above mentioned list.
Name= - this is simply a string name used for identification purposes only, it is not required by the game, although it is useful to leave this in for debugging and troubleshooting your AI.INI file - as a point of interest, this statement does not even get parsed.
n=x,UNIT - this is used to define which units are in this TaskForce. This is in the form of a list, and for each different unit you want in your TaskForce, you must have a separate line in the list. Each line consists of a number (how many of the unit) followed by a comma and then the name of that unit from the [BuildingTypes],[InfantryTypes],[VehicleTypes] or [AircraftTypes]lists from RULES.INI. Note that the numbering must start at 0. For example, to define a TaskForce with 5 GI's and 2 Grizzly Tanks, you could use;-
[TASKFORCE]
Name=5 GI's and 2 Grizzly Tanks
0=5,E1
1=2,MTNK
Group=-1
Group= - defines the default grouping for the units in this TaskForce which is therefore used when it has executed (or does not have) a ScriptType. This is over-ridden by the Group= setting in the associated TeamType. The following values can be used;-
-1 Lose Transports - any transports are dissolved
?? Lose Units, Lose Transports - all units dissolved
?? Keep Units, Keep Transports - all units retained
?? Lose Units, Keep Transports - only transports retained
?? Keep Units Farthest - only units furthest away are retained
?? Keep Units Nearest - only nearest units are retained
?? Greatest Threat - group together at object posing greatest threat
-40094 Least Threat - group together at object posing least threat
[ScriptTypes]
This section takes the form of a list of all ScriptTypes which can be used by TaskForces. The list is numbered starting at 0, new ones should be simply added to the end of the list. Each entry in the list takes the form of a hexadecimal numbered string which is the unique identifier for each of the ScriptTypes - like other lists in the INI files, the game code requires that each entry in this list is defined with its own section in this file. For convention, it is wise to stick to this hex numbering system although again this is not strictly necessary. The section entries describe what the TaskForce is going to do and consists of a list of action codes.
An example is detailed below;-
[SCRIPT]
Name=
a=x,y
b=x,y
c=x,y
...
[SCRIPT] - this is the unique identifier name used to define the section for this ScriptType and should also be contained in the above list.
Name= - this is simply a string name used for identification purposes only, it is not required by the game, although it is useful to leave this in for debugging and troubleshooting your AI.INI file - as a point of interest, this statement does not even get parsed.
n=x,y - this defines the action to be performed by the TaskForce to which this ScriptType is allocated. This takes the form of a list, and for each action you want the TaskForce to perform, you should have a new line in your script. Think of this like writing a computer program - for everything you want the computer to do, you add a new line to your program - its the same idea here. Again, by convention, the numbering must begin at 0. These scripts can become very complex and powerful tools, and provide one of the ultimate levels of editing potential in the game.
The first value, x, contains the action to perform. Some actions require a parameter, y, which provides information for the action - they mean different things for different actions. Here's an example of a script, the first line tells the computer to attack any enemy vehicles, and the second line tells the computer to attack anything when its finished the first line (i.e. after it has destroyed one vehicle);-
[SCRIPT]
Name=Attack any vehicle then attack anything
0=0,5
1=0,1
Here's a list of the script actions and their respective parameters (where appropriate);-
0,n = Attack Target Type, n = target type to attack
This instructs the TeamType to use the TaskForce to approach and attack the target specified by the second parameter. The following are the target types which can be used;-
0 N/A cancel attack mission
1 Anything anything (usually the first enemy object they encounter) - utilizes threat rating logic
2 Structures any enemy [BuildingTypes]
3 Ore Miners any enemy [VehicleTypes] with Harvester=yes set
4 Infantry any enemy [InfantryTypes]
5 Vehicles any enemy [VehicleTypes]
6 Factories any enemy [BuildingTypes] with a Factory= setting
7 Base Defenses any enemy [BuildingTypes] with IsBaseDefense=yes set
8 Base Threats any enemy objects approaching (or already in) its base and which are in an attack mission
9 Power Plants any enemy [BuildingTypes] with positive Power= values set
10 Occupiable any [BuildingTypes] with CanBeOccupied=yes set (usually neutral structures)
11 Tech Buildings any [BuildingTypes] with NeedsEngineer=yes set (usually NeutralTechBuildings=)
NOTE: in Yuri's Revenge, Occupiable structures are defined by having CanOccupyFire=yes set instead of CanBeOccupied=yes.
1,n = Attack Waypoint, n = waypoint number to attack
This instructs the TeamType to use the TaskForce to attack the waypoint number specified by the second parameter. If any members have Infiltrate=yes set they will enter the structure at the waypoint. Members with Engineer=yes set will capture the structure provided it does not have Capturable=no set or if it has NeedsEngineer=yes set. Members with Agent=yes set will spy on the structure if it has Spyable=yes set. Members that do not have Assaulter=no set will garrison the structure if it has CanBeOccupied=yes set. Members with C4=yes set will blow up the structure if does not have CanC4=no set. If there is no building at the specified waypoint, the TaskForce will move to the waypoint and will just remain in their last mission. Waypoints are used to define specific places (cells) on the map - see the Map Editing Guide for a detailed explanation of waypoints. At this point however, its worth noting that Red Alert 2 usually assigns waypoint number 98 to define the place where the player starts in single player games (also known as the 'home cell'), waypoint number 99 for the center of the map, and waypoint numbers 0 - 7 to define the starting places for the 8 players.
2,0 = Go Berzerk
Forces infantry units with Cyborg=yes set to go berserk (they consider all objects, including friendly units, equally in their threat scan).
3,n = Move To Waypoint, n = waypoint number to move to
This instructs the TeamType to use the TaskForce to move to the waypoint number specified by the second parameter. Waypoints are used to define specific places (cells) on the map - see the Map Editing Guide for a detailed explanation of waypoints. At this point however, its worth noting that Red Alert 2 usually assigns waypoint number 98 to define the place where the player starts in single player games (also known as the 'home cell'), waypoint number 99 for the center of the map, and waypoint numbers 0 - 7 to define the starting places for the 8 players. TIP: you could use this script action to get a TeamType to move to Waypoint= number 99 (just about every map has this defined as the center point) - that will mean it will always strive to get to the center of the map, providing a good vantage point from which to perform further script actions and giving the impression that the computer is scouting for enemies.
4,n = Move Into Specific Celltag, n = celltag to move into
This instructs the TeamType to use the TaskForce to move into the CellTag specified by the second parameter. This is used when you want the TeamType to trigger a specific Action (when the game tests for the CellTag being entered). CellTags are attached to cells and are used to trigger Events and thus fire Actions when that cell is entered by a unit (or any unit from the TaskForce). The CellTag parameter should be the waypoint parameter for that CellTag from the [CellTags]listing in the map file, hence this script action is only of use on specific map files. See the Map Editing Guide for a detailed explanation of CellTags and their use.
5,n = Guard Area, n = time to guard area in tenths of a minute (multiples of 6 seconds)
This instructs the TeamType to put the TaskForce into Guard Mode (same effect as selecting a group of units and pressing the Guard Mode key as defined in KEYBOARD.INI or clicking the relevant button on the Advanced Command Bar). Units will move to attack enemy units that fall within their Sight= range.
6,n = Jump To Script Action, n = number of script action to jump to
This is used to repeat actions within the ScriptType. The second parameter is the action number of the ScriptType that you want to jump to. Remember that the first action of a ScriptType is numbered 0 so if you jump to this (by using n=6,0 for example) you get the TaskForce to repeat all the commands it has, looping forever. This is used by the waypoint system in the game for setting up patrols. You don't have to repeat all the actions as you could jump to say action 3, which would ignore the first three action commands (remember, the numbering starts at 0) and just go to the fourth.
7,0 = Force Player Win
Forces a game win condition for the owner of the TeamType (they win the game).
8,n = Unload, n = type of unloading
If the TaskForce contains a unit or units that have a valid Passengers= value set, and those units contain passengers, this command will make the units inside the transport(s) disembark. Note that once the passengers have disembarked, the transport itself is suspended until given a new mission and is therefore no longer considered a part of this TaskForce - this means that you cannot, for example, get units to disembark, do something, then get back into the transport in the same script. The second parameter can be used to control what happens to the transport after it 'deploys' its cargo;-
0 Keep transports and units - all remain in the team and execute the remainder of the script
1 Keep transport and lose the units - only the transport will execute the remainder of the script
2 Lose transport and keep units - only the units will execute the remainder of the script
3 Lose transports and lose units - nothing executes the remainder of the script
9,0 = Deploy
If the TaskForce contains a unit or units that are able to deploy (for example a unit which DeploysInto= a [BuildingType] or has any of Deployer=yes, DeployFire=yes, DeployToFire=yes set) then this action causes them to deploy at the current cell they are occupying (same effect as selecting a unit and pressing the Deploy key as defined in KEYBOARD.INI or clicking the relevant button on the Advanced Command Bar).
10,0 = Follow friendlies
This command causes the TaskForce to follow the nearest friendly unit when it moves although it will not function as if it is 'guarding' the unit. The following is not permanent, when the TaskForce is assigned another mission it abandons the following. TIP: If the support TeamType has this as the first line in its ScriptType, then it will escort the first TeamType.
11,n = Assign New Mission, n = new mission type
The objects in the TaskForce are all assigned the new mission defined by the second parameter. Not all of them work, some are made obsolete by other action commands, some do not work because an object in the TaskForce may not support that action. Because these are the same 'behaviours' to which objects can be assigned when initially placed on the map some apply only to structures. The following are valid settings for the second parameter, you should refer to the Mission Control section of the RULES.INI Guide for a more detailed explanation of the missions and how they work;-
0 Sleep object sits around and plays dead, will not acquire targets
1 Attack special attack mission used by AI team types (utilizes threat rating logic)
2 Move simply moving to destination
3 QMove special move to destination after other queued moves occur
4 Retreat object runs away (may even leave the map)
5 Guard object sits around and will engage an enemy that falls within its weapon range
6 Sticky just like guard mode, except the object will engage enemies but not pursue them
7 Enter enter building or transport
8 Capture engineer entry logic used by MultiEngineer
9 Eaten when object is being repaired (applies only to structures)
10 Harvest the loop controlling harvesting of Ore and dumping at a Refinery
11 Area Guard guard the general area where the object starts at
12 Return return to co-ordinating object (e.g. spawned object returns to the spawner)
13 Stop stop moving or firing at the first available opportunity
14 Ambush force fire (units with Infiltrate=yes will enter target if possible)
15 Hunt scan for and attack enemies wherever they may be on the map
16 Unload while dropping off cargo (e.g. Landing Craft unloading passengers)
17 Sabotage unit runs to place C4 on a building or Ivan goes to place bomb on object
18 Construction structures use this when building up after initial placement
19 Selling structures use this for deconstruction after being sold
20 Repair used when repairing an object (e.g. Service Depot)
21 Rescue special team over-ride mission
22 Missile Nuke Silo special launch missile mission
23 Harmless object doesn't fire and is not considered in any threat scan
24 Open while opening or closing a gate to allow passage
25 Patrol patrol a series of waypoints
26 Paradrop Approachobject is approaching the paradrop site
27 Paradrop Overfly object is flying over the paradrop site (i.e. dropping the paratroopers)
28 Wait paused and awaiting next mission
29 Move (special duplicate) used when Chrono units are moving to destination
30 Attack (special duplicate) used when units are deployed to fire (e.g. weapons with an area fire effect)
31 Spyplane Approachobject is flying towards target (YR)
32 Spyplane Overfly object is flying over the target (YR)
NOTE: there is a difference when using Area Guard as opposed to Guard. Units with an Area Guard mission are more aggressive and will pursue enemy units that fall within their Sight= range and continue that pursuit until they can attack the target. Then the units will return to their original position unless they catch the target within their initial guard zone (in which case they will attempt to destroy it). Units in an Area Guard mission are not recruited 'from the field' when a create team Action is executed, although units in a standard Guard mission will be gathered to create the new team if they are required.
12,n = Set Global, n = global number to be set
The global number specified in the second parameter is defined as being 'set' (it is allocated a value of '1' or 'true'). This should be employed in specific map files only. This is part of the boolean logic employed by the global variables system in the game engine - refer to the Map Editing Guide for a more detailed explanation of global and local variables. The Global Variables are defined in RULES.INI - see the RULES.INI Guide.
13,n = Play Idle Anim Sequence, n = sequence number
If the TaskForce contains a unit or units that are SHPs (i.e. infantry) then the relevant idle SHP sequence is displayed as defined by the frame numbering system in ART.INI.
14,0 = Load Onto Transport
If the TaskForce contains a unit or units that have a valid Passengers= value set, and units whose Size= and PhysicalSize= settings allow them to be carried by that transport, this command will make the units enter the transport.
15,n = Spy On Structure At Waypoint, n = waypoint number
Should be used only for units with Infiltrate=yes and Agent=yes set. This instructs the TaskForce to enter the structure at the waypoint number specified by the second parameter and spy on the structure if it has Spyable=yes set. If there is no building at the specified waypoint, the TaskForce may not activate correctly and will just remain in their last mission. Waypoints are used to define specific places (cells) on the map - see the Map Editing Guide for a detailed explanation of waypoints. At this point however, its worth noting that Red Alert 2 usually assigns waypoint number 98 to define the place where the player starts in single player games (also known as the 'home cell'), waypoint number 99 for the center of the map, and waypoint numbers 0 - 7 to define the starting places for the 8 players.
16,n = Patrol to waypoint, n = waypoint number
This is similar to Move to waypoint. This instructs the TeamType to use the TaskForce to move to the waypoint number specified by the second parameter. The difference is that the units in the TaskForce will move out of their patrol route to actively go and engage any enemy objects that are within their Sight= as they move to the waypoint. NOTE: this action eats up processor time, because the TaskForce will scan for enemy objects with each movement. If you have a lot of TaskForces (or lots of units in them) engaged in this action, you will experience slowdown in the game - this is one reason why the single player missions are comparatively slow, they use this action a lot. The rate at which the scanning for targets whilst in this mission is controlled by the PatrolScan= statement in the [AI]section of RULES.INI (see the RULES.INI Guide). Waypoints are used to define specific places (cells) on the map - see the Map Editing Guide for a detailed explanation of waypoints. At this point however, its worth noting that Red Alert 2 usually assigns waypoint number 98 to define the place where the player starts in single player games (also known as the 'home cell'), waypoint number 99 for the center of the map, and waypoint numbers 0 - 7 to define the starting places for the 8 players.
17,n = Change Script, n = script number to execute
Very handy and under utilized - this instructs the TaskForce to execute another ScriptType. The second parameter specifies the number of the ScriptType to execute as listed in the [ScriptTypes]table (consider the table as being numbered starting at 0 for this purpose).
18,n = Change Team, n = team number to join
This instructs the TaskForce to join another TeamType. The second parameter specifies the number of the TeamType to join as listed in the [TeamTypes]table (consider the table as being numbered starting at 0 for this purpose).
19,0 = Panic
If the TaskForce contains a unit or units that have Fraidycat=yes set then they will run around aimlessly, using the Panic= animation from their sequence as defined in ART.INI. Normally used for the civilian units. Units that do not fulfil this criteria lie down and act as if prone.
20,n = Change House Ownership, n = house number of new owner
Used in single player missions on specific map files only, this changes ownership of the entire TeamType to the House= number specified by the second parameter. See the Map Editing Guide for details of [Houses] and their numbering.
21,0 = Scatter
This instructs the TaskForce to scatter (same effect as selecting a group of units and pressing the Scatter key as defined in KEYBOARD.INI).
22,0 = Afraid & Run To Shroud
This instructs the TaskForce to behave in a scared manner and it will run to the nearest shrouded cell. The TaskForce will not actively engage in combat, will not acquire targets and will not retaliate (it will scatter instead if attacked).
23,0 = Force Player Loss
Forces a game loss condition for the owner of the TeamType (they lose the game).
24,n = Play Speech From EVA.INI, n = number of speech to play
This instructs the TaskForce to play one of the Sofia or EVA voices (depending upon the ParentCountry= or the owner of this TaskForce). The second parameter is the number of the sound to be played from the [DialogList] in the EVA.INI file (note that you should consider this list as being numbered from 0 instead of 1 to get the correct numbering convention).
25,n = Play Sound From SOUND.INI, n = number of sound to play
This instructs the TaskForce to play one of the generic in game sounds from the [SoundList] in the SOUND.INI file (note that for all in game Action and Trigger purposes this number is from an internal table - see the Map Editing Guide).
26,n = Play Movie
This instructs the TaskForce to play one of the movies from the [Movies] list in the ART.INI file (note that for all in game Action and Trigger purposes this number is from an internal table - see the Map Editing Guide).
27,n = Play Theme From THEME.INI, n = number of theme to play
This instructs the TaskForce to play one of the game soundtracks from the [Themes] list in the THEME.INI file (note that for all in game Action and Trigger purposes this number is from an internal table - see the Map Editing Guide).
28,0 = Reduce Ore
Reduces the amount of Ore in the cell that the TeamType is occupying. Used by the special 'weapon' that is inherent with Ore Miners.
29,0 = Begin Production
Forces the owner of the TeamType to begin the auto-production process (the AI's behaviour in skirmish games). Should only be used on AI controlled houses.
30,0 = Force Sale
Forces the 'fire sale' of all remaining structures owned by the House= to which the TeamType belongs.
31,0 = Suicide
This instructs the TaskForce to destroy itself. In effect it commits suicide, usually accompanied by an explosion.
32,n = Start Weather Storm In...
This initiates the Weather Storm intro effect (when the screen goes dark prior to the clouds appearing) and is set to be delayed by the number of seconds specified by parameter 2.
33,0 = End Weather Storm
This forces an end to the Weather Storm intro effect (when the screen goes dark prior to the clouds appearing).
34,n = Center Map On Team
This will center the screen on the TeamType. The same effect as hitting the Home key as defined in KEYBOARD.INI when the screen centers on your MCV (or the unit defined by the BaseUnit= statement in RULES.INI). The second parameter determines the speed at which the 'camera' switches view to the TaskForce with 0 being instant.
35,n = Shroud Map For Time Interval, n = time to remain shrouded
This action will shroud the entire map except for the area around the players MCV's (if they have one). The second parameter determines the number of frames for which the map should remain shrouded (1 second = approximately 15 frames) after which the explored areas are revealed again.
36,n = Reveal Map For Time Interval, n = time to remain revealed
This action will reveal the entire map. The second parameter determines the number of frames for which the map should remain revealed (1 second = approximately 15 frames) after which the map is shrouded again.
37,0 = Delete Team Members
This forces dissolved members of the TaskForce to leave the map after which they are deleted (for example aerial transports after their passengers have disembarked).
38,n = Clear Global, n = Global number to be cleared
The global number specified in the second parameter is defined as being 'clear' (it is allocated a value of '0' or 'false'). This should be employed in specific map files only in which the global variable has been defined. This is part of the boolean logic employed by the global variables system in the game engine - refer to the Map Editing Guide for a more detailed explanation of global and local variables. The Global Variables are defined in RULES.INI - see the RULES.INI Guide.
39,n = Set Local, n = Local number to be set
The local variable number specified in the second parameter is defined as being 'set' (it is allocated a value of '1' or 'true'). This should be employed in specific map files only in which the local variable has been defined. This is part of the boolean logic employed by the local variables system in the game engine - refer to the Map Editing Guide for a more detailed explanation of local and global variables.
40,n = Clear Local, n = Local number to be cleared
The local variable number specified in the second parameter is defined as being 'cleared' (it is allocated a value of '0' or 'false'). This should be employed in specific map files only in which the local variable has been defined. This is part of the boolean logic employed by the local variables system in the game engine - refer to the Map Editing Guide for a more detailed explanation of local and global variables.
41,n = Unpanic
If the TaskForce contains a unit or units that have Fraidycat=yes set which are currently assigned the Panic= mission then this action nullifies that effect and the unit(s) adopt their default behaviour.
42,n = Change Facing, n = new direction to face
This instructs the TaskForce to turn and face the new direction specified by the second parameter. The facings are as follows;-
0 North
1 North East
2 East
3 South East
4 South
5 South West
6 West
7 North West
43,0 = Wait Until Fully Loaded
This is always used after members of the TaskForce have entered a transport in the same TaskForce and serves two purposes. The effect of this is that the transport will be used to carry out any subsequent movement or deploy actions but after that it is no longer considered a part of this TaskForce and as such is available to be recruited into new TeamTypes. It is this action which enables use of the TransportsReturnOnUnload=yes statement in the corresponding TeamType entry. The second purpose is to flag the transport as being 'loaded' with passengers and thus is considered in the AI's targeting logic as a potential threat (see the ContentScan= entry in the RULES.INI Guide). This action also orders the transport to wait until it is fully loaded before executing any subsequent script actions.
44,0 = Unload TRUCKB > TRUCKA
Used purely for a graphical effect and applicable uniquely to the [TRUCKB] unit, this has the effect of converting [TRUCKB] into [TRUCKA] to give the impression that the unit has unloaded its cargo. NOTE: this is residual from Tiberian Sun and as such may not work correctly since [TRUCKA] refers to the Demo Truck image in Red Alert 2 which has no 'unloaded' image. Changing the image for the Demo Truck and assigning new units to [TRUCKA] and [TRUCKB] enables use of this logic.
45,0 = Load TRUCKA > TRUCKB
Used purely for a graphical effect and applicable uniquely to the [TRUCKA] unit, this has the effect of converting [TRUCKA] into [TRUCKB]to give the impression that the unit has been loaded with cargo. NOTE: this is residual from Tiberian Sun and as such may not work correctly since [TRUCKA] refers to the Demo Truck image in Red Alert 2 which has no 'unloaded' image. Changing the image for the Demo Truck and assigning new units to [TRUCKA] and [TRUCKB] enables use of this logic.
46,n = Attack Enemy Structure, n = structure number (see note below)
Members of this TaskForce attack the enemy structure specified by the second parameter. This action depends upon the type of units in the TaskForce and if certain members have Infiltrate=yes set. Members with Engineer=yes set will capture the structure provided it does not have Capturable=no set or if it has NeedsEngineer=yes set. Members with Agent=yes set will spy on the structure if it has Spyable=yes set. Members that do not have Assaulter=no set will garrison the structure if it has CanBeOccupied=yes set. Members with C4=yes set will blow up the structure if does not have CanC4=no set.
47,n = Move To Enemy Structure, n = structure number (see note below)
Members of this TaskForce move and stay adjacent to the enemy structure specified by the second parameter.
48,0 = Scout
Causes members of this TaskForce to move to a pre-determined point on the map in an attempt to scout an area. The effect is that the TaskForce will move in one randomly chosen direction until it is no longer able to do so which can make it very useful or a waste of time depending on the direction chosen. If you want to continually scout the map, you should loop this script action.
49,0 = Repeat Until Success
This is typically used after an Attack Target instruction. This forces the TaskForce to carry out its previous action in the script continually until all of the target types specified by that previous instruction no longer exist, at which point the TaskForce moves on to the next instruction after this one. The action is continually executed until any condition on its use can no longer be met (for example if the previous action was Attack Vehicles and all vehicles have been destroyed, the script moves on to the next action). In other words, this can be used to set a 'success' condition on the script.
50,n = Flash (visual effect), n = number of flashes
This causes the TaskForce to 'flash', the visual effect you get on an object when you order something to attack it. The second parameter is the number of times to flash the unit 'white'.
51,n= Play Animation, n = animation number
This instructs the TaskForce to play one of the animations from the [Animations] in the RULES.INI.INI file (note that for all in game Action and Trigger purposes this number is from an internal table - see the Map Editing Guide).
52,n = Display Talk Bubble, n = talk bubble number
Should be used for single-unit TaskForces only, this causes a 'talk bubble' to appear above the unit. The second parameter determines which type of talk bubble to display;-
1 * general speech
2 ? question
3 ! shouting or statement
Note that the length of time for which the talk bubble is displayed is controlled through the TalkBubbleTime= statement in RULES.INI - refer to the RULES.INI Guide for details of this and the steps to take to enable its inclusion in Red Alert 2 as this remains residual from Tiberian Sun:Firestorm.
53,0 = Gather (at enemy base)
This causes the TaskForce to gather together (sometimes used when members of the TaskForce move at different speeds and you want the faster ones to stop while the slower ones catch up) after the previous action has been executed. If the TaskForce is in an attack mission and moving towards an enemy base, this command is usually executed when the first member of the TaskForce reaches the distance from that base defined by the AISafeDistance= statement in RULES.INI - see the RULES.INI Guide.
54,0 = Regroup (at friendly base)
This causes the TaskForce to regroup, if for example any of its members have become engaged in a base defense mission or strayed away whilst in guard mode, or even the TeamType itself has been suspended for whatever reason. The members regroup directly next to each other leaving no 'gaps' at the nearest available point with sufficient space, and is used, for example, prior to activating the Iron Curtain so that all applicable members are affected (i.e. they fall within its range of effect).
55,0 = Activate Iron Curtain on TaskForce
If the owner of the TaskForce to which this ScriptType is attached also has the Iron Curtain fully charged then it will be fired at this TaskForce. Note that the use of the Iron Curtain in this manner depends on the percentage chance of the AI incorporating them into its actions as defined by the AIMinorSuperReadyPercent= statement in RULES.INI - see the RULES.INI Guide for more details.
56,n = ChronoSphere TaskForce, n = structure number to be Chronoshifted to (see note below)
If the owner of the TaskForce to which this ScriptType is attached also has the Chronosphere fully charged then it will be used on the TaskForce before moving on to the next action. Note that the use of the Chronosphere in this manner depends on the percentage chance of the AI incorporating them into its actions as defined by the AIMinorSuperReadyPercent= statement in RULES.INI - see the RULES.INI Guide for more details.
57,n = ChronoWarp TaskForce, n = target number to be Chronoshifted to (see note below)
If the owner of the TaskForce to which this ScriptType is attached has been Chronosphered then it will be used on the same TaskForce to shift them to the enemy structure number specified in the second parameter before moving on to the next action. Note that the use of the Chronosphere in this manner depends on the percentage chance of the AI incorporating them into its actions as defined by the AIMinorSuperReadyPercent= statement in RULES.INI - see the RULES.INI Guide for more details.
58,n = Move To Friendly Structure, n = structure number (see note below)
Members of this TaskForce move and stay adjacent to the friendly structure specified by the second parameter. The structure can be one owned by the owner of the TaskForce or any of its allies.
59,n = Attack Structure At Waypoint (Yuri's Revenge only)
Members of this TaskForce attack the structure at the Waypoint= specified by the second parameter. This action is very similar to action number 43 although this action does not test for ownership of the structure itself - thus the inclusion of this action allows, for example, InfantryTypes with Engineer=yes set to enter structures owned by the same side for the purposes of repair. This would be the most appropriate action to use to get the AI to repair bridges. Use of this also means that the TaskForce will attack the structure with one of its weapons meaning, for example, that units with C4=yes set will not C4 the building but shoot at it instead. This is useful if you want to get a TaskForce to destroy a nearby occupiable structure instead of entering it in a bid to prevent the enemy getting old of it - a tactic used in the Yuri's Revenge AI.
60,0 = Enter Grinder (Yuri's Revenge only)
Members of this TaskForce will enter the nearest structure with Grinding=yes set if it is owned by the owner of the TaskForce or any of its allies.
61,0 = Occupy Tank Bunker (Yuri's Revenge only)
Any VehicleType members of this TaskForce which do not have Bunkerable=no set will enter the nearest vacant structure with Bunker=yes set if it is owned by the owner of the TaskForce or any of its allies.
62,0 = Enter Bio Reactor (Yuri's Revenge only)
Any InfantryType members of this TaskForce will enter the nearest structure with InfantryAbsorb=yes set if it is owned by the owner of the TaskForce or any of its allies and has space available.
63,0 = Occupy Battle Bunker (Yuri's Revenge only)
Any InfantryType members of this TaskForce with Occupier=yes set will enter the nearest structure (which they own) with CanOccupyFire=yes set.
64,0 = Garrison Structure (Yuri's Revenge only)
Any InfantryType members of this TaskForce with Occupier=yes set will enter the nearest (neutral) structure with CanOccupyFire=yes set. This action is used specifically for this purpose due to action #59 (see above) since the logic in Yuri's Revenge has changed so that the units weapon is transferred to the structure. Use of this action also allows the computer to repair those structures by sending an InfantryType with Engineer=yes set into them and also allows the AI to differentiate between attacking such a structure and entering it, which is useful if you want the AI to use infantry to destroy an occupiable structure thus preventing its enemy from using it.
• A Note On Structure Numbers
When used in ScriptTypes, the structure number takes any of several formats and is derived by finding the structure in the [BuildingTypes] list of RULES.INI and subtracting ONE from this structures' number in that list (equivalent to renumbering the list from 0) - this is the explicit number of that structure and is the number to use as the second parameter of the action. Any one of several amendments can be made to this number;-
• add 131072 to the number, so GAPOWR (number 1 in RULES.INI thus number 0 for this purpose) becomes 131072
• add 196608 to the number, so GAPOWR (number 1 in RULES.INI thus number 0 for this purpose) becomes 196608
• add 65534 to the number, so GAPOWR (number 1 in RULES.INI thus number 0 for this purpose) becomes 65534
It has not been determined what significance or effect the different numbering systems have (if any). Changing them at random appears to have no effect although it is thought that there is additional logic attached to them.
[TeamTypes]
This section defines the TeamTypes, which connect a ScriptType with a TaskForce while adding some generic behaviour parameters (ie behaviours which apply to every member of the TaskForce) whether they are how the TeamType is created, or how it behaves after it has been created. These behavioural modifiers make it difficult to entirely predict or determine the TeamTypes behaviour. The maximum number of TeamTypes which can be in existance at any one time is controlled with the TotalAITeamCap= statement in RULES.INI - refer to the RULES.INI Guide for a more detailed explanation of this and many other statements relating to the AI. These can be created in any of several ways;-
• within individual map files by an Action when some pre-determined condition is met by the game code (known as an Event) - see the Map Editing Guide
• when a generic game event occurs that may not be specific to a particular map, scenario or House (known as an AITriggerType, again these can be employed and even defined in individual map files)
• based on time rather than an Event or a Trigger, the TeamType is automatically created and used, known as Autocreate - this process is inherent in the game code in skirmish games with the frequency of this process being controlled by the TeamDelays= statement in RULES.INI (see the RULES.INI Guide). In map files, you must trigger this process yourself through the relevant Action (see the Map Editing Guide).
The section takes the form of a list of all TeamTypes. The list is numbered starting at 0, new ones should be simply added to the end of the list. Each entry in the list takes the form of a hexadecimal numbered string which is the unique identifier for each of the TeamTypes - like other lists in the INI files, the game code requires that each entry in this list is defined with its own section in this file. For convention, it is wise to stick to this hex numbering system although again this is not strictly necessary. The following statements can be used;-
Name=
This is simply a string name used for identification purposes only, it is not required by the game, although it is useful to leave this in for debugging and troubleshooting your AI.INI file - as a point of interest, this statement does not even get parsed.
VeteranLevel=
Is used to determine the level of 'veterancy' that each member of the TaskForce used by this TeamType has. Use 1 for 'Little Experience' (default), 2 for 'Veteran' and 3 for 'Elite'. Higher numbers can be used if you edit RULES.INI - see the Veteran Factors section of the RULES.INI Guide for more details.
(YR) MindControlDecision=
Determines what a member of the associated TaskForce will do if it 'mind controls' its target. This only works if that has been placed in an 'attack' type mission, as it gets over-ridden by other specific script actions. The decisions are;-
0 = nothing (default behaviour) used to indicate that the TeamType should not use this logic
1 = add to AI's side as Recruitable=yes for further teams
2 = send it to a structure with Grinding=yes set for sale (e.g. Grinder) if owned
3 = send it to a structure with InfantryAbsorb=yes and/or UnitAbsorb=yes set (e.g. Bio Reactor) if owned
4 = set object in 'Hunt' mission
5 = do nothing
The percentage chances of each of those actions as well as the parameters used to assist the decision can be customized through the AICaptureNormal=, AICaptureWounded=, AICaptureLowPower=, AICaptureLowMoney=, AICaptureLowMoneyMark=, and AICaptureWoundedMark= statements in RULESMD.INI (see the RULES.INI Guide).
Loadable=
Can be set to 'yes' or 'no' and is used to determine if the associated TaskForce should reload when any of its members run out of Ammo= . This is required in case a particular unit has to dock with a co-ordinating structure to reload, a process which is a mission in itself and thus could interrupt (and possibly cause havoc with) the actions for the TeamType as defined by the associated ScriptType as 'nesting' missions in this manner could cause Internal Errors - objects can only be in one mission at a time. This logic is residual from Red Alert (where it was used primarily for the Mine Layer code) and may be obsolete in Red Alert 2.
Full=
Should be used only in map files, this can be set to 'yes' or 'no' and determines if any units within the associated TaskForce should be initially 'full' as determined by the PipScale= statement in their RULES.INI entry - this applies only to Ore Miners and transport type units in Red Alert 2. If the TaskForce contains a Transport and other units, the units are automatically placed in the Transport for reinforcement purposes.
Annoyance=
Can be set to 'yes' or 'no' and is used to determine if destroyed members of the associated TaskForce are automatically replaced by the AI and allocated the same ScriptType, the supposed effect being that this TeamType annoys the player with its persistence.
GuardSlower=
Can be set to 'yes' or 'no' and has the effect of increasing the default value of BaseDefenseDelay= as defined in RULES.INI specific to this TeamType so that members of the associated TaskForce in a base defense mission take longer to respond to any threats to themselves or any objects they are guarding. The factor by which that value is increased has not been determined.
House=
Should be used within map files and simply defines the House= to which ownership of this TeamType is automatically passed upon creation. For general AI.INI TeamTypes this should be set to <none>. TIP: In Yuri's Revenge, this can be used to refer to multiplayer (including human) houses by specifying individual player houses at any of the 8 starting Waypoints= on the map. For example, to specify the player at the first starting waypoint, you can use House=<Player @ A>. The letters A to H can be used to represent Waypoint= numbers 0 - 7 inclusive, thus it is possible to provide reinforcements to human players in multiplayer games. For map file Trigger, Event and Action purposes, the multiplayer houses are numbered 4475 - 4482, again representing the House= at each of the Waypoints numbered 0 - 7 inclusive.
Recruiter=
Can be set to 'yes' or 'no' and determines if this TeamType can be created by using any objects required to assemble the associated TaskForce that already exist on the map (provided they are not already part of an existing TeamType).
Autocreate=
Can be set to 'yes' or 'no' and specifies whether or not this TeamType should be created based on time rather than any form of trigger. The AI.INI file usually defaults to 'no' - this is because a TeamType with Autocreate=yes set is, obviously, subject to being automatically created. Each House= can, independently, have this function activated through the relevant Action within a map file. As mentioned above, the frequency of this process is controlled by the TeamDelays= statement in RULES.INI (see the RULES.INI Guide).
Prebuild=
Can be set to 'yes' or 'no' and determines if an inactive duplicate of the associated TaskForce should be created before it may be needed. This is used in case the TeamType has a high Priority= setting so that the AI has a backup should the original be destroyed (useful if the TaskForce contains an object which is expensive or takes a long time to produce). This is how the AI can sometimes appear to produce expensive units very quickly in some single player missions.
Reinforce=
Used in map files only for single player missions, this can be set to 'yes' or 'no' and determines if this TeamType forms reinforcements, in other words if set to 'yes' then the TeamType is expected to be created from off the map rather than on it.
Droppod=
Can be set to 'yes' or 'no' and determines if the TaskForce should be delivered by the AircraftType defined by the name [DPOD] in RULES.INI. This is entirely residual from Tiberian Sun (where that unit was simply a placeholder for this purpose which used the Drop Pod Locomotor=) and may be linked to and used by the Paradrop logic in some way by Red Alert 2. The DPOD unit must have Passengers= and SizeLimit= values set accordingly (to allow it to carry the TaskForce) and for this purpose should also have Spawned=yes set. See the relevant entries in the RULES.INI Guide for more details of customizing the Drop Pod effect.
UseTransportOrigin=
Can be set to 'yes' or 'no' and determines whether or not this TeamType should be created at the point of origin of its transport, if the transport itself already exists and has been recruited into this TeamType. This is used in map files to create reinforcement teams from off the map that will arrive on a transport.
Whiner=
Can be set to 'yes' or 'no' and is used only by 'pool' TeamTypes (see AITriggerTypes) to determine if destroyed members of the associated TaskForce are automatically replaced by the AI. This is because 'pool' TeamTypes are normally assigned to base defense missions or generic missions such as guarding, hunting or scouting and their members are always made available for recruitment into further teams (a mechanism which ensures that the AI doesn’t always have to produce every team from scratch since it will have a pool of units from which to assemble future teams).
LooseRecruit=
Can be set to 'yes' or 'no' and determines whether or not this TeamType should be dissolved after completion of its assigned ScriptType if that mission was successful (in other words the members of its associated TaskForce are then free to be recruited into another TeamType).
Aggressive=
The TeamType will execute orders regardless of enemy action and will not stop to engage in combat with enemy objects, although it may retaliate and return fire on the way. The supposed effect is that the associated TaskForce will doggedly aspire to complete its assigned ScriptType.
Suicide=
The TeamType will execute orders regardless of enemy action and will not stop to engage in combat with enemy objects and will not retaliate or return fire. It will ignore Sight= ranges and the GuardRange= of any enemy objects and will not be recruited into any subsequently created TeamTypes on the presumption that its associated ScriptType will invariably lead to the destruction of the associated TaskForce.
Priority=
This is used to determine the priority of this TeamType being chosen for creation when the AI is deciding what to do next. The lower the number, the greater the likelihood of the AI using this TeamType above others. For simplicity, Red Alert 2 uses multiples of 5 for this setting (Tiberian Sun used multiples of 4) so it is best to stick with this convention although other values between 1 and 50 can be used. Note that the setting of the SuspendPriority= statement in RULES.INI uses this value to determine whether or not this TeamType will be suspended during base defense missions (see the RULES.INI Guide for more details).
Max=
This serves two purposes. Firstly, it serves as a trigger to create the TeamType - when set to '1', it will automatically be created by the AI regardless of whether or not it is already triggered for creation through an AITriggerType or otherwise only if IsBaseDefense=no is set for this TeamType (see below). Secondly, it serves to indicate the maximum number of instances of this TeamType that can exist at the same time only if Autocreate=yes has been set for this TeamType (see above).
TechLevel=
This is obsolete in Red Alert 2 and is unused. In previous C&C games, this was used as a method of restricting AI auto production by determining the lowest TechLevel= at which this team could be employed by the AI, however the TechLevel= setting in Red Alert 2 has become all but obsolete as this can no longer be determined by players. Leave this set to its default of 0 (see the AITriggerTypes section for a further explanation of how the TechLevel= setting is used by the AI as a result of a change in the game engine code for Red Alert 2) .
Group=
This defines a specific grouping for the units in this TaskForce which is used when executing its ScriptType. This over-rides the Group= setting in the associated TaskForce. The following values can be used;-
-1 Lose Transports - any transports are dissolved and do not execute the script
?? Lose Units, Lose Transports - all units dissolved, nothing executes the script
?? Keep Units, Keep Transports - all units retained and all execute the script
?? Lose Units, Keep Transports - only transports retained to execute script
?? Keep Units Farthest - only units furthest away are retained
?? Keep Units Nearest - only nearest units are retained
?? Greatest Threat - group together at object posing greatest threat
-40094 Least Threat - group together at object posing least threat
Tag=
Used in map files only, this is used to determine which of the [Tags] is attached to this TeamType if there is a map-specific Event and Action attached to it (e.g. it gets destroyed or should be created). See the Map Editing Guide for further details on [Tags] and their use. This is not ordinarily used in AI.INI.
Waypoint=
Used in map files only, this is used to determine the waypoint at which the TeamType is to appear. You should ensure that the waypoint you specify here is included in the [Waypoints]section of the map file. See the Map Editing Guide for a detailed explanation of waypoints. This is not ordinarily used in AI.INI although its worth noting that Red Alert 2 assigns waypoint number 99 for the center of the map and waypoint numbers 0 - 7 to define the starting places for the 8 players in multiplayer maps.
OnTransOnly=
Can be set to 'yes' or 'no' and determines whether or not this TeamType should only execute its associated ScriptType if that ScriptType contains a 'load on transports' action. If that action is not successfully completed, the TeamType is dissolved and the members of the associated TaskForce are made available for recruitment into further TeamTypes . This is used to ensure that the TaskForce only carries out its mission if it has a transport or can be transported (as it may depend upon it).
TransportWaypoint=
Used in map files only. Can be set to 'yes' or 'no' and specifies the waypoint at which the transport for this TeamType is created if its at a separate place to the rest of the TeamType.
AvoidThreats=
Can be set to 'yes' or 'no' and determines whether or not this TeamType should take evasive action, meaning it will avoid, where possible, Sight= ranges and the GuardRange= of any enemy objects. If set to 'no', the TeamType will engage and return fire on any enemy objects it encounters during execution of its ScriptType (if, of course, it is able to do so).
IonImmune=
Can be set to 'yes' or 'no' and determines whether or not members of the associated TaskForce are immune to the effects of Weather Storms. This is probably obsolete in Red Alert 2 as it is residual from Tiberian Sun, where the occurrence of an Ion Storm would instantly destroy any airborne objects - this tag would nullify that effect for this TeamType.
TransportsReturnOnUnload=
Can be set to 'yes' or 'no' and determines whether or not any transports within the associated TaskForce should return to their point of origin upon deployment of their contents provided they have been released from that TaskForce by use of the 'dissolve transport' action or using an appropriate second parameter on the 'unload transports' action (see above). The purpose of this is primarily due to the fact that most transports are unarmed and thus unable to carry out any other mission, so by returning to their point of origin they are made immediately available for recruitment into further TeamTypes.
AreTeamMembersRecruitable=
Can be set to 'yes' or 'no' and determines whether or not members of the associated TaskForce are available to be recruited into further TeamTypes when they have completed the actions detailed in the associated ScriptType. This is used because you can't actually recruit units that are already in a TeamType.
IsBaseDefense=
Used mainly for 'pool' teams (see AITriggerTypes). Can be set to 'yes' or 'no' and determines whether or not this TeamType should assume a base defense mission based on the actions detailed in its associated ScriptType. The number of TeamTypes which can be assigned to this at any one time is controlled by the MinimumAIDefensiveTeams= and MaximumAIDefensiveTeams= statements in RULES.INI (see the RULES.INI Guide). TIP: A TeamType which has IsBaseDefense= set to 'yes' will also rush to the aid of any units owned by the same House= which have ToProtect=yes set (the only examples of this in Red Alert 2 are the Ore Miners).
OnlyTargetHouseEnemy=
Can be set to 'yes' or 'no' and determines whether or not members of the associated TaskForce will also attack 'neutral' units (e.g. civilians or other objects belonging to a House= with Side=Neutral set) and consider such objects in its threat scan.
Script=
The unique identifier name used to determine the ScriptType to use for this TeamType and should also be contained in the [ScriptTypes]list and have its own section defined.
TaskForce=
The unique identifier name used to determine the TaskForce to use for this TeamType and should also be contained in the [TaskForces]list and have its own section defined.
[AITriggerTypes]
This section defines which of the TeamTypes should automatically be created in response to specific game events or other triggers in the game. Most of these are created by the AI in an attempt to ensure that it always deals with certain things, for example 'its a good idea to destroy an enemy Nuke Silo' or 'it would be good to capture or destroy the enemy Construction Yard'. In effect, this section is the very essence of the scripted AI.
This section also constitutes the full list of 'global' AI triggers used by the computer in single and multiplayer games. Individual map files can indicate whether or not this list should be used with use of the IgnoreGlobalAITriggers= statement in their [Basic] section (setting that to 'yes' means this list will not be used in games played on that map) and can also define their own AI triggers to be used only in games played on that map by including their own [AITriggerTypes] section which simply appends the new ones to the end of this list. Additionally, map files can also specify which of these triggers should be used in games played on that map on an individual basis with use of the [AITriggerTypesEnable] section which effectively allows each individual trigger to be enabled or disabled - this is used in Red Alert 2, for example, to ensure the AI makes use of Naval type attack forces on maps which have a high water content and does not try to attack with ground based units. See the Map Editing Guide for more details.
The section simply forms a list of each AITriggerType and in a break with convention it is not numbered and each entry contains its own data. Note that this may partly be due to the fact that individual AITriggerTypes listed here can each be enabled or disabled through map files (see the Map Editing Guide) so for example, the computer will not waste time and resources building a TeamType specifically to capture your Construction Yard if you can't even acquire one in the mission.
Each entry takes the following format;-
[ID]= A,B,C,D,E,F,G,XX.000000,YY.000000,ZZ.000000,X1,Y,X2,Z,H,D1,D2,D3
[ID]
Takes the form of a hexadecimal numbered string which is the unique identifier for this AITriggerType. DO NOT change this as the [AITriggerTypesEnable] section in most map files depends upon these values in order to enable/disable this particular AITriggerType as required. If you want to add or modify one, copy an existing one and add it to the end of the list with a new ID.
A = Name
This is simply a string name used for identification purposes only. In this section, you should leave this in.
B = TeamType
Determines which of the TeamTypes should be used for the actions associated with this trigger. If a TeamType is not required then this should be set to <none>.
C = Owner
Determines which House or Country is associated with using this trigger. This is to ensure, for example, that Soviet armies do not use TeamTypes containing Allied units and vice versa as this serves as an override to the Owner= statement for each object in RULES.INI. You should set this to <all> if it pertains to no particular or specific House=.
D = TechLevel
Determines the TechLevel= setting which is required in order for this trigger to be used. Although the TechLevel= setting is partly useless to human players in Red Alert 2, this is used by the AI when it assembles TaskForces. The trigger will only be used when the AI has reached this TechLevel= setting through construction of the required structures in its tech tree - setting this value below that required for a particular unit can often lead to the AI using units for which it has not met the Prerequisite= requirements. It is best to set this to at least the setting required to build any units in the associated TaskForce(s).
E = AITriggerType
Holds the type of AI trigger. This holds values between 0 - 7 with '-1' representing a special case for 'pool' teams.
-1 AI pool team trigger (autocreated thus not attached to the AIGenerals)
0 trigger when enemy owns the Unit Type or Tech Type (min quantity specified by parameter AABBCCDD)
1 trigger when computer owns the Unit Type or Tech Type (min quantity specified by parameter AABBCCDD)
2 trigger when enemy has low power (power is in Yellow)
3 trigger when enemy has low power (power is in Red)
4 trigger based on number of Credits held by enemy (min quantity specified by parameter AABBCCDD)
5 trigger when Iron Curtain is charged to amount specified by AIMinorSuperReadyPercent= in RULES.INI
6 trigger when Chronosphere is charged to amount specified by AIMinorSuperReadyPercent= in RULES.INI
7 trigger when neutral owns the Unit Type or Tech Type (min quantity specified by parameter AABBCCDD)
TIP: Use AI Trigger Type number 4 to fire triggers based on the number of credits held by the player - this will add to the 'unpredictability' of the AI as it wont be creating a TeamType based on the existence of something else. This will also allow you to target the player with most money (usually a sign of 'turtling') in which case destroying/capturing their refineries and hunting their Ore Miners as well as capturing Oil Derricks make good strategies for the AI. In Yuri's Revenge, this also makes a useful trigger for launching AI attacks with Floating Disks against Refineries.
F = Tech Type
Determines which object in the game will cause the AI to use this trigger. Should be any object from the [BuildingTypes],[InfantryTypes],[VehicleTypes] or [AircraftTypes]lists from RULES.INI. If the trigger is not fired based on a unit or tech type, <none> should be used instead (one example is for the creation of 'pool' teams). TIP: If you want the AI to defend against a tank rush, make the trigger fire upon the existence of the enemy Weapons Factory rather than the tanks themselves - this means the AI will have its defense ready by the time the tanks hit it.
G
Determines what to do in response to the unit or tech type defined in parameter 'F' (above). Takes the following format;-
AABBCCDD-EEFFGGHH-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
• AABBCCDD holds a number (represented by 4 hex bytes, in reverse) for each subsequently specified condition that must be satisfied for the trigger to be fired.
• EEFFGGHH holds a value between 0 and 5 and fires the trigger in response to one of the following condition types;-
• 5 = fire the trigger if not equal to
• 4 = fire the trigger if greater than
• 3 = fire the trigger if greater than or equal to
• 2 = fire the trigger if equal to
• 1 = fire the trigger if less than or equal to
• 0 = fire the trigger if less than
If both numbers are set to '00000000', this signifies the creation of a 'pool' type team (see below).
The long string of numbers represented by X's are usually all set to '0' - no exceptions to this have been observed and their use or significance has not been established.
XX.000000 = Weighted Probability
This determines the percentage probability that this AITriggerType will be used so that a weighted distribution of triggers is employed rather than all of them being executed one at a time as if in a list. High values such as 5000.000000 are used to ensure absolute certainty. The 'predictability' of the Red Alert 2 AI is due partly to the fact that the same values (10, 20, 40, 50, 70, 500, 5000) are usually employed throughout the triggers.
YY.000000 = Minimum Weighted Probability
This determines the minimum percentage probability that this AITriggerType will be used when amended by the AI Trigger Weighting Parameters in RULES.INI so that a weighted distribution of triggers is employed rather than all of them being executed one at a time as if in a list. High values such as 5000.000000 are used to ensure absolute certainty. The 'predictability' of the Red Alert 2 AI is due partly to the fact that the same values (10, 20, 40, 50, 70, 500, 5000) are usually employed throughout the triggers.
ZZ.000000 = Maximum Weighted Probability
This determines the maximum percentage probability that this AITriggerType will be used when amended by the AI Trigger Weighting Parameters in RULES.INI so that a weighted distribution of triggers is employed rather than all of them being executed one at a time as if in a list. High values such as 5000.000000 are used to ensure absolute certainty. The 'predictability' of the Red Alert 2 AI is due partly to the fact that the same values (10, 20, 40, 50, 70, 500, 5000) are usually employed throughout the triggers.
X1 = Skirmish Availability Flag
This should be set to '1' if the trigger is to be made available to the computer in skirmish mode and '0' if not.
Y = Not Known
Unknown but is always set to '0'. Possibly used to associate this trigger with a specific AI General although this is difficult to substantiate (see the [AIGenerals] section of the RULES.INI Guide for more details).
X2 = Side Ownership
This value is what gives ownership of the trigger itself to a particular Side=, since several Houses= could belong to the same Side=. This is what enables generic scripts to be used, for example any Soviet army to create Dogs to guard against Spies rather than, say, just Russia. This value should be set to 1 if this AITriggerType applies to an Allied army, '2' if it applies to a Soviet army and '3' if it applies to a Yuri army (in Yuri's Revenge only). TIP: Setting this parameter to '0' allows any AI controlled House= or Side= to use this trigger, regardless of the Owner= setting on the units in the TeamType, meaning that any AI player could use the same trigger in the game.
Z = Base Defense Flag
This should be set to '1' if the trigger is used for AI base defense and '0' if not. Helps the AI to decide what to do when it adopts a specific behaviour dictated by the AIGenerals (see the RULES.INI Guide) and also means the AI will create the associated TeamType even if it has not yet chosen an enemy. This is also attached to the UseMinDefenseRule= tag (see the RULES.INI Guide).
H = Support TeamType
This is what gives the AI some degree of 'smartness' - if the AI simply used the AITriggerTypes without this, it would appear to be boring and predictable as all it would effectively be doing is sending a series of attacks at the players 'list fashion'. This second TeamType is used if, for whatever reason, the first TeamType comes under attack or is otherwise deemed as being likely to fail its associated ScriptType. In that instance, this second TeamType is despatched to support the first, either by eliminating the threat to it or by attacking something else in a bid to create a distraction. This second TeamType is sometimes despatched prior to the first - for example the second TeamType could be instructed to destroy any AA defenses prior to the first being an air-ground assault. This is a much under-utilized feature which allows for the possibility of combined assaults on players. TIP: If you have a TeamType which is performing a 'rush', give it a support TeamType which can deal with any Aircraft or Base Defenses which may pose a threat to it thus rendering it useless.
D1 = Difficulty #1
Flag which should be set to 1 or 0 and indicates if this AITriggerType can be used on the easiest (or Easy) skill level setting in the game.
D2 = Difficulty #2
Flag which should be set to 1 or 0 and indicates if this AITriggerType can be used on the medium (or Normal) skill level setting in the game.
D2 - Difficulty #3
Flag which should be set to 1 or 0 and represents of this AITriggerType can be used on the hardest (or Brutal) skill level setting in the game.
• A Note On AI Pool Teams
Its worth noting that the AI is frequently triggered to create 'pool' teams. These are teams which tend to be created based on time rather than any specific event (although some pool teams are still triggered for creation by events) - this is done automatically in skirmish mode by the 'autocreate' process with the frequency of this being controlled by the TeamDelays= statement in RULES.INI (see the RULES.INI Guide). The members of these teams usually assume some default behaviour such as guarding the AI's base, and the main reason for their creation is simply to make units available for the AI so that it doesn't play the game in a scripted, linear fashion. Use of pool teams also ensures that, for example, the AI always has something with which to defend its base or guard its Ore Miners.
Members of teams created as pool teams are also used to fill other teams (in other words they are 'recruitable') so that the AI does not always have to build every team from scratch. Whilst awaiting recruitment, the pool teams assume a default behaviour (usually defense) until any or all of their members individually or collectively are recruited to join another AI team that has a specific script to perform, although some members may never be recruited into another team.
For those reasons, it is always well worth ensuring that you have the AI create quite a few pool teams, otherwise you will find its actions slow and infrequent as it will have to build almost every team from scratch.
TIP: its well worth putting pool teams into a default mission of 'Guard' rather than 'Guard Area', as teams in a 'Guard Area' mission are not recruited 'from the field' when making new teams (see the note above under the relevant script action). This will also speed the game up a little as 'Guard' requires less processor time than 'Guard Area'. Exploit the autocreation of 'pool' teams - you don't have to put these teams into a generic mission such as base defense - you could, for example, make an autocreated pool team that simply attacks the enemies Construction Yard or hunts enemy Ore Miners. The autocreate process for pool teams means that the AI will always conduct such attacks at regular intervals with the pool team you have defined.