CGF Terrain / Route File Creation
Last update: October 22, 2000, by William. List of changes here .

This manual is organized as one big html file to allow you to save it to your own hard disk for future reference. Do check back the original page for any updates.

1. Introduction

The basic information describing the terrain just consists of:

• waypoints, or nodes
  A node describes a location that can be visited by the bot, and is annotated with various 'flags' that inform the bot whether that location is, for example in water, requires crouching, etc. All these flags are generated automatically once the node is created.
• connections, or links
  A link between two nodes describes a viable direct path from one node to the other without major obstructions.
  A link only describes a one-way path. To describe that you (and the bot) can move directly from one node to the other and back, two links are required.
  Typically, a link depicts a horizontal path between nodes that are about 200 game units apart. However, a link can depict a 800 unit jump from a cliff down into the water as well.
  Links are not annotated. Instead, the AI figures out what to do (jump, swim, crouch, open door, shoot breakable glass) based on the flags of the nodes connected by the link.

Terrain file creation or route file creation is the process of creating a good terrain description for the bots. The bots really depend on these terrain files for navigation, but in the case of CGF, also for finding cover, location sniper positions, approaching a position stealthily, etc.

Note that the CGF bots cannot 'roam' or 'explore' an unknown map themselves. This is explained in the FAQ.

This manual is organized as follows:

1. introduction (this text)
2. terrain files (.srp, .dst, .tac, .exp)
3. node flags
4. terrain mapping commands
5. steps to create an initial terrain file
6. steps to test and improve the terrain file
7. deal with map features that are likely to cause problems
8. easy creation of a .cgf script defining locations
9. debugging terrain problems in missions
10. requirements for CGF terrain file distribution
11. additional credits
12. change log for this document

2. Terrain Files

• {mapname}.srp, [essential!]
  defines the nodes and connections
• {mapname}.dst, [optional, can be reconstructed]
  (large file) containing the path lookup table for each pair of nodes.
  The presence of this file speeds up map load time by about 5 minutes
• {mapname}.tac, [optional, can be reconstructed]
  (small file) containing all kinds of tactical lookup tables
  The presence of this file speeds up map load time by about 2 minutes
• {mapname}.exp, [optional, but cannot be fully reconstructed]
  (small file) contains and records experience gained from monitoring player/bot movement and performance.
  The presence of this file improves the AI behavior, but does not affect map load time at all.

• {mapname}.fog, [optional, and in directory action\cgf\fog]
  (small text file) defines fog preferences for map at hand: fog density, fog type and fog color (expressed in red, green and blue)
  Density is typically low for indoor maps and higher for outdoor maps (0.0 disables fog, 0.05 is low, 0.20 is dense).
  Since the terrain file will enable the gamer to start playing CGF at a specific map, it makes sense to provide a fog file for that map as well.

Because generating these tables takes about 7 minutes (depending on CPU power and map size), and because most gamers don't like to wait that long before playing a mission, CGF computes these tables once, and stores them in (large) files. CGF then reads these files (thus: tables) at the start of a mission, and launches the mission in about 10 seconds instead of 7 minutes. The sole disadvantage is that it takes a few MB's of your harddisk.
If you are short on hard disk space, you can remove the .dst and .tac files for the maps you don't play frequently - this saves up about 2MB per map.

3. Node Flags

• when you start the mapping process
• when you spawn a node, or
• when post-processing the map (before saving, when reconstructing the terrain files).

Please note that you'd better not remove any nodes that are created when you start mapping (doors, breakable glass, etc.) because you cannot re-create these manually.

CGF 0.79 records the following properties per node:

node property	computed	description
id	spawn	unique node number - may change as a result of node removal, values range from 0 onwards
lightlevel	spawn	lightlevel, as recorded during creation. ranges from 0 = dark to 128 = full bright
'low' flag	spawn	around node location, crouching is required
'watershallow' flag	spawn	location features shallow water (no need to swim, reduced speed, no falling damage)
'waterdeep' flag	spawn	location features deep water (need to swim, reduced speed, need to surface to breathe)
'breathing' flag	spawn	location is deep water but to surface for breathing
'ladder' flag	spawn	location features ladder
'narrow' flag	spawn	location features narrow ladder or ledge, thus requires more precise jumping and movement
'glass' flag	start mapping	location features breakable glass
'elevator' flag	start mapping	location is elevator stop position [not supported yet]
'train' flag	start mapping	location is train stop position [not supported yet]
'door' flag	start mapping	location is a normal or rotating door (that can be opened)
'covered' flag	post-processing	location enables bot/player to put their back to the wall and be attacked from 'one' direction (190 degrees) only
'indoor' flag	post-processing	location (and its direct surroundings have an indoor location, and should be tackled appropriately by the forces) [not supported yet]
'traffic' flag	post-processing	location is used frequently for movement (and deserves closer attention) - flag becomes more accurate when playing more missions on a particular map
'snipe' flag	post-processing	location is used succesfully for sniping (and deserves closer attention) - flag becomes more accurate when playing more missions on a particular map
'camp' flag	post-processing	location is used succesfully for camping (and deserves closer attention) - flag becomes more accurate when playing more missions on a particular map

4. Terrain Mapping Commands

All commands are issued from the console (or via a key binding). All commands are prefixed by 'terrain' and need to provided with the appropriate argumeents. Thus the 'show infront' command should be entered as, for example:

terrain show infront 30

command	description
help	displays summary of terrain commands
map	Toggles node creation (if node creation is toggled on, and linking wasn't on, linking will be enabled as well). Note: the first time node dropping is toggled on, a node (node 0) is dropped at your position, and all doors and breakable glass are given nodes as well. When display node is enabled, new nodes will show up as red balls. Whenever node dropping is toggled off, map post processing is done (to remove some incorrect nodes and links, and to compute label information for each node). This takes some serious time.
link	Toggles link creation. Node creation need not be on. Link creation is automatically enabled when enabling node creation using terrain map. When display link is enabled, new links will show up as rail gun traces (un-directional links) or green laser lines (bi-directional links).
log visit	Toggles reporting of node information. When enabled, the node properties are listed. The following abbrevations are used in the reported information: 'd' is defensive value, 'l' is lightlevel, 'o' is occupation score 'm' is movement score, 's' is sniping score, 'c' is camping score. Note: you need to have 'log visit' enabled to use the 'terrain show' commands.
log create	Toggles reporting the creation of any link or node (tells if a node is created, and if two nodes are linked. In the latter case, the distance, expressed as travel time in seconds id displayed). Since the 'display node' and 'display link' options suffer from the Quake2 entity limit, I typically have 'log create' enabled to see whether links and nodes are being created.
display node	Toggles displaying of nodes (by red balls). Nodes remain only visible for about 60 seconds. Quake2 has troubles handling too many entities. Since each nodes and link are displayed using one entity each, Quake2 soon will start complaining. For that reason, if there are already too many waypoints present in the map to be displayed at all, none of them are displayed initially, and solely new nodes will be displayed.
display link	Toggles displaying of links by rail gun traces (uni-directional or one-way links) and green laser lines (bi-directional or two-way links). Links remain only visible for about 60 seconds. Quake2 has troubles handling too many entities. Since each nodes and link are displayed using one entity each, Quake2 soon will start complaining. For that reason, if there are already too many links present in the map to be displayed at all, none of them are displayed initially, and solely new links will be displayed.
save	Performs post-processing of the map (removing incorrect links, updating description info) and saves the route info to action\terrain\<map>.srp.
manual drop node	Drops a new node at the player position and automatically creates all safe links for neighboring nodes to / from this new node (whether terrain link is enabled or not). Make last created node also the last visited node.
manual delete node or manual delete node <nodeid>	Removes the specified node (or the last visited node if no node id was given - use terrain log visit to know which node was last visited), and assigns the last created node the id of the deleted node. Therefor, don't count on node numbers to remain the same if you use manual delete node. Solely node 0 cannot be removed using 'terrain manual delete node 0' - you need to actually visit this node to remove it. Note that, though you removed a node, the visual representation (red or green ball) that might have been created won't disappear until the time out occurs.
manual link <nodeid> <nodeid>	Creates a one-way link from first node to second node (only - reverse the node numbers to create the link back). If the link didn't exist before, it reports the calculated travel time from the first to second node. Example:   terrain manual link 130 134
manual unlink <nodeid> <nodeid>	Removes the one-way link from first node to second node (only - reverse the node numbers to remove the link back). Example:   terrain manual unlink 130 134 Note that, though you removed a link, the visual representation that might have been created won't disappear until it's time out.
stats	Dumps terrain statistics on the console. This is the same information you see when a map is loaded.
export	Exports 'comma separated file' with node tactical values into action\cgf\log\<mapname>.csv. These files can be read with a spread sheet application (MsExcel) for visualization and further analysis of the map tactical positions.
show path <nodeid>	Displays path from current position to specified node using green laser lines, and a sequence of node numbers on the console. The laser lines will be present for about 30 seconds. Example:   terrain show path 134 Note: if there isn't a path, no path is given. Make sure you have 'log visit' enabled otherwise CGF won't know your current node.
show stealthpath <nodeid>	Displays path from current position to specified node using green laser lines. The path is constructed with a preference for stealth and wall hugging. If the path doesn't show sufficient wall hugging, either there are few walls nearby, or you have not created sufficient links with the nodes close to the walls, or the walls need to be populated with nodes closer to the wall. Example:   terrain show stealthpath 134 Note: if there isn't a path, no path is given. Make sure you have 'log visit' enabled otherwise CGF won't know your current node. Important: only use this command when you haven't changed the nodes and links since you loaded the terrain files. Otherwise, the command causes a crash.
show lonely <maxnodes>	Displays the <maxnodes> nodes having the lowest number of neighbors. Nodes appear as red balls for 45 seconds. These nodes may require more linking (or, less likely, to have more other nodes closeby), but this need not be the case. Example:   terrain show lonely 25 Note that the maximum number of nodes made visible is 100.
show closest <maxnodes>	Displays the <maxnodes> nodes being closest to another node. Nodes appear as red balls for 45 seconds. Some of these nodes are better removed but be careful not to remove door, glass or ladder nodes (the ladder top sometimes need to be removed though). Example:   terrain show close 25
show infront <maxnodes>	Displays the <maxnodes> nodes visible and infront of you. Nodes appear as red balls for 45 seconds. It provides with you more info on the nodes created thusfar. Example:   terrain show infront 25 Note that there might be nearby nodes that you cannot see from your current position; as a result, these nodes won't appear. You may want to change position, and reissue this command to get a better overview.
show linkcandidates <radius>	Displays the links within the radius for which only a one-way link is present. Links appear as green laser lines. Some of these 'linkcandidates' indeed are valid links and you can add them by travelling between the two nodes. In other cases, the linkcandidate just denotes an 'unviable' link and you need not add it. Example:   terrain show linkcandidates 300 Note that many of the links shown aren't good candidates. Just focus on short distance links that are missing.
show locations	Displays the locations for the mission read (if any). Locations are displayed as vertical stacks of three blue balls. You can read a mission without executing it using the command 'mission read <missionname>.cgf'.
show insolid	Displays (on the console) a list of nodes that (in some strange way) have been created in a solid brush (and are not water, door or glass nodes).

5. Steps to Create an Initial Route File

list 1: console commands to start map in the correct way 
        for route file creation
      ---------------------------
      > set cgf 0
      > set teamplay 0
      > set deathmatch 1
      > set fog 0
      > set breakableglass 1
      > map mapname

You may want to enable god mode to prevent dieing when falling off a ledge. You also may want to set the brightness to the max so you can actually see where you are walking anywhere on the map.

After loading the map, CGF will report whether a route file was found or not.

Now prepare to start routing with sufficient information:

list 2: console commands to make sure you see the 
        results of your mapping effort
      ---------------------------
      > terrain log create
      > terrain log visit
      > terrain display node

Before we start mapping, it's good to know that for the CGF bots, not all locations are equal. Instead, some locations are very important for these bots to fight well:

• near wall locations (provide more stealth and cover)
• near edge roof locations (make for good defensive positions - plenty to see, cover when stepping back from the edge)
• potential sniper locations (in windows, dark corners, close to obstacles as rooftop air vents)

Because the automatic node creation won't create a new node very close to an existing one, it is important to wander via the near wall, roof edges, and potential sniper locations first.
(In case you forget to drop nodes somewhere, you can always drop them there manually).

Start mapping So move close to a wall start creating your first route file:

list 3: console command to actually start mapping
      ---------------------------
      > terrain map

When you haven't created any nodes for the map at hand, the 'terrain map' command will generate a number of nodes automatically:

• the node at your position
• nodes at door positions
• nodes at breakable glass positions

Now, have a walk and look at the console (and behind you) what's happening.

Saving the route file After having create a number of nodes and links, it's good to know how to save our new (but partial) route file. Just type:

list 4: console command to store the (partial) route file
      ---------------------------
      > terrain save

Because the map is "post-processed" (cleaned up) before saving, this may take a serious while - all this time, your Q2 seems to hang (but it is very very busy). Time for coffee, Mountain Dew or whatever keeps you going.

Since 'terrain save' takes some minutes, you won't like to save very often. However, since CGF is still beta (not really 24x7 software) you want to save often enough.

After saving, you can continue mapping, or leave the map (and maybe come back to the map later).
It's good to do this to see that we really have created a partial route file:

list 5: console command to leave and re-enter the current map
      ---------------------------
      > map mapname

After loading a map, make sure you use the commands from list 2 and list 3 to continue mapping.

Special Considerations Some map features require a few special actions. Currently these features are ladders and 'unreachable areas'.

Ladders Since, in Quake2, ladders are not entities but just brush texture attributes, ladders cannot be detected automatically by CGF. Instead, ladders can only be detected when you use them.
Because most mappers apply the LADDER texture on both the front and sides of the ladder, and because most players and bots climb the ladder front faster than the ladder sides, it is important that you approach ladders towards front, and look straight at them. Then, just jump into the ladder... The mapping code will detect the ladder and populate the whole ladder with nodes and links automatically.

If you manage to screw up and see nodes and links appear at the side of a ladder, or at the wrong side of the ladder (leading to the ceiling instead of the hole in the ceiling), then do the following:

list 6: console commands to remove (ladder) nodes
      ---------------------------
	  ' 1. disable node creation
      > terrain map
	  ' should say mapping disabled
	  ' 2. disable node linking
      > terrain link
	  ' should say linking disabled
	  ' 3. move to some ladder node
      > ... (you move)
	  ' 'log visit' should report you visit a ladder node
	  ' 4. remove ladder node
      > terrain manual delete node
	  ' should say node removed
	  ' 5. continue visiting all ladders nodes for this ladder
	  '    and remove them all
      > ... (you move and delete)
	  ' 6. move back from ladder
	  '    and enable mapping/linking again
      > terrain map
	  ' should say mapping enabled, linking enabled
	  ' 7. move back from ladder
	  '    and enable mapping/linking again
      > ... (move into ladder ther right way)

Unreachable areas Unreachable areas are tricky to map. To get to unreachable locations (for example, the central tower rooftop at Urban has a spawn point but cannot be reached otherwise; likewise, Actcity2 has a similar spawn point), use the noclip cheat command and move to that location.
However, before using the noclip command, make sure that you don't link your last visited node to the new node at the unreachable location. And as soon as you arrive, use noclip again to drop down to the floor, and enable linking again.

Summarized in commands:

list 7: console command to deal with 'unreachable location'
      ---------------------------
     > terrain link
	  ' should say linking disabled - otherwise, issue again
     > noclip
	   should say 'noclip on'
     > ... fly-move to 'unreachable location'
     > noclip
	   should say 'noclip off'
	   drop down to floor
	   a new node will be created automatically
     > terrain link
	  ' should say linking enabled
     > ... continue mapping

These commands enable you to get a reasonable 'draft' route file. In the remainder of this manual, you'll learn how to inspect, modify and improve your route file.

6. Steps to Inspect, Modify, and Improve the Terrain File

• verify 'terrain stats', and especially the link counts
• path verification
• use the 'terrain show' query functions

(The table reflects reported map statistics - note that you cannot simply divide the number of links by the number of nodes to get the average number of links per node: some of the links are bi-directional, whereas other are unidirectinal only):

mapname	nodes	links	avg. links / node
actcity2	475	1493	3.14
urban	755	2238	2.96
urban2	638	1962	3.08
city	951	2799	2.94
downtown	725	2105	2.90
p1_lightbeam	826	3180	3.85
monastery	759	2281	3.01
coverme	483	1497	3.10
riot	575	1725	3.00

This table demonstrates that 'urban' style maps in general have about 3.0 links per node. Map features that increase the link count are water, many 'low falling damage jumps' and many traversable obstacles. p1_lightbeam has all of these, and therefor scores more links per node.
If you notice that you have only 2.5 links per node (avg.), you know you need to run around some more with linking enabled!

Path Verification An effective way to both check and improve a route file is to display and traverse paths (adding and removing links where necessary):

• to key positions
• along key obstacles
• to random positions

list 8: checking and improving the nodes at a key positions
      ---------------------------
      ' move to position overlooking key position
      ' make visible any nodes around that position
     > terrain show infront 30
      ' nodes appear - move and repeat to make all
      ' relevant nodes visible
      '
      ' if node needs to be added, move to that position and
     > terrain manual drop node
      ' a node is added, and linked automatically to
      ' all other nodes that are easy to reach
      '
      ' you can check easily for nodes being too close to each other:
     > terrain manual show closest 30
      ' (show the 30 nodes being closest to another node)
      '
      ' if the nearby node is close, you might want to remove it
      ' move to the node (log visit says you when you reach it)
     > terrain manual delete node
      ' last visited node is deleted
      '
      ' make sure the new node is reached from all relevant
      ' nodes by moving to and from the new node

Key positions need not only be populated with nodes, they should also be reachable. So visit some key positions, write down their node id's, and move to some other location. Make sure that you have 'terrain link' enabled.
Then issue (for example, from current position 279 to see the path to node 701):

list 9: verify and improve a path
      ---------------------------
     > terrain show path 701
      ' links appear, and path nodes are visible at console
      ' for example,
      ' path == 279, 278, 579, 580, 581, 680, 701

The path listed on the console includes all nodes along the path from your position to the destination. If there's a shorter path possible (and if the bots are likely to make it without strafe-jumping, double-jumping or whatever tricks you can but they cannot do), just walk that path yourself, and the required links will be added.

However, if the path listed is an illegal one, visit the relevant nodes to see what number (580, 581, or ...) identifies what node. Then, manually remove the erroneous link as follows:

list 10: remove erroneous link
      ---------------------------
     > terrain manual unlink 580 581
      ' message stating 'unlinked 580 -> 581' should appear

Note that if this path was incorrect, other paths around or thru the obstacle are likely to be present. Move to other nodes and check all possible paths (from both directions) until you are sure all remaining links are correct.
At actcity2, I had to remove incorrect links that were created because the fence was not seen as blocking movement (which it does :) ). See the images above.

Next to key positions, key obstacles need to be verified (and improved or corrected). Typical candidates to cause trouble are: ladders / drainpipe / climbable lamp posts, doors, air ducts, crate stacks, and breakable glass.
Read more about these in the next section.

After having dealt with the key positions and key obstacles, I often try to display and follow paths to 'random' nodes (node id's 50, 100, 150, ... etc.) and will follow that path (or a shorter path while creating links).

use of additional commands (linkcandidates, closest, lonely) still to be written

7. Dealing with troublesome map features

• crate stacks
• doors / breakable glass
• fences
• ladders

Most of these problems can be worked around by repositioning nodes (manually create a new one, delete the old one), to enable the bots to successfully jump the stacks. Take care to position the nodes in the center of the crate (small crates, and large crates that are not mounted from the floor) and near but not over the edge for larger crates that are to be mounted from the floor. See the images below:

Doors / breakable glass typically cause the following problems:

• there might be paths that bypass a door / glass node (needed by the bot to understand how to operate the door / glass) [center image above]
• paths in the vicinity of a door include the door/glass node (urging the bot to try to open door or break glass while this isn't necessary) [right image above]
• paths going through the doors in opened position [left image below]
• too many nodes close to the doors, so (during patrol) bots restrict the movement space near the door

In a few cases, the surroundings of doors need to be populated with extra nodes. Since door nodes are (automatically) among the first to be created, you won't (automatically) drop another node closeby. However, without that new node, the path meant to by-pass the door will go via the door and onwards - the bots will open the door for no good reason (or pick a path circumventing the door node since they consider using doors as slow).

Thus, to have the bots use the terrain close to the door the way you would do, you need to add another node. See the image above for an example.

In the third case, after opening a rotating door, the bots need to be able to continue without having to pass thru the rotating door. See the image below for an example.

Finally, do also make sure there are not too many unneeded nodes just in front of door. This especially hampers bots during patrols - they do not see the stops very close to the door as a stop not to wait and assemble on.

Fences are another source of problems. CGF tries to create (in an automatic way) as many links as possible. In most cases, it will not create links through walls or through corners. However, it is far more likely that CGF will create links through open fences. You definitely want to verify paths close to the fence to see whether they pass thru the fence.

8. Easy construction of a first mission script defining locations

list 11: record locations into a mission skeleton
      ---------------------------
      ' move to key location (to be labeled 'casino_entrance')
     > location casino_entrance
        says location added 
      ' repeat step for other key locations
      ' ...
      ' and save mission skeleton to file 
      ' (file labeled 'mapname_test.cgf')
     > mission write mapname_test.cgf
        says mission written
      ' now quit and complete the skeleton into a test mission 

list 12: load, display, add and save mission locations
      ---------------------------
      ' load appropriate mission (should compile without errors)
      ' here, we load actcity2.cgf
     > mission read actcity2.cgf
        says reading mission done 
      ' now display locations
     > terrain show locations
        says number of locations displayed
      ' shows locations as blue 3 ball stacks
      '
      ' ... now move and add your own
     > mission location my_own_locations
      ' ...
     > mission write actcity2.cgf
        says mission written

9. Debugging terrain file problems in missions

• log files (in developer mode only)
• retrieve the "bot-in-troubles" plan of action

Log files are used to report obvious problems during mission start and mission execution. They can be found in the action\cgf\log directory. Log files are plain text files, and are given the name of the map: <mapname>.log.
Log entries are made for every mission, and appended at the bottom of the file. If the log file grows too large, you can throw it away, or remove large parts of its contents. For performance reasons, log files are only written when you run CGF in developer mode. Developer mode is enabled by a 'set developer 1' in the .cfg file used to launch the bots.

Commercial break: Borderfield's CGF Mission Editor has built-in support to enable developer mode (in the Options, AQ2 Settings menu) and to view the log file for the current mission (in the Project menu, View Log option).

With the CGF Launcher, before launching the mission, select Edit Script, and add 'set developer 1'.

The log file entries for a specific mission might look like this (I screwed up a location position by writing down incorrect coordinates, and had the bots move to an unreachable roof):

mission# |    time | mission = "actcity2_sample.cgf"
=========|=========|========================================================
00000000 |     2.4 | mission started
00000000 |     2.4 | location "motel_lobby" incorrect (no nearby node)!
00000000 |     2.4 | location definitions verified: 1 errors!
00000000 |    66.0 | no path from 448 to 290

When a specific bot is in trouble (he's stuck), you might want to get into his brain and at least see what's on his mind. That's possible with CGF - you can dump a bot's current plan into the action\cgf\log directory as follows:

list 13: dump a bot plan for later analysis
      ---------------------------
      ' while running a mission where bot Alpha-1 seems stuck
     > plan Alpha-1
      ' now dumps plan into file 
      ' action\cgf\log\plan_Alpha-1.txt

SubPlotAction "Move To Location" [
  Sequence
  [
    NormalMoveToLocation(-88,1199,24) // at node = 259
    NormalMoveToLocation(-159,1121,24) // at node = 281
    NormalMoveToLocation(-129,973,24) // at node = 241
    NormalMoveToLocation(-149,933,24) // at node = 288
>>  NormalMoveToLocation(-16,1380,408) // at node = 289
    NormalMoveToLocation(-115,1378,408) // at node = 290
    NormalMoveToLocation(-72,1414,408) // near node = 290, d = 55.6987
  ] // Sequence
] // SubPlot

Note that if you dump the bot plan when the bot is repeatedly failing to tackle some obstacle, the chevron symbol is likely not to point to the problematic movement. In that case, you can write down the problematic path (the 5 nodes preceding the chevron, and the 5 nodes succeeding it) and inspect that path.

10. Requirements for Terrain/Route File Distribution

• the .zip containing the route file to install like any other Action extension;
• the .zip to contain solely the essential route files (the <mapname>.srp file and the <mapname>.exp file only when you've played a set of over 50 varying missions on the map using this exact .srp file);
• the .zip to contain a .txt file that describes who you are, where to find you (email) for thanks, comments and suggestions, and any problems you couldn't solve;
• the .zip to contain a sample mission defining the key locations and areas, so they themselves can write missions based on your route file. This sample mission can be the test mission you have used to verify the bots navigation in the map;
• the route file to be of good quality (see below). They exspect you not to release the route file until it's good enough;
• the .zip to contain a fog preferences file fitting the map. The route file will probably enable the gamer to play CGF on that map for the first time - he might as well start with some decent fog settings.

In more detail, a .zip route file archive has the following contents for a map (for example, actcity2):

• .\terrain\actcity2.srp
  the only essential route file
  
• .\terrain\actcity2.txt
  text describing file, author and other relevant info
• .\terrain\actcity2.exp
  recorded combat experience (only when you've ran over 50 varying missions using the exact .srp file distributed, otherwise, leave it out)
• .\missions\actcity2_sample.cgf
  sample / test mission
  
• .\cgf\fog\actcity2.fog
  (text) fog preferences file

=======================================================================================
Title                   : CGF Terrain file for Actcity2
Filename                : actcity2_cgf_terrain.zip
Version / Date          : 1.0 / August 25, 1999
Game                    : CGF for Action Quake 2
Author                  : William
Email Address           : [email protected]

=======================================================================================
* Construction *

Base                    : -
Construction Time       : 3 hours
Limitations / Bugs      : secrets doors not mapped (since bots cannot use secret doors)

The sample mission, serving both as a base for further mission development and as a demonstration of the route file's quality, should define:

• all relevant locations, preferably by a recognizeable name (augmented by some ASCII art map that explains what you mean by the 'just_underneath_brown_tower')
• all relevant areas
• a single force, containing a single team, containing a single bot member. For example:

  
  force "Spec Ops"
  {
    team "Breach Team Alpha"
    {
      npc "Alpha-1" "male/sabotage"
      {
  	  weapon "Dual MK23 Pistols";
  	  item "Lasersight";
  	  ammo "M4 Clip" = 2;
  	  skill          = 2;
      };
    };
  };
  

• a single objective (since at least one objective is required). For example:

  objectives
  {
    failure
      ("Spec Ops",
       "\nyawn...\nthis is taking way too long"
      )
      = timeout(300)
        -> {"actcity2_sample.cgf"};
  };
  

• a single plan for the sole team, inserting the bot somewhere, and having the bot deal with all important obstacles. Typically, that means, the bot handles rotating doors from the side the door opens to, and that the bot uses all ladders present. For example (as used for p1_lightbeam):

  plan "Breach Team Alpha"
    {
      insert at indoor_meetingroom using "column";
      wait until ready;
      wait 5;
  
      moveup to outdoors_wall_nearwaterladder using "column";
      wait until ready;
      wait 5;
  
      moveup to indoor_meetingroom using "column";
      wait until ready;
      wait 5;
  
      moveup to indoor_pcroom using "column";
      wait until ready;
      wait 5;
  
      moveup to vacant_camper_parkingstop using "column";
      wait until ready;
      wait 5;
  
      moveup to nearcamper_slopingroof using "column";
      wait until ready;
      wait 5;
  
      moveup to indoor_meetingroom using "column";
      wait until ready;
      wait 5;
    };
  
  

  You would observe the bot using the AQ2 built-in chase cam. The additional 'wait 5' delays make it easier to see what the bot is doing.

A CGF terrain file is of good quality when all the above mentioned conditions have been met, and:

• the bot successfully (and consistently) manages to execute the plan in the sample mission
• all relevant parts of the map are covered with nodes and links. On average you'll have about 2.8 avg. links per node on flat maps, and > 3 avg. links on maps featuring many height levels or water.
• when run in 'developer' mode ('set developer 1'), the most recent log messages for the map (in cgf\log\<mapname>.log) do not include any errors.

A fog preferences file (action\cgf\fog\actcity2.fog) would look like this:

// format: mapname density fog_type red green blue begin end
//       - density: 0.00 -> no fog
//         density normally in range 0.05 ... 0.20
//       - fog_type: 0 = exp     (fog linear with distance)
//                   1 = exp2    (fog increasing more than linear)
//                   2 = linear  (fog linear within specific begin-end range)
//       - red/green/blue in range [0.0 .. 1.0]
//       - begin:    start distance for linear fog (no fog within begin dist)
//       - end  :    end distance for linear fog (no vision beyond end dist)
actcity2     0.10  2  0.50 0.50 0.45 200 1600

11. Additional Credits

12. CGF Terrain / Route File Creation Change Log