Creating Mods-- This page is reprinted in entirety from and is ©Red Storm Entertainment.




Mission Editing for Rainbow Six

V1.0, 10/6/98


General Mission Editing Notes

All of this information is provided for you to use at your own risk. While editing these files will allow you to create new scenarios using the existing maps, or add new ways to play multiplayer, you need to be careful. Improper editing these files can cause game crashes, ruin saved campaigns, cause multiplayer to no longer work, and create problems when installing official patches from Red Storm Entertainment, Inc. You have been warned.

File Types

File Type

Location

Description

Mission File Data\mission\*.mis Global mission characteristics.
Mission Difficulty File Data\mission\*.mdf Mission details that are difficulty specific
Mission Text File Data\text\mission\*\*.mdt Localized text for each mission difficulty
Multiplayer Game Type Data\mission\*.mgt Rules sets for multiplayer games
Victory Conditions Data\mission\*.txt Victory conditions for each mission difficulty
Terrorist Actor Files Data\actor\*.ter Details about terrorists
Hostage Actor Files Data\actor\*.hst Details about hostages
Objective Actor Files Data\actor\*.mso Details about mission objective actors
Kits Data\kit\*.kit Equipment carried by a person

 

Tools in the Game

The one bit of information that you cannot get easily are locations and facings for the actors and zones in the mission. There are two ways to get this from within the game.

First, you can use the planning interface. Load up a mission that uses that map into the game, go into the plan map, and lay down routes. This works ok for starting locations and great for paths (such as terrorist patrol routes). Save the plan file (these are in data2\plan) and then open it with a text editor. You’ll see a start location and facing for the route, plus all the waypoints. You can’t just cut and paste these into the mission file, though, as you’ll need to remove the "MoveTo" at the start of the line and the 1 or 0 that comes at the end. But, you’ll have the numbers.

The other way that works well is to use the debugging keys. Bring up a chat window and type "debugkeys" into it. You’ll get a message that the debugging keys are now available. Hit F10 to toggle the keyboard into debug mode (again, you’ll get a message). Now whenever you hit the F key, a message is written to the DEBUG.TXT (in a debug build) or SHERMAN.LOG (in a release build) with your current location and facing. These can be easily pasted in to the mission file. Use both the location and facing for random and default start locations, or cut the facing out if you’re creating a path. In addition, you’ll get the number of the room you are in (useful for PatrolArea steps).

Bitmaps

Rainbow Six uses a custom bitmap file format called "RSB". RSBs are simply pre-processed bitmaps with an 8-bit palletized version (for textures) and a 16-bit 5-6-5 version (for textures and shell art) in one file. This speeds up game loading. If a 24-bit BMP is supplied, the game will create the appropriate RSB file and use it. If you are creating new bitmaps for characters or weapons, create a 24-bit BMP of the appropriate size, run the game, and then use the RSB that gets created.

The Mission Listing File

A list of all missions available in the game is in data2\mission\mission.lst. If you want to add a brand new mission, it must be added to the appropriate section of this file. Otherwise, it will not appear in the game interface. You can also simply edit an existing mission.

The Mission File

Each mission must have one mission file. You can either edit an existing mission file, or create your own new one (which must be added to the mission listing file). A mission file has the following structure (this is taken from m01.mis):

//---------------------------------------------------------

// MISSION DATA

//---------------------------------------------------------

This section is a comment. Our parser can handle both C-style comments (start with /* and end with */) or the C++ style comment shown above. If the parser hits a /*, it will ignore everything up to and including the next */ it finds. If the parser hits a //, it will ignore everything up to the end of that line. Anything inside double quotes "" is considered a single token (in case you need spaces in a name). Any amount of whitespace (tabs, spaces, or newlines) may be used to separate tokens.

"M01.map"??// Map file name"M01"???// Map directory"M01 Operation Steel Wind"?// Name of missionM01.pln???// Default plan file nametest0.brf??// Briefing file nametest0.dbf??// Debriefing file name

"M01.bmp"??// Mission picture file name

This section describes the basics of the mission. The first line is the map name. This map must exist in the data2\map folder. The next line is which directory inside data2\map holds this map and all of its textures and other files. In this example, we are using data2\map\m01\m01.map for this mission.

Next is the name of the mission. This is used in the interface wherever the mission is listed. The last 3 lines may be safely ignored; they are artifacts to old code that have simply been left in as placeholders. They must be there, but their contents do not matter.

// Renderer options10.0f???// Hardware near clipping plane15000.0f??// Hardware far clipping plane10.0f???// Software near clipping plane

15000.0f??// Software far clipping plane

1???// Fog is on

55 65 85??// RGB for fog

600.0f??// Fog start

6000.0f??// Fog end

55 55 50??// Ambient lighting color value

55 65 85??// Background color (should match fog, if on)

These are all rendering options used for this mission. The first two numbers are the distance (in centimeters, all game units are listed in centimeters) to the near and far clipping planes in hardware, while the next two are used for software. Anything closer than the near clipping plane and farther than the far clipping plane is not drawn. Adjusting these can affect performance.

Next comes fog information. This map uses fog as indicated by the 1. Changing that line to 0 would turn fog off for the mission. Note that if the user specifies no fog in their Options screen, a 1 here would be ignored. We then have the RGB color for the fog, how far from the camera fog starts (in this case 600 cm, or 6 meters), and how far from the camera the fog blocks everything (6000 cm, or 60 meters).

We then have two more RGB color values: ambient lighting (used everywhere in the level), and the background color used where stuff isn’t drawn. The background color should match the fog color to avoid any weird rendering anomalies.

// Clouds information

1???// Clouds are on?

"01_clouds.bmp"?// Cloud texture name

1.0f???// Clouds texture multiplier

1.0f???// Clouds speed multiplier

OutdoorRooms?// List of rooms in which clouds should be drawn

?0

End

FogRooms??// List of rooms in which fog should be drawn

?0

End

BackgroundColors?// List of rooms with alternate background colors

?0?255 255 0

End

Now we have some additional rendering cues. The first line indicates whether or not clouds are drawn for this level. We then have the name of the bitmap to use for the cloud texture. The texture multiplier determines how large the cloud texture is drawn, and the speed multiplier affects how fast the clouds move across the sky. Next we have a list of rooms in which the clouds should be drawn. Every room in a map is numbered; simply add the number of any outdoor room to this list and clouds will be drawn when the character is in that room.

We then list any rooms that should have fog drawn. These should generally be outdoor rooms. Indoor rooms, no matter how large, should generally not be fogged at all.

Finally, we list any rooms that we want to have a different background color from the general one specified for the rest of the map. We also give the color to use in that room.

// AI Line of sight info

2500.0??// Max Distance

// Rules info

1???// Full Surveillance On?

// Gore info

0???// Gore disabled for this mission

This section lists some general rule information. First is the max line of sight distance. Ais will not see anyone farther away than this distance. For this level, it is set to 25 meters. If you think Ais are not seeing far enough on a level, raise this number.

The full surveillance line should be set to 1 on any mission where the team should have had time to set up the global heartbeat sensors. If this is 1, the player will see the location of every human in the level in their in-game map. If this is 0, only detected humans will appear in the map.

// Plan map info.2000.0??// Initial zoom distance500.0???// Minimum zoom distance

4000.0??// Maximum zoom distance

0.0???// Initial camera rotation in degrees

0.0???// Compass rotation to point north.

1.0?2.5??// Min and Max Waypoint scale

2.5?6.0??// Min and Max Waypoint connector scale

1.0?2.5??// Min and Max Icon scale

This section describes how the map looks in the planning interface. Tweaking these values affects how the map is initially displayed. In addition, you can change how big the paths for the teams are drawn on the map.

0???// Number of weeks past

This is how long this mission occurs after the previous mission in a campaign. Since this is the first mission, no time is passed. This affects how much team members will heal from wounds and fatigue accumulated on prior missions.

16???// Number of filtered kits

3

4

5

6

7

8

9

13

14

15

16

17

18

19

20

21

We limit the number of uniforms that the player has to choose from on a particular mission. The reason for this is texture memory; if 8 team members are taken on a mission and each has a different camouflage pattern, performance and the look of the level will suffer. So, this list determines which uniforms are not allowed on a mission. To determine what the numbers mean, look at the data2\kit\uniforms.itm file. The first kit is 0, the last kit is 21 (at the moment; patches and mission packs could change this file). In this list, there are 16 uniforms that may not be picked for this mission. The six allowed are 0 through 2 (solid gray light, medium and heavy) and 10 through 12 (gray camouflage light, medium and heavy).

// Roster modifiers0?// restrict to operatives that went on the previous mission0?// only allow operatives that went on the previous mission11?// number of operatives to activate this mission"Arnavisca, Santiago""Bogart, Daniel"

"Burke, Andrew"

"Chavez, Ding"

"Haider, Karl"

"Hanley, Timothy"

"Maldini, Antonio"

"McAllen, Roger"

"Raymond, Renee"

"Walther, Jorg"

"Yacoby, Ayana"

0?// number of operatives that become unavailable this mission

These are roster modifiers. This is how we control who becomes available when. If the first number is set to 1, the player may only take operatives who went on the immediately preceding mission. If the second number is set to 1, the player may not take any operative who went on the immediately preceding mission. The third number is a count of how many operatives become available at this point in the campaign. In our example, the 11 listed operatives are available when the player reaches this mission (the first in the campaign). The last number is a count of how many operatives leave the team and become unavailable; if this were greater than 0, the operatives would be listed by name as shown for the activated operatives.

1?// Difficulty Setting Exist// Mission Difficulty Files

M01Easy.mdf

M01Med.mdf

M01Hard.mdf

This is the last part of a single-player or co-operative mission file (in a multi-player mission, more data follows this as there are no difficulty files; that data will be described in a later section). Normally, the first number is set to 1 to indicate that there are multiple difficulty settings for this mission. If it is set to 0, that means that no matter what difficulty the campaign is using, the same terrorist and hostage layouts will be used and the following 3 lines do not appear.

In this case, we have multiple difficulties, and they are found in the following 3 files. The first is for Recruit difficulty, the second for Veteran, and the third for Elite.

Multiplayer Mission Files

A multiplayer mission file differs from a single player mission file in two ways. First, all the mission details (see below) are included directly in the mission file. Any and all details are allowed, which implies that you can add terrorists to a multiplayer mission (just to throw the teams off ;-). Second, the Adversarial flag is set to 1 instead of 0, and it is followed by some extra data. For example:

//---------------------------------------------------------

// ADVERSARIAL DATA

//---------------------------------------------------------

1???// This is an adversarial mission

This is the header that indicates this is an adversarial mission. It will show up in the mission list in an adversarial game.

// Spawn points

39???// Number of spawn points

34528.1 35267 33543.7

31266 35367 29596

Here come the spawn points. First a count is given, then the points. There must be at least 16 spawn points for a mission to work correctly. Players will be randomly placed on the spawn points.

// Team information

// Side One: Base

30091.5 33767 30599.5

30300.6 33767 29739.5

// Side Two: Base

35363.6 33767 35176

35533 33767 35713.9

These are the team bases. Side one is Blue, side two is Gold. Note that only the corners are specified, much like insertion / extraction zones. Make sure the bases are on a level spot and that the entire base fits on the map. Also make sure that 8 people can fit around the edge of the base (one on each corner, and one in the middle of each side).

That’s all that is needed to turn a mission into a multiplayer playable mission.

The Mission Difficulty Files

These contain the information for each mission specific to each difficulty level (especially terrorists, hostages, and victory conditions). Below is an example (M01Easy.mdf):

VicCondM1Easy.txt?// Victory Conditions file name

This is the name of the file that contains the victory conditions for this mission. See the section below for what should go in this file.

//---------------------------------------------------------

//-- Landmarks --------------------------------------------

//---------------------------------------------------------

7???// Number of landmarks

// Insertion Zone

5

29423.8 32157 35190.4

0

// Extraction Zone

6

30601.7 32157 36039.3

0

// Front Door

0???// Unique number id

31603.4 32287 32747.5?// Location

0???// Is Primary Objective?1==TRUE, 0==FALSE

// Foyer

1???// Unique number id

32783.2 32287 32754.9?// Location

0???// Is Primary Objective?1==TRUE, 0==FALSE

// Balcony

2???// Unique number id

34725.5 32947 32743.8?// Location

0???// Is Primary Objective?1==TRUE, 0==FALSE

// Fire Escape #1

3???// Unique number id

33745.4 32947 34657?// Location

0???// Is Primary Objective?1==TRUE, 0==FALSE

// Fire Escape #2

4???// Unique number id

33715.2 33387 34675.9?// Location

0???// Is Primary Objective?1==TRUE, 0==FALSE

This section contains landmarks that show up in the planning interface. Each one has a unique number ID (which is an index into the Mission Difficulty Text file described below), a location, and an indicator that tells whether or not it is a primary objective. The primary objective indicator determines what icon is used for the landmark.

// Specific Action Objects

0???// Number of action objects

Specific action objects are used for switches and bombs. This mission has none, but I’ve pasted in a sample from a different mission:

"Disarm Bomb"?// Type of objective

"rigbomb"???// Actor name

"rigbomb.mso"??// Actor Filename

30717.6 34567 30304.5 ?// Location

0???// Rotation about Y axis.

0???// Number of dependants

This is a bomb from mission 3 (the oil rig). The objective type determines what skill and equipment are used to determine how long the object must be manipulated for before it is considered complete, as well as what radio messages are played by your team members as they manipulate it. It must be one of "Plant Bug", "Disarm Bomb", "Override Video Feed", "Access Computer", "Disable Virus Release Capsule", "Deactivate Security", or "Switch".

Next comes a name for the actor. This is used internally by the simulation and must be unique. Then comes the actor file name. This file resides in data2\actor and contains details about the mission objective. These files are described below. After this is the location of the objective in the world, then a rotation (in case you want it to face a different direction), and the number of dependants. The number of dependants should be left at 0.

//---------------------------------------------------------

// TERRORIST DATA

//---------------------------------------------------------

9????// Number of Terrorists

Here come the bad guys 8-) First we tell how many there are going to be.

// Guy looking for ambassador

"Seeker1"

MTER_V2.ter

M1T1_AK47.kit

This is our first guy and the only one I’ll describe. Normally there would be 8 more after this. Also, I’ve edited his PatrolPath step down so it fits better. There is another section below on AI plans.

We start with a unique identifying name for this terrorist. This is used internally by the simulation. Next comes which actor file to use. This actor file is in data2\actor. You can tell the type of terrorist by the name of the file. The ‘M’ on the front says that this is a male terrorist (‘F’ indicates a female). ‘TER_’ follows to indicate that it’s a terrorist (hostages have ‘HOST_’ but otherwise follow the same naming convention). The ‘V’ indicates a veteran. We also have ‘R’ for rookie and ‘E’ for elite. This determines the skill level (mostly how well the terrorist shoots). A ‘1’, ‘2’, or ‘3’ comes last. This is the "determination" level of the terrorist. A ‘1’ indicates a terrorist who’ll break and run at the first sign of trouble, while a ‘3’ will stand and take just about anything without panicking. All terrorist actor files end in .ter; feel free to poke around in data2\actor to see all the possible files we’ve created. If you feel the need, you can create a new terrorist actor file and use it here.

Next comes the kit file name. These are in data2\kit. The kit file contains a list of all the equipment being carried and the body armor being worn. These are described in detail below.

0????// Location Known?1==TRUE, 0==FALSE

0????// Is Primary Objective?1==TRUE, 0==FALSE

1????// Icon Shown??1==TRUE, 0==FALSE

These 3 booleans affect how the icon for this terrorist appears in the planning interface. The "location known" boolean is set depending on how good the intelligence is on the terrorist’s location. If the terrorist is standing still or moving in a small area, set this to 1. If the terrorist is wandering around a large area or could be in any of a number of locations set it to 0. The "primary objective" boolean is set to 1 for terrorists that have a special meaning to the mission (i.e. Ramon Calderon in M04), or 0 for most normal guards. And finally you can set the last boolean to 0 to hide the icon in the plan map (use this when the player has very poor intelligence on the mission).

1????// Count of random start locations

?34051.9 33377 33950.9 176

Ready

34051.9 33377 33950.9 176?// Default Start / icon location

"Deliberate Engage"??// Starting SOP

3????// Number of plan steps

"PatrolPath" "Once" 5

?33897 33377 33887

?33797 33377 33887

?33697 33377 33577

?33597 33377 33577

?33428 33377 33659.5

"EliminateThreat" "AmbassadorActor"

"InvestigateDisturbance"

Ready 0????// Ready Contingency Plan

Alert 0????// Alert Contingency Plan

Here is the terrorist’s script for this mission. First comes a count of random start locations. If this is 0, the terrorist will start at the default location given 2 lines down). Note that a terrorist on a "PatrolPath" plan can start anywhere along the path unless a random start location is given; in this case, I’ve specified one random start location to force the AI to start at the beginning. Make sure you have exactly as many start locations and facings given as the number you specified. The facing must be between 0 and 255 (a complete 360 degrees is mapped to this 0 — 255 range).

Next comes the starting alertness level for the terrorist. This must be one of "Bored", "Ready", or "Alert". Bored terrorists see and hear less than Ready terrorists, who see and hear less than Alert terrorists. Terrorists will go from Bored to Ready when they hear the team members, and will go from Bored or Ready to Alert when they see the team members.

Then comes a default start location and facing. This is used for the icon location in the planning phase, and as a start location if no random location is given or the terrorist has a plan other than "PatrolPath". The facing is what direction the terrorist starts off looking (as above, it must be between 0 and 255).

The starting SOP comes next. This is a two word combination. The first word describes the speed at which the terrorist moves and must be one of "Safety" (which means move slow and take careful aim), "Deliberate" (which means move normal and take reasonable aim), and "Blitz" (which means move fast and take any shot you get). The second word describes how the terrorist moves and must be one of "Clear" (which means normal combat for a terrorist), "Engage" (which means the same as Clear for terrorists), and "Advance" (which means ignore any targets, just move).

Then we have a count of the number of plan steps for this terrorist. In this case, we have 3. After that are the actual plan steps themselves. I’ll describe these in a minute, but in this case the terrorist has a path to move along, and at the end of that path the terrorist will kill the specified hostage, then start investigating any combat sounds it hears.

Finally we have the contingency plans for the terrorist. The "Ready" plan is executed if the terrorist hears something, while the "Alert" plan is executed if the terrorist sees something. This happens when the terrorist changes alertness levels, so if the terrorist starts Ready the terrorist will never execute its Ready plan. The keywords are followed by a count of the number of steps in the contingency plan. In this case our terrorist does not do anything special on sight or sound.

//---------------------------------------------------------

// HOSTAGE DATA

//---------------------------------------------------------

1????// Number of Hostages

// Ambassador hiding on second floor

"Ambassador"

MHOST_1.hst

M1_H1.kit

1????// Location Known?1==TRUE, 0==FALSE

1????// Is Primary Objective?1==TRUE, 0==FALSE

1????// Icon Shown??1==TRUE, 0==FALSE

3????// Count of random start locations

32593.2 32927 31612.8 111

33449 32927 31340.8 187

32971 32927 31548 129

32765.4 32927 31328.5 188?// Default Start / icon location

"Safety Advance"??// Starting SOP

1????// Number of plan steps

DoNothing

//---------------------------------------------------------

// VEHICLE DATA

//---------------------------------------------------------

0????// Number of Vehicles

These sections look a lot like the terrorist section above. We have one hostage and no vehicles. The hostage section looks a lot like the terrorist section, except that there is no initial alertness state and no contingency plans. Alertness levels have no meaning for hostages. We do have 3 random locations for the hostage, however.

//---------------------------------------------------------

// SINGLE PLAYER INSERTION ZONES

//---------------------------------------------------------

1????// Number of insertion zones

29539.8 32157 35452.9??// Insertion zone corners

29328 32157 34280.3??// Insertion zone corners

Insertion zones are where the team members are allowed to start. There may be more than one in a mission, and each one has 2 corners. An insertion zone should be placed on a flat part of the map and there should be room for 3 people to line up along all edges of the insertion zone (otherwise if a 4-man team is placed at the edge of the zone facing in, someone might get stuck outside the world, as we line a team up directly behind the leader in a single file).

//---------------------------------------------------------

// EXTRACTION ZONE

//---------------------------------------------------------

1???// Extraction Zone Defined

0???// Extraction Zone Required for Game End

29968.3 32177 35611.9??// Extraction zone corners

31219.8 32177 36404.8??// Extraction zone corners

Here’s the extraction zone. Missions may or may not have one, and if one is defined you need to determine whether or not all living team members must be in the extraction zone for the mission to end. It has 2 corners just like the insertion zone and should be on a level place as well, although it does not need the border around the edge like an insertion zone.

//---------------------------------------------------------

// ADVERSARIAL DATA

//---------------------------------------------------------

0. // This is an adversarial mission?

This is set to 1 for multiplayer missions. Those are described above.

AI Plans

The plans given in the mission files consist of a count of plan steps, followed by the steps themselves. This section describes each of the types of steps you can assign to an AI. Once a step is completed, the AI automatically moves on to the next step.

GuardSpot: A GuardSpot step tells the AI to stand in the current spot and look for threats. In a typical indoor room the AI will cover an arc facing the center of the level the AI is standing on. GuardSpot is also given a time in seconds to stay in that spot. For example:

?"GuardSpot" 300.0

Will cause the AI to guard the current location for 5 minutes (300 seconds).

InvestigateDisturbance: This step is similar to a GuardSpot except that if the AI hears a team member, it will move towards that sound. There is no time-out on an InvestigateDisturbance, so the example is simple:

?"InvestigateDisturbance"

PatrolArea: A PatrolArea step tells the AI to randomly patrol a list of rooms. It takes the number of rooms, then a list of room numbers. These room numbers are best found using the ‘F’ debugging key described at the beginning of this document. Here’s an example:

?"PatrolArea" 3 12 16 17

In this example, the AI will patrol rooms 12, 16, and 17 at random. The AI will wander back and forth between the doors to these rooms looking for trouble.

PatrolPath: This is the most complex step you can assign to a terrorist. You specify the type of path which may be "Loop", "Track", or "Once". When the AI gets to the end of a Loop path, it tries to move to the first point in the path. When the AI gets to the end of a Track path, it turns around and follows the path back. And when the AI gets to the end of a Once path, it stops and goes on to the next step in its plan. Note that the only way for an AI to stop doing a Loop or Track path is if it starts executing a contingency plan.

?After the path type comes the number of points in the path, followed by a list of the points themselves. For example:

"PatrolPath" "Track" 8

??33730.7 32937 34395.8

??33731.2 32937 33729

??33697 32937 33697

??33597 32937 33697

??32067 32937 33697

??31967 32937 33697

??31900.5 32937 33712.7

??31927.2 32937 34442.9

This is a Track path with 8 waypoints. If a terrorist has a PatrolPath as the first step in their plan and does not have any random start locations assigned, the terrorist will start at one of their path points chosen at random.

EliminateThreat: This step is used to tell the AI to kill a specific other AI, ignoring all other threats until this is accomplished. This is the only way to get a terrorist to kill a captive hostage. It takes the internal simulation name of the AI to be killed. To get this, append the word "Actor" on to the end of the name you specified for the AI in the mission file. From the example given above:

"EliminateThreat" "AmbassadorActor"

would cause the terrorist to kill the hostage named "Ambassador". Note that the AI will not move to do this; it will only turn in place until it has the target lined up. You need to make sure that the AI has a line of sight to the target before assigning this step (perhaps using a "PatrolPath" "Once" step to move them).

ChangeSOP: This causes the AI to change the SOP it is operating under. This is commonly used by a terrorist contingency plan to change their speed. For example, a terrorist moving at a normal pace that hears something might be given a:

?"ChangeSOP" "Blitz Engage"

before an InvestigateDisturbance step to cause them to run to the sound that was heard. It can be given any of the SOPs listed above in the mission difficulty file description.

UseEnvironmentObject: When an AI executes this step, it moves towards the specified object and then manipulates it. It takes the name of the object given in the mission file as a parameter. For example:

"UseEnvironmentObject" "switch1"

causes the AI to pull "switch1". This is typically used to get an alerted terrorist to set off bombs.

DoNothing: This is the default hostage behavior. The hostage basically stands there until either a team member in escort mode comes along (in which case the hostage will follow that team member) or a terrorist becomes visible (in which case the hostage will surrender).

BecomeCaptive: This causes a hostage to surrender. This should be the one step for a hostage that is being guarded by terrorists so that they start off in the surrendered position. If they don’t start surrender, the terrorists will most likely kill them.

Here are some tips for creating AI plans in the mission files:

* Hostages should get a plan with exactly one step. It should be "DoNothing" if there are no terrorists around, or "BecomeCaptive" if there are.
* Use "PatrolPath" "Once" to get a terrorist to move some place. Once they reach the destination, they will move on to the next step (which is often a "UseEnvironmentObject" or "EliminateThreat", but can be anything).
* Make sure that an AI has a clear line to an object they are going to use or eliminate. They will get stuck if you don’t.
* If a patrolling terrorist has a contingency plan that requires them to move, make sure they can get to the first movement point of that contingency plan from any place on their patrol route. Otherwise they will get stuck when they go to execute the contingency plan.
* If you are using a "PatrolPath" "Once" step as the first step for a terrorist, and they have no random start locations, be aware that they may start the game at the end of their path and immediately move on to their next step. To get around this, give them a single random start location that is the same as their first point on the path.

It is recommended that you look through some of the existing mission files and see the types of things that we have done with the AIs. There are plenty of examples of terrorists that are guarding, investigating, or patrolling, but you can also find examples of terrorists that are moving toward a hostage to kill them (M01 and M05), terrorists that will set off bombs when they are alerted to the team’s presence (M03, M06, M15), or terrorists that move to choke points when alerted to the team’s presence (M11, M12). Experiment and see what works and what doesn’t.

The Victory Condition Files

The victory condition files for Tom Clancy’s Rainbow Six are used to determine the victory conditions for both single player and multiplayer missions. They are plain text files which are parsed by the game engine. For multiplayer games, only the server actually checks victory conditions, and the results are reported to the clients on game completion.

The Victory Condition engine in Rainbow Six uses what are essentially a set of states. As with most state machines, one event being met may turn on or off other events. These special triggering conditions well be dealt with later in the document.

Victory Condition Types

The victory condition file is essentially a set of individual conditions, as well as some special directives for the victory conditions as a whole (more on those later). Each condition, as it is read in, is also numbered, starting with condition 0. This is particularly important for some of the more complex victory condition configurations and for any use of the victory condition flow commands.

Each condition is one of a set number of types (and the condition type is the first element of each condition, to enable the parser to know what is coming next). The types are:

?TERRORIST_CASUALTY_COUNT

?HOSTAGE_CASUALTY_COUNT

?TEAM_MEMBER_CASUALTY_COUNT



The three casualty count conditions are used to track total kills. These are important because unlike the class conditions later, these also can be set to be side specific for multiplayer games. This means that kills can be totaled by side (as opposed to just the total number of kills which occur). Any kill for which a cause cannot be found (or which is caused by an AI in multiplayer) counts for both sides. Specific numbers, or ranges (ALL, MOST, or ANY may be used).



?SPECIFIC_HUMAN_CONDITION

?HUMAN_CLASS_CONDITION



The human victory conditions (whether for a class, that is to say, Hostages, Terrorists, or Team Members), or for a specific named actor, have a range of settings. They can track whether or not the actor (or actors) reach a zone, are killed, or are seen by an opponent. In addition, for the class conditions, as with the casualty counts, numbers can be given as specific values or ALL, MOST, or ANY. The abstract terms exist to allow victory conditions to function with missions with varying numbers of appropriate humans. Some of these conditions (such as being in a specific zone) can go from being met to not being met.



?OBJECT_CONDITION



Object conditions exist primarily to see whether an object has been manipulated in some way. This can include a door, or a mission object (like a security system, or a phone, or a bomb, or a switch). Whenever the object is succesfully manipulated (and for things like bombs, this can take time) the object condition will be met if the victory condition is active. Again, more on that sort of thing later. Object conditions are also the conditions most likely to be used to setup other conditions. Once an object condition is met, it stays met.



?ACTOR_LOCATION_CONDITION



Actor location conditions are used to track the location of any actor. This is, for example, how the escape of planes or cars results in mission failure during some of the single player missions. In addition to the coordinates of the point to be reached, a bubble around that point can be defined.



Victory Condition Flow Control

In addition to the base conditions, it is possible to activate, deactivate, or trigger another victory condition. It should be noted that "trigger" in this case has a very specific meaning. The flow controls are as follows:

?PREDECESSOR [Integer, First Victory Condition] [Integer, Activated Victory Condition]



This should be read as "first victory condition is the predecessor of activated victory condition". The secondary condition is inactive when the game starts (and will not do anything). For certain conditions (object manipulations, or anything having to do with an actor or human reaching a certain zone or location) this means that it will not register completion.

When the first condition is met, it is then deactivated, and the second condition is activated. This is important; inactive conditions are not checked for victory or failure, so no condition which is used to activate another should have any RESULT (see the details on victory conditions later in this document) other than NO_RESULT, nor should they have a GOAL_TYPE of anything other than NOT_GOAL.

It is important to note that any condition in the game can only be activated once. That means that if a condition is active (whether it starts that way, or is activated by another condition later) and then later deactivated (either by being used as the base of a flow control command, or by a specific deactivation flow control), it cannot later be activated.



?TRIGGERS [Integer, First Victory Condition] [Integer, Triggered Victory Condition]



This should be read as "first victory condition triggers the failure of triggered victory condition, assuming that the triggered victory condition has not already been met". The triggered condition will be activated if it need be (and it can be). If a condition has been triggered, and it otherwise has not been met, it will result in failure.

This is how alarm switches (for example) can be wired to bombs. The alarm switch being manipulated (it would be an OBJECT_CONDITION) triggers the bomb. If the bomb has been disarmed, which would mean it’s OBJECT_CONDITION had been met, then the trigger does nothing. If the trigger hits a bomb which has not already been disarmed, the result is mission failure.

Again, any condition which TRIGGERS another should have no RESULT other than NO_RESULT, and conditions may not be activated twice. Once deactivated, they are inactive for the rest of the mission.



COMPLETES [Integer, First Victory Condition] [Integer, Completed Victory Condition]



This should be read as "first victory condition completes the completed victory condition if that condition can be met". This is used to handle logical completions of tasks. So, for example, the task of rescuing the ambassador in the first mission can be met either by getting the ambassador to the extraction zone, or by killing off all of the terrorists. This is not the case in the second mission, as there is an army parked outside the front door; just because you killed the terrorists in your way doesn’t mean you got away free.

If the condition which is to be completed cannot be completed (for example, the Ambassador is dead), then this has no effect. As always, the completing condition is deactivated after all of the flow events are processed (this does mean that you can have a condition which not only COMPLETES multiple events, but theoretically TRIGGERS other events as well).



DISABLES [Integer, First Victory Condition] [Integer, Disabled Victory Condition]



This should be read as "first victory condition disables the second victory condition if that condition has not been met". Any condition which is disabled in this manner is also flagged as being impossible to meet. This means, for example, that once a condition has been disabled, even if another condition would complete it, it won’t take.

This is used in the most complex mission flow in the shipped version of Rainbow Six. The Athletes Village mission has virus capsules which can only be disarmed AFTER a signal is received from the security computers. So, the first set of conditions for the virus capsules result in failure; if you try to disarm them and they are on maximum security, they just go off. When the security computer is succesfully manipulated, it disables those conditions, and activates a set of timed conditions. If the capsules are then successfully manipulated within the time frame, the result is success.



Victory Condition Format

Each victory condition is made up of the victory condition type (which is used to identify it), and a number of fields which define it. These fields, which are best considered as clauses which specify the condition, can be put in in any order.

The largest number of these clauses are common to all victory conditions. They are as follows:

DESCRIPTION [String or String Token]



The description is used only in reporting primary goals (more on primary goals later in this section). It can be put into any condition, but the game engine only uses this field to report the status of primary goals.

IS_TIMED [Boolean]

This setting defaults to false. If included and set to true, it indicates that there is a time limit associated with this victory condition. This time limit starts when the condition is activated. If the condition is active, and the time limit has expired, and the condition has not otherwise been met, the result is failure. If this condition exists, a TIME_LIMIT clause is also required.

TIME_LIMIT [Float]

The time limit (which defaults to 0.0 seconds) is only used in conjunction with the IS_TIMED field, and defines the time limit itself. The value is the time in seconds in which the condition must be met before failure.

SIDE [Integer]

This field is only valid for multiplayer adversarial victory conditions. It determines whether a condition is valid only for one side or the other. The value is 0 (for the Blue side) or 1 (for the Gold side). If this is omitted, then the victory condition is not side specific, and would apply to both sides.

GOAL_TYPE [NOT_GOAL | PRIMARY_GOAL | ADDITIONAL_GOAL]

This field defaults to NOT_GOAL if unspecified. The only purpose goals have in Rainbow Six is to determine what is displayed in the mission briefings, and in the mission results screen. Anything which is set to PRIMARY_GOAL will be displayed, and should have a description associated with it. This clause has no other effect, and does not determine whether or not the mission ends. Victory conditions which are used to trigger mission flow commands should be set to GOAL_TYPE NOT_GOAL.

RESULT [PARTIAL_SUCCESS | SUCCESS | FAILURE | NO_RESULT]

This field determines the results of this condition being active and met, and defaults to NO_RESULT if unspecified. If the game is an adversarial multiplayer game, and the condition is side specific, it applies only to that side. Otherwise it applies across the board. A value of FAILURE causes failure, regardless of any other victory conditions. SUCCESS results in mission success (unless another condition failed). If all of the active conditions which could result in PARTIAL_SUCCESS have been met, then the result is mission success. These equate roughly to OR and AND respectively, as far as victory condition success is concerned. Victory conditions which are used to trigger mission flow commands should be set to RESULT NO_RESULT.



The clauses specific to the casualty count victory conditions are as follows:

?KILLED_BY_ENEMY [Boolean]



This clause indicates that the condition should tally those casualties killed by an enemy (either a terrorist or by the opposite side in multiplayer). It is important to note that is relative to the player or players. So a terrorist accidentally killed by another terrorist was in fact killed by an enemy. This defaults to FALSE if unspecified. Note that which side is friendly and which is hostile for adversarial multiplayer is determined by the SIDE clause in the condition.

KILLED_BY_TEAM [Boolean]

This clause indicates that the condition should tally those casualties killed by those friendly to the player or side (either any Rainbow team member, or members of the same side in adversarial multiplayer). This is used in the Double Bluff victory condition to track which side. Note that which side is friendly and which is hostile for adversarial multiplayer is determined by the SIDE clause in the condition.

IS_ABOVE_THRESHOLD [Boolean]

If this clause is TRUE, the condition is met when the tally is greater than or equal to the threshold. If FALSE (the default setting) , the condition is met when the tally is less than the threshold. In general, this clause is rarely set, because it is implicitly set by three of the four arguments to the THRESHOLD setting.

THRESHOLD [ALL | ANY | MOST | Integer]

This clause determines the threshold for the condition. If the value is ALL, then all of the target group must be killed. If it is ANY, then any member must be killed to make the condition true. If it is MOST, then half or more must be killed. Do not set the IS_ABOVE_THRESHOLD value manually unless you are setting a specific number rather than a symbolic value. The THRESHOLD defaults to 0 if unspecified.

If you are using the symbolic values for a side specific TEAM_MEMBER_CASUALTY_COUNT condition, then the threshold is based on the side in question. So if the clause SIDE 0 were also in the condition, THRESHOLD ALL would be use the number of players on SIDE 0 as its target value.



The clauses for the human specific conditions (SPECIFIC_HUMAN_CONDITION and HUMAN_CLASS_CONDITION) are as follows:

?HAS_BEEN_KILLED



The condition is met if the specific human (or the appropriate number of members of the specific class) have been killed.

HAS_REACHED_EXTRACTION_ZONE

The condition is met if the specific human (or the appropriate number of members of the specific class) have reached the extraction zone defined for the mission. If the specific human (or appropriate number of members of the specific class) are dead, this cannot be met.

HAS_REACHED_OWN_BASE

Valid only for multiplayer adversarial team games (and side specific conditions), the condition is met if the specific human (or the appropriate number of members of the specific class) have reached the base of the SIDE specified. If the specific human (or appropriate number of members of the specific class) are dead, this cannot be met.

 

HAS_REACHED_ENEMY_BASE

Valid only for multiplayer adversarial team games (and side specific conditions), the condition is met if the specific human (or the appropriate number of members of the specific class) have reached the base of the side other than the SIDE specified (i.e. the condition is for SIDE 0, then the person or persons must reach the base of SIDE 1) . If the specific human (or appropriate number of members of the specific class) are dead, this cannot be met.

 

HAS_BEEN_SEEN

The condition is met if the specific human (or the appropriate number of members of the specific class) have been seen by enemies. This condition is also met by the death of the human (or appropriate number of humans).

Please note that all of these clauses are exclusive of one another. If you want to check for multiple different clauses, use multiple conditions.



The clauses for SPECIFIC_HUMAN_CONDITION are as follows:

?ACTOR [String]



This clause defines the named actor (for example, MultiplayerHostage0) which is the target of this condition. This must be set, there is no default.



The clauses for HUMAN_CLASS_CONDITION are as follows:

?TEAM_MEMBERS | HOSTAGES | TERRORISTS



These three clauses are all exclusive of each other, and define the class in question. It should be noted that if the condition is side specific, then TEAM_MEMBERS only refers to team members on that particular side. This must be set, there is no default.

NUMBER [ALL | ANY | MOST | Integer]

This clause works almost exactly like the THRESHOLD setting in casualty counts. However, unlike casualty counts, the condition is met only if the count is greater than or equal to the target (there is no setting for less than). The default number is 0.



The clauses specific to the OBJECT_CONDITION are as follows:

?OBJECT [String]



This clause defines the name of the object to which the condition applies. The condition is true if it is active when the object is manipulated. This must be set, there is no default.



The clauses specific to the ACTOR_LOCATION_CONDITION are as follows:

?ACTOR [String]



The actor can be either a vehicle or a human. The condition will be true as long as the specified actor is within the set distance of the target location. This must be set, there is no default.

LOCATION [X Coordinate Float] [Y Coordinate Float] [Z Coordinate Float]

The target location (as defined in floating point coordinates). This must be set, there is no default.

DISTANCE [Float]

The distance of the bubble around the point (expressed in centimeters). The default is pulled from the constants.txt file.



The Mission Text Files

The Mission Text Files contain localized text information used under the "Recon" tab in the planning interface. All landmarks, terrorists, and hostages are described in this file. This sample is taken from the M01Easy.mdt file.

//-----------------------------------------------------------

//-- Landmarks ----------------------------------------------

//-----------------------------------------------------------

// Format <Integer> Id?<String> name <String>?Description

7?// Number of landmarks

0?"Front Door"?"The main doors are barricaded. No entry."

Landmarks start with a count, then one line per landmark. Each landmark has a unique integral identifier in the mission difficulty file that matches a line in this file. Each landmark then has a name and a description. Any text may be used.

//-----------------------------------------------------------

//-- Terrorists ---------------------------------------------

//-----------------------------------------------------------

// Format <token> ?<Localized name>?<description>

9?// Number of terrorists

"Seeker1"?"Terrorist"??"Searching for the Ambassador."

The terrorist data consists of a count, then one line per terrorist. The first string contains the name of the terrorist from the mission difficulty file. Next comes a short name for the terrorist. Finally, there is a full description.

//-----------------------------------------------------------

//-- Hostages ---------------------------------------------

//-----------------------------------------------------------

// Format <token> ?<Localized name>?<description>

1?// Number of hostages

"Ambassador"?"Ambassador"??"Hiding nearby. If discovered by terrorists, he will be executed. Get to him quickly. "

This should look familiar. Hostages have the exact same format as the terrorists.

Multiplayer Game Type Files

The Multiplayer Game Type (.MGT) file is used to create the game rules for adversarial multiplayer games. Each time the server enters the Multiplayer Shell, it scans for .MGT files, and loads them in.

Whenever an adversarial game type is selected, the Server sends the game rules to the clients. These rules are memory resident, and no files are added or changed on the client machine. It should be noted that this means that the actual names/descriptions of games are sent from the server, and will be in the language of the Serving machine. So an American player connecting to a Server running the German version would see game rules and descriptions in German.

The following fields are presented in the order in which they may be found in the .MGT File

Name Field (String or String Token): The name of the game type. This can either be a token from the text table for the game, as it is in the shipped game types, or just a string. Either will work. This should be kept short, because it is displayed in the game action interface.

Description Field (String or String Token): A description of the game type. This is displayed to all of the game types, and is especially useful when introducing new or custom game types, to make sure that all of the players understand the rules.

Additional Victory Conditions Field (Boolean): This value is TRUE if there are a set of custom victory conditions for this game type, and FALSE if there are none. The implicit game rules for adversarial multiplayer games are victory when all opponents are dead. Anything more complex will require a separate victory condition file.

Victory Condition Filename Field (String): If and only if additional victory conditions are selected, this field will be the name of the victory condition file (which must be in the Data\Mission directory under the root game installation) which is to be loaded for this particular game type. See the documentation on Victory Conditions for the details on the contents of this file.

Sides Enabled Field (Boolean): If this field is TRUE, the game is a team game, and the players will be divided into two sides, Side 0 (Blue) and Side 1 (Gold). If this is FALSE, the game is a free-for-all, with no teams in play. In a free-for-all game, players will start at random locations around the map.

Sides Start in Bases Field (Boolean): If and only if this is a side enabled game, this field determines whether the two teams start in eight points around the perimeter of their base, or at the random locations used in free-for-all games.

Create Hostages Field (Boolean): If and only if this is a side enabled game, this field determines whether or not the game should automatically create two hostages. These hostages are named (for the purpose of victory conditions) MultiplayerHostage0 and MultiplayerHostage1.

Hostage Start Location Field (String): If and only if this is a hostage game, this field determines where the hostages are created. The fields are as follows



HOSTAGES_START_IN_BASES: One hostage will start in the exact center of each base. MultiplayerHostage0 will start in the center of the base for Side 0 (Blue), and MultiplayerHostage1 will start in the center of the base for Side 1 (Gold).

HOSTAGES_START_AT_SPAWN_POINTS: The two hostages will be seeded at Random amongst the random spawn points defined for the level. DO NOT SET THIS OPTION IF PLAYERS ALSO START AT RANDOM SPAWN POINTS. This setting is not tested, as it was not used in the multiplayer game types shipped with the game.

HOSTAGES_START_IN_EXTRACTION_ZONE: The two hostages will start at the two defined points of the mission extraction zone. THIS WILL NOT WORK WITH ALL MISSIONS, AS SOME EXTRACTION ZONES EXTEND OUTSIDE OF THE PLAYABLE AREA. This setting is not tested, as it was not used in the multiplayer game types shipped with the game.



Hostage Actor File Field (String): If and only if this is a hostage game, this field determines the actor filename for the hostages. This file must be in the Data\Actor directory under the root game installation.

Hostage Kit File Field (String): If and only if this is a hostage game, this field determines the kit filename for the hostages. This file must be in the Data\Kit directory under the root game installation.

Mission Limitations Field (Boolean): If this field is TRUE, then all missions are valid for this game type. If this field is FALSE, then the game type is limited to only certain missions. The mission limitation code is untested, as all of the multiplayer game types which shipped with the game are valid for all missions.

Valid Mission Count Field (Integer): If and only if missions are limited, this field is the number of mission files which are valid for this game type. The mission limitation code is untested, as all of the multiplayer game types which shipped with the game are valid for all missions.

Valid Mission Filename Fields (String): If and only if missions are limited, one of these fields will exist for each mission. This is the filename of a valid mission for this multiplayer game type. Each mission must be located in the Data\Mission directory under the root game installation. The mission limitation code is untested, as all of the multiplayer game types which shipped with the game are valid for all missions.

Actor Files

Actor files contain all the attributes of humans that appear in the game. As listed in the table at the top of this document, there are a variety of extensions used for these. All share the same format information. Below is Ding Chavez’s actor file:

"Ding Chavez"

This actor name is a left-over artifact from early versions of the game. It is left here as a reminder of which actor is in the file.

"chavezf.bmp"

"chavezl.bmp"

These are the names of 2 bitmaps that are used by the shell. These are stored in the data\shell\faces folder. The first is a small face bitmap used in all the team listings. It should be a 19 x 57 bitmap with three face graphics stacked one on top of the other. Each individual face graphic is 19 x 19. The top face is the normal one, the second is a grayed-out or unselectable version (we use a black checkerboard over the same face used on top), and the third is a brighter highlighted version of the top one.

The second bitmap is a large face used when the actor is a team leader. It is 43 x 43 pixels in size.

Neither of these bitmaps matter for terrorists or hostages, so anything can be put in for them.

100???// Health

100???// Fatigue

95???// Agression

100???// Leadership

92???// Self-control

97???// Stamina

94???// Teamwork

71???// Demolitions

67???// Electronics

100???// Firearms

74???// Grenades

100. // Stealth

These numbers are the attributes for the character. All should be in the range of 1 to 100. Health and Fatigue do not matter and should be left at 100.

1010. // Radio voice pitch adjustment (1000 = normal)

This number is applied as a pitch adjustment to the character’s voice in the game. 1000 is normal, below 1000 leads to a lower-pitched voice, and higher than 1000 leads to a higher-pitched voice. This gives each team member in the game a unique voice over the radio. Terrorists and hostages ignore these values.

"chavez.bmp"

This is the name of the large graphic that appears on the roster screen. It is stored in the data\shell\roster directory and is 141 x 211 pixels in size. Terrorists and hostages do not use this.

"Chavez.bio"??// Background text file

This contains the nationalized text information about the actor’s background. These are stored in the text\bios folder under the appropriate language folder. The bio file is free-form text. Blank lines are used to separate paragraphs. Terrorists and hostages do not use this.

"american.bmp"??// Nationality Flag bitmap

Which bitmap to use for the actor’s flag in the roster screen. If you need to add a new flag, they are 145 x 88 pixels in size. Terrorists and hostages do not use this.

"chavez.prf"??// Actor profile

This file contains medical and other data about the actor. These files are stored in the data\text\profile folder under the appropriate language folder. The profile file is simple and self-explanatory, so it is not documented here. Terrorists and hostages do not use this.

"USA"???// Gun Ready style - USA or Europe

This indicates how the character holds the gun in the ready position. Valid values are "USA" or "Europe". USA style has the gun tucked in against the shoulder ready to be raised in position. Europe style has the gun rotated on its side so that it is rotated and raised into firing position.

"MALE"???// Sex, MALE or FEMALE

What sex the character is. Used primarily for sound effects such as wounds and radio transmissions.

1, .97, 1???// scale

XYZ scaling factors for the character. This is used to reflect the height of the character since all team members share the same models. Ding is slightly under average height. It is not recommended that you adjust the X or Z scaling values as they affect the speed at which a character can travel.

"chavez_hrt_light.bmp"?// HRT light face texture

"chavez_camo_light.bmp"?// Camo light face texture

"chavez_camo_light.bmp"?// Desert light face texture

These are the face textures used by the character for the different skins. They are stored in the data\texture folder. The camo textures are 128 x 64 pixels in size and include the entire head (hair, ears, etc.). The HRT textures are 32 x 32 pixels and include just the front of the face. Terrorists and hostages do not use these.

Kit Files

Kit files describe all the equipment being carried by an actor in the game. They can be used as default kits for the team members for a mission, or describe what a terrorist or hostage is carrying.

"TEAM MEMBER"?// kit type

The type of kit for describing who is using it. Must be one of "TEAM MEMBER", "TERRORIST", or "OTHER".

"Assault"??// kit name

A name for the kit. May be any text.

"none.bmp"

"dummy.txt"

Ignore these values, they are no longer used.

"Primary"?"pw_mp5.wpn" 5?// primary weapon

"Secondary" "sw_45.wpn" 3?// secondary weapon

The weapons carried in the primary and secondary slots. A secondary weapon may not be carried without a primary. Terrorists and team members must always have a primary weapon, while hostages should never have a weapon. Secondary weapons are optional in all cases. The primary weapon for a team member kit used as the default kit for a mission should be in the primary.itm list. Terrorists may use any weapon in the primary or secondary slots. The number at the end of the line is the number of magazines carried for that weapon.

"team_hrt"???// model folder name

This is the name of the folder in the data\character folder that is used for the character model.

3????// # of LODs

"grey_medium_a"

"grey_medium_b"

"grey_medium_c"

These are the models used for the 3 different LOD levels.

3

"medium_hrt.eq"??1?// body armor always first

"flashbng.eq"??3?// slot 1 item

"flashbng.eq"??3?// slot 2 item

Any extra equipment carried. The first number is a count and should always be at least one (for the body armor slot). The next line has the body armor carried which also determines the motion set used for the character. The next two lines are used for items in the 2 extra slots, along with a count of how many of that item there are.
--------------------------------------------------------------------
-----------------
Rainbow Six and Eagle Watch are ©Red Storm Entertainment.

---------------------

| << Back