///////////////////////////////////////
// lOkO bot beta .14 September, 2005
///////////////////////////////////////

Creating Routes for the lOkO Bot
--------------------------------

CONTENTS:

Preface

1.0 Routes - Nodes, Paths and Links

	1.1 What's a Node

	1.2 What's a Link 

	1.3 More on Nodes...

		1.3.1 Node Types

		1.3.2 Loading An "Un-noded" Map

		1.3.3 How Bots Use Nodes and Links

	1.4 Quake Units and Distance, Height, etc.

2.0 Generating Nodes and Links

	2.1 The addnode Command

	2.2 The make_paths cvar

	2.3 The addlink and and 2way  Commands

	2.4 The removelink and and 2way Commands

	2.5 Client Commands for Nodes and Links

	2.6 Map Analysis Client Commands

	2.7 Server Commands For Nodes and Links

		2.7.1 sv savenodes

		2.7.2 sv rebuildgraph

		2.7.3 sv printnodes

	2.8 The debug_pathing cvar

	2.9 More on the cvar make_paths 

3.0 Optimal Procedure for Generating Routes

	3.1 Adjust Nodes For World Items

	3.2 Manual Placement of Strategic Nodes 

	3.3 Add Nodes For World Items

		3.3.1 Door Bottom and Door Top Nodes

		3.3.2 Shoot Nodes

		3.3.3 Door Open Nodes

		3.3.4 Visible Nodes
		
		3.3.5 Notvisible Nodes

		3.3.6 Train Nodes

			3.3.6.1 Getting On the Train

			3.3.6.2 Getting Off the Train

	3.4 Walking The Map To Generate Nodes/Links

        3.5 Identify Unlinked and Unreachable Nodes

	3.6 Adding Shoot Nodes for Secret Doors

	3.7 Relocate Nodes above Teleporters
 
	3.8 Tweaking The Path

4.0 Workarounds

	4.1 Jump Pads

	4.2 Push Buttons

5.0 Other Advice

	5.1 Deep Thoughts about The Path
	
	5.2 Ways to Test The Path

	5.3 Optimal Path Creation in Large Open Areas

	5.4 Jump Node Additional Notes

	5.5 Grapple Node Additional Notes
---------------------------------------------------------------------------

Preface
-------
Before attempting to create routes on a map for the bot to follow, read 
this entire document. 

The lOkO bot can expertly navigate a level only if it has knowledge of the level, 
which is provided by the nodes and links created between nodes by the route 
builder. 

Other bots for Quake series games and games of that ilk may roam the level on 
their own without nodes, learn the map by mimicing player movement, analyze the 
bsp file to discern the architecture of the level or some other method which requires 
little input from the user; some of them play extremely well on lots of maps but 
performance on some maps is somewhat less satisfying or even poor or unplayable 
as the bot cannot navigate the level because it does not understand how to use
objects on the level that players use to move around the level, like ladders, 
doors, jump pads and wind tunnels, platforms, moving trains, etc. With most of
these bots there's little or nothing you can do to influence the navigation
behavior of theses bots, either they play the level well or they don't.

From the start, the intention has always been for the lOkO bot to rely on
routes built for it rather than autonomous navigation of the level; a viable
route verified by the route builder who provides the bot with intimate 
knowledge of the level so it can expertly navigate it. Commands are provided
for building, editing, analyzing and testing bot routes; the route builder has
complete control over how the bot navigates, nothing is hidden or unknown, no 
magic black box black hole optimization algorithms, everything can be edited
and fixed. 

Precise navigation requires node placement and path creation with knowledge
of how the bot uses the node path. "Run around the level" won't cut it. However, 
if you follow these instructions you should be able to make good routes.



1.0 Routes - Nodes, Paths and Links
-------------------------------------
The lOkO bot uses nodes and links to navigate a level so it can acquire 
stuff it needs, find places to flee to, find air when drowning, follow a 
path to a sound and lots of other stuff. The sequence of nodes a bot needs
to follow to get from one place on the map to some other place is referred
to as a path; route is a synonym for path. The process of placing nodes and
creating node routes on a level is called pathing the level, aka routing the
level.

1.1 What's a Node ?
-------------------
A node is a data object that stores the coordinates of a particular location the 
bot can move to, perhaps some action the bot should perform at the location 
(swim, go up a ladder, jump, use a platform, etc.), maybe identifies some weapon, 
teleporter or other item of interest at the coordinates, and the other nodes it 
can move to from the node's location. A node does not use a Quake2 entity so it 
doesnot exist on the map, nodes exist only in the node table in memory; a bot 
determines his current location coordinates then looks at the node table to find 
the node closest to his location coordinates. A temporary entity is spawned by some 
of the node commands to show node locations. 

1.2 What's a Link ?
---------------------
A link is the one-way connection from a node to an adjacent node that can 
be sucessfully navigated to. Each node can have up to 8 links, meaning
it can navigate to up to 8 other nodes from the node. Think of it like 
this: rather than storing a set path connecting many nodes together , individual 
noodles are placed from each node to any other individual nodes the bot can get 
directly to from there. 

Pre-defined paths are not stored, only links from nodes; when a level is loaded 
the individual links are loaded into a "graph" in memory and when the bot 
wants to navigate somewhere every possible combination of links is tested to 
determine the shortest path from the bot's current location to the desired 
destination. The path is stored in the graph in memory until another level 
is loaded or you exit Quake2. The individual nodes (and associated links) 
are stored in a file along with info about the items on the level when you run 
the savenodes server command.



1.3 More on Nodes...
--------------------
An individual node is identified by a unique node number. The first node 
created is node 1 (node 0 exists but is moved off the map). There can be 
up to 999 nodes generated for a any level (the largest amount of nodes I've 
ever generated for a level is 992 nodes for map city64). Each node can have up 
to 8 links (8 other nodes connected from it).


1.3.1 Node Types
---------------- 
Nodes are catagorized by 'type', ie. what action should occur to reach the node, 
how to behave when at the node or if an item is at the node. Here are all the node 
types; a number is used to signify what type of node a node is:

   Type
   Number   Node Type   Action
   ------   ---------   ---------------------------------------
   0        move        A garden variety node. No item is associated with
                        the node. The bot has to walk or run to the node

   1        ladder      NOT USED !! See the laddertop command ! 

   2        platform    Either the bottom or top of a platform; tells the
                        bot he should not move until he rides the platform          
                        to the top node. Platform nodes are created 
                        automatically when an un-noded map is loaded.
                        A platform is quake2 func_plat entity, never
                        a func_door or func_train.

   3        teleporter  teleporters and teleporter destinations; the bot tries
                        to get really close to this node before he determines
                        he 'made it' to the node. Also, the teleporter_touch
                        function tells the bot he's 'made it' to the next
                        node. Teleporter nodes are created automatically when 
                        an un-noded map is loaded.

   4        item        signifies something the bot can pick up and use is
                        at this node; the bot can walk, run or swim to this
                        node. Item nodes are automatically created for all
			deathmatch items present on the map when an un-noded 
                        map is loaded except CTF techs and "ancient heads" are
                        omitted.

   5        water       the node is under water or slightly above water;
                        the bot must swim up or down to it if it's underwater.
                        The bot will try to head for a close water node 
                        if he's on fire.

   6        grapple     indicates the bot must use the grapple to reach this 
                        node (actually, bots use the off-hand hook now).

   7        jump        the bot must jump to reach this node

   9        doorbottom	the node indicates the bottom position of a door the
                        acts like a platform; the node should by placed just
                        above the door when it's at it's "lowered" position.
                        Must be added manually with the addnode command; only
                        use for a quake2 func_door entity, never func_train.
			You can also use this node type for a func_door_rotating
			that operates in the X axis, see the 'finddoor' command.


   10       doortop     the node indicates the top position of a door the
                        acts like a platform; the node should by placed just
                        above the door when it's at it's "raised" position.
			Must be added manually with the addnode command; only
                        use for a quake2 func_door entity, never func_train.
			You can also use this node type for a func_door_rotating
			that operates in the X axis, see the 'finddoor' command.


   11       shoot       the node is behind a secret door; the bot shoots 
			towards the node until he can "see" the shoot node 
			when the door opens; you can also use a shoot node
                        to tell the bot to shoot shoot-able buttons.
			Must be added manually with the addnode command.

   12       dooropen    this type of node is only required for Action Quake2
                        maps; bots will know to issue the "opendoor" command
                        if they detect the nearest door to the node is closed.
                        The node indicates a door that acts as an opening
                        which slides/rotates open and closed. For rotating
                        doors a dooropen node should be placed on the side
                        of the door the door rotates to, sliding doors need
                        1 dooropen node placed on either side of the door.
			Must be added manually with the addnode command; only
                        use for a quake2 func_door entity, never func_train.

   13       train       the node indicates the bot must either get on or ride
                        a func_train entity. When getting on a func_train, the
                        bots wait for the train to move directly under the train
                        node, while riding a train the bot always stays in the
                        middle of the train. Must be added manually with the 
                        addnode command. If the bot has to jump to get on the
                        train, see the node type 'notvisible' below

   14       visible     the bot doesn't navigate to the location of this node;
                        it waits at it's previous node until the visible type node 
                        is "visible" (a line can be drawn from the bot to the visible
                        node without hitting any bsp obstructions), then proceeds
                        to the node after the visible node. Handy when the bot
                        needs to wait for a bsp object (func_rotating, func_door,
                        func_train, etc.) to move out of the bot's way before the bot
                        continues on it's route. Must be added manually with the 
                        addnode command.

   15       notvisible  like the visible node, except the bot waits for the node to
                        be *not* visible, ie. the bots view of the notvisible node is 
                        obstructed. Used when a bot must wait for a bsp object to be in 
                        a certain location before the bot proceeds, like when a bot 
                        must jump on to a func_train, place a notvisible node under the
                        train at a point when is obscured by the moving train it's safe 
                        to jump on the train, and place a jump node over the train. 
                        Must be added manually with the addnode command.


1.3.2 Loading An "Un-noded" Map
-------------------------------
When you load a level that does not have a link file, a new node is 
automatically created at the location of every weapon, item (ammo, health, 
armor, powerup, etc., but NOT techs), teleporter and teleporter destination;
a node is also placed at both the bottom and top of platforms with 
a link between the bottom node and top node. An item table is created in
memory to store the class name and item node associated with each item 
initially spawned on the map. Then a human must walk around the level 
creating more nodes and links until the all navigable parts of the level 
are covered with nodes. The human can also add nodes and links, remove
links and move nodes at the console using a bunch of commands explained 
later.

If you are going to build routes for a native Capture the Flag make sure the server
cvar ctf is set to 1 before the level is loaded so item nodes are automatically
generated for the red and blue team flags.


1.3.3 How Bots Use Nodes and Links
------------------------------------
The bot uses nodes and links like this:
 
1. He picks someplace he wants to navigate to (an item he wants, the last 
   place he saw an enemy, the location of a sound another player made, etc.)

2. He determines the closest node to himself (his 'current node') by comparing
   his current location against the locations of all the nodes in the node table 
   in memory.

3. He determines the closest node to his desired destination (his
   'destination node') by comparing his destination's location against the 
   locations of all the nodes in the node table in memory.

4. The link graph is analyzed to determine the shortest path of nodes between 
   his current and destination nodes; the sequence of nodes that need to be 
   followed to reach his destination are stored in the link graph.

5. The bot looks in the graph for the next node in the path (his 'next node') 
   to head to and starts to move towards it (his 'next node'); how he moves 
   (walk/run, swim, grapple, jump) is determined by the next node's node 
   type.

6. When he gets close to his next node (how close depends on what type of 
   node it is) his next node becomes his current node and he consults the 
   link graph to get his new next node. He then heads towards his new 
   next node.

7. Step 6 is repeated until his current node is his destination node.


1.4 Quake Units and Distance, Height, etc.
------------------------------------------
   The quake2 world is defined mathmatically; distances, sizes, speeds, 
acceleration, etc. are all defined and measurable, but not in everyday units 
of measure such as inches/feet/miles or centemeters/meters/kilometers but as 
"Quake Units"; the distance from a bot's position to a nearby object might
be expressed as 150 quake units away. It's difficult to estimate distances
on a map in terms of quake units, so I've developed a new unit of measure
called the Quake Guy Height, or QGH. Now anyone who has played any 
Quake2 deathmatch has seen the standard iD male player model a zillion times 
at various distances, so it is a convenient reference size. The standard iD
male model is close enough to 64 quake units, so 1 QGH is 64 units, 2 QGH
is 128 units, 1/2 QGH is 32 units, etc. By no coincidence, most map textures
and geometric shapes are created in sizes of 32, 64, and 128 quake units.
Finally, 128 units is the "node density" used to populate an unnoded area of
a map; when you "path" a map by navigating around the map creating nodes and
links, if no node is within 128 units a new node is created at your 
location. So now you can estimate how far you can walk into an unnoded area
before a new node will be created, about 2 QGH.


2.0 Generating Nodes and links
--------------------------------   
After the creation of the initial nodes for all items, platforms and teleporters
automatically generated for an unpathed level, nodes can be created two ways:

2.1 The addnode Command
-------------------------
The 'addnode' command creates a node just below your current origin (your 
origin is a point in the middle of your QuakeII model body). You can further 
qualify the type of node by adding the node type to the command; 'addnode 5' 
adds a water node at your current location. The default node type generated 
when you don't specify a node type is 0 (type move). The node initially has 
no links associated with it. See 1.3.1 Node Types for type of nodes to add;
run the 'shownodetypes' to show the node type number and description of
all node types.

2.2 The make_paths cvar
----------------------------
When the server cvar make_paths is set to 1 humans navigating the map
will have there movement analyzed by the game dll. The dll generates a new node 
whenever a human is more than 128 quake units away from an existing 
node. The dll also generates a new link when a human sucessfully navigates
from one node to another.

/////////////////////////////////////////////////////////////////////////
*** To generate good routes you should use a combination of 2.1 and 2.2; 
*** see section 3.0 Optimal Procedure for Generating Routes !!
/////////////////////////////////////////////////////////////////////////

2.3 The addlink and and 2way  Commands
-----------------------------------------
You can manually create a link from one node to another using the 'addlink' 
command . The '2way' command creates a pair of links between two nodes.

Examples:

    addlink 24 50     - add a link from node 24 to node 50

    NOTE: all links created with the addlink command are ONE WAY LINKS; 
    addlink 24 50 creates a link from node 24 to node 50 BUT NOT from 
    node 50 to node 24 ! Run the addlink command again to link create a 
    link from node 50 to node 24. 

    2way 24 50  - creates a 2 way link between node 24 and node 50, ie. a 
    link from node 24 to node 50 *and* a link from node 50 to node 24.

2.4 The removelink and cut Commands
-----------------------------------
You can remove the link from one node to another with the 'removelink' command. The 
'cut' command removes all existing the links between two nodes. "rl" is a synonym for 
"removelink".

Examples:

    removelink 50 53  - removes the link between nodes 50 and 53
    or
    rl 50 53
 
    NOTE: removelink works like addlink; removelink 50 53 would NOT remove 
    the link from node 53 to 50 if it exists.


    cut 50 53   - removes the link from node 50 to node 53 AND the link 
        from node 53 to node 50 if either link exists.



2.5 Client Commands for Nodes and Links
----------------------------------------

Run these commands from the console; you might want to bind a key to certain
commands; since the lOkO mod does not support single player mode against 
monsters I suggest you bind the following keys to these commands:

    bind F11 "findnode"		// find the closest node within 128 units
    bind F5  "addnode 0"	// add a node of type MOVE at your location
    bind F6  "viewpos"		// report your current 3d coordinates
    bind F10 "addnode 5" 	// add a node of type WATER at your location



findnode - finds the closest reachable node to you within a spherical radius 
of 128 units; the node number, type of node and the coordinates of the node 
are displayed on the console; a colored sphere is drawn at the node's origin. 
If no node is within 128 units -1 is returned. "Reachable" means an imaginary 
line may be drawn from you to the node and no solid object (or window) is hit; 
the node is not necessarily in front of you and may be above or below you.


viewpos  - this is the iD command that displays the coordinates of the  
point your player model's "eyes" are viewing the world from. The coordinates 
of your view position are displayed on the console as well as your view angle 
in degrees.


shownode <#> - shows the node specified by <#>; the node number, type of node 
and the coordinates of the node are displayed on the console; a colored 
sphere is drawn at the node's origin. "sn" is a synonym for the shownode command.


linksfrom <#> - shows all nodes that are links from the node specified by 
<#>; the node numbers, types of nodes and the coordinates of the nodes are 
displayed on the console; a colored sphere is drawn  at each linked node's 
origin. "lf" is a synonym for the linksfrom command.


linksto <#> - shows all nodes that are links to the node specified by <#>; 
the node numbers, types of nodes and the coordinates of the nodes are 
displayed on the console; a colored sphere is drawn  at each linked node's 
origin. "lt" is a synonym for the linksfrom command.


movenode <#> <x> <y> <z> - changes the location of the node specified by 
<#>; <x>, <y> and <z> are the coordinates to move the node to. 
BE CAREFUL - there is no error checking here, you can move the node right 
off the map if you're not careful (this is sometimes useful if you want to 
discard a node). If you omit the coordinates the node is moved to location 
<0,0,0>.


changenodetype <#> <type> - changes the 'type' (move, jump, water, etc.) 
of the node specified by <#>, ie. 'changenodetype 27 7' changes node 27 to 
a jump node. You can change any node to any type EXCEPT type item (4), 
type teleporter (3) or type platform (2). You should never have to change 
any node from/to type 2 (platform) or type 3 (teleporter).
"nodetype" is a synonym for "changenodetype"

addcrouchflag <#> - adds a "flag" to the node specified by <#> that indicates 
the bot must crouch down to reach this node. "addcrouch" is a synonym for 
"addcrouchflag". You only need to add a crouch flag to a node when it's not obvious 
to the bot he must crouch, typically one of four cases:
  a. The terrain the bot is travelling slopes up or down; the bot has trouble
     detecting the need to crouch when the surface he's travelling on is not
     level ground.
  b. The opening the bot must crouch thru has a small "lip" protuding from the
     ground upward; for example a teleporter the bot must crouch to reach
     may have a teleporter pad which causes the bot to think crouching won't help
     reach it.
  c. The bot needs to crouch to get thru an opening and then fall to the ground
     (the opening on the other side of the wall is vertical drop, like a cliff).
  d. The bot needs to crouch underwater (most of the time he knows to crouch but
     sometimes he screws up).

You can also use a crouch flag on a node when a bot should slow down when 
approching the node:
  a. The bot must make a sharp turn of 90 degrees or more when navigating
     a narrow path high above ground with steep cliffs on both sides or 
     when navigating perpendicular girders on a building under construction.
  b. The must "fall" to a narrow ledge from above the ledge; on q2dm1 a node
     adjacent to the hyperblaster has a crouch flag so bots slow down when they
     navigate from the top of the platform off the ledge to the hyperblaster. 


removecrouchflag <#> - removes the existing crouch flag from a node.
"nocrouch" is a synonym for "removecrouchflag".

crouchflags - displays on the console the numbers of all nodes which have 
crouch flags.

shortpath <fromnode> <tonode>  - shows the first 15 nodes of the shortest 
calculated path from <fromnode> to <tonode>; the node numbers are displayed 
on the console and a colored sphere is drawn at each node's origin. The
server command rebuildgraph must be run before any new node/links are
considered to be a potential path. "sp" is a synonym for the shortpath command.


offmap - lists all nodes whose xyz coordinates fall outside the quake2 world, 
ie. one or more coordinate is greater than 4096 or less than -4096. The node 
number, node type and xyz coordinates are displayed on the console; only the 
first 15 nodes that are outside the map are reported.
NOTE: you can NEVER remove a node from a level, but you can render it useless 
(unknown to any bots) by removing all links to and from the node (removelink 
command) and moving it off the map; 'movenode 86 10000 0 0' moves node 86 off 
the map (the location of coordinates 10000,0,0 can never be reached on any 
Q2 map as the dimensions of the level must fall between -4096 and +4096 in 
each direction). When you load an unpathed level node 0 is always created and 
moved off the map to coordinates 10000,0,0.


unlinked <skip#> - lists the node number, type of node and and xyz coordinates 
of any node that does not have a link FROM it; a colored sphere is drawn at the 
location of the node. Without an arguement, the unlinked command reports on
the first 15 unlinked nodes; if you specify an integer as an argument 
(<skip#>) ie. 'unlinked 15' the command will skip the specified number of nodes
and report on the next 15 unlinked nodes.

NOTES: while unlinked nodes are ignored when creating/calculating shortest 
paths, if the bot decides he wants to go someplace and the closest node to 
him is unlinked he won't be able to calculate a path to *anywhere* (I must 
eventually write code to fix this ...) so you should run the unlinked command 
to identify unlinked nodes and link them or move them off the map; in certain 
cases, like when the only way to get to a node is by rocket jumping (which 
the bot cannot do) you can leave the unlinked node as is because the bot 
should never be able to reach the node anyway.

cantreach <skip#> - lists the node number, type of node and and xyz coordinates of any 
node that does not have a link TO it; a colored sphere is drawn at the 
location of the node. The first 15 nodes that can't be reached are reported; if you 
specify an integer as an argument  (<skip#>) ie. 'cantreach 15' the command will skip 
the specified number of nodes and report on the next 15 nodes that can't be
reached.

laddertop - this command manually places a node of type jump a certain distance 
above your origin (the middle of your player model); issue this command when 
STANDING ON THE GROUND JUST IN FRONT OF THE TOP of a ladder (note: ladder 
nodes are obsolete !).

nodesum - list on the console the count all the node types on the level

shownodetypes - this is a utility command that displays on the console all the 
legal node types and their descriptions.


2.6 Map Analysis Client Commands
---------------------------------------
These client commands provide useful information about Quake2 game items and
bsp entities on the map. Parameters are all integer values.


findstuff <radius> - prints on the console the class name and position of every 
game item and bsp object around you within a radius of <radius> units. Be aware that 
not all teleporter destinations are obviously marked with a teleporter destination model; 
this command will tell you if one is near. Also, what looks like a platform really 
may be a 'func_door' or 'func_train', this command will tell you what it is.


finddoor - finds the closest func_door or func_door_rotating within a 512 unit radius 
of your position and reports it's state (at bottom, going up, etc.) as well as info
contained in the door's spawn flags (starts open, crusher, x-axis, reverse, toggle).
A green colored sphere is drawn at the reported door's position.


findbutton - finds the closest func_button within a 512 unit radius of your position 
and reports it's moveinfo state and the button's health.A green colored sphere is drawn 
at the reported buttons's position.


findplat - finds the closest func_plat within a 512 unit radius of your position 
and reports it's moveinfo state. A green colored sphere is drawn at the reported 
platform's position.


showalltele - prints on the console the location of each teleporter and the location
of it's target destination; a green colored sphere is drawn at each location and 
a blue debug trail is drawn between each teleporter and it's target destination.


pvis <x1> <y1> <z1> <x2> <y2> <z2> - reports on the console if the 3d coordinates on 
the map specified by (x1,y1,z1) and (x2,y,z2) are "visible" to each other. A colored
sphere is drawn at the two specified coordinates. Useful for determining where to
precisely place shoot nodes on a shootable button and where to place visible nodes 
and notvisible nodes.


secretdoors - reports on the console the location of each secret door on the map;
a colored sphere is drawn at the door's location. Note that true secret doors have a
classname of func_door, a use function of door_secret_use() and health > 0; "simulated"
secret doors can be made from trigger_multiples and other bsp objects, these are 
not reported.


showpush - prints on the console the location of each trigger_push on the map; a green 
colored sphere is drawn at each location

itemsum - prints on the console the classname and quantity of each game item in the
item table generated or loaded when the level was loaded.

2.7 Server Commands For Nodes and Links
-----------------------------------------

The following commands are coded as server commands so clients connecting
to your machine cannot maliciously save nodes to disk or rebuild the link
graph; clients can, however, run any of the previously mentioned node manipulation
commands; they were left as client commands for the convenience of the route maker.


2.7.1 sv savenodes
------------------
As mentioned above under 'More on Nodes...' if you load a level that does not 
have an existing node file new node and item tables are generated. After you 
have finished pathing the level you must run the server command savenodes to 
store the node and item tables to a file on disk:

A file in the directory quake2\lokonav is created to store the link file 
named from the map name plus the extension 'ndl' ie. q2dm1.ndl. If you fail 
to save the link file you will lose it when you load another level or you 
exit Quake2. The saved link file is loaded and used by bots the next time
the level is loaded. The item table is also saved to disk in the link file
by sv savenodes command and this item table is used by bots each subsequent time 
the level is loaded, regardless of extra items added or items banned.


2.7.2 sv rebuildgraph
---------------------
This will re-build the link graph in memory without having to reload the 
level; don't forget to run 'sv savenodes' to store the nodes & links to 
disk.
When a level with an existing link file is loaded, a graph of all existing 
links is automatically created. If you add or remove nodes or links 
the graph must be updated before the bots will be aware of the new nodes and 
links. You can save the nodes with 'sv savenodes' and re-load the map and a new 
graph will automatically be generated, or issue the server command 
rebuildgraph' to create an updated graph.


2.7.3 sv printnodes
-------------------
The server operator can create a readable text file of the node table and 
item table in use with printnodes command. A text file is created on the server in 
the quake2\lokonav with the name of the map and the file extension '.ndp' ie. 
'q2dm1.ndp'. The text file lists the contents of the node table (node number, 
node type, xyz coordinates, other nodes that are linked from it) and the item 
table (item number, item index, node number at location, item classname). 


2.8 The debug_pathing cvar
--------------------------

Setting the server cvar debug_pathing greater than 0 will display additional 
information on the console about the nodes you create and links you generate.

a. Each time you add a node, a message will be displayed on the console 
showing the node number added and it's node type; a colored sphere will be 
drawn at the node's origin.

	Example:     Node 112 added: type Move

b. Each time a link between two nodes is created a message will be 
displayed on the console.
 
	Example:  Link :  126->128

indicates a link was created from node 126 to node 128.

If debug_pathing is set greater than 1 and the make_paths cvar is set 
greater than 0 then each time you get close enough to a node to consider
the node 'visited' a white sphere is placed at that node; this results in
a trail of white spheres representing the path being created or followed
by the human pather.


2.9 More on the cvar make_paths ...
--------------------------------------
Whenever this document refers to 'auto' pathing, nodes being 'auto' dropped 
or 'auto' links it means the nodes and/or links were created automatically 
by the pathing code when a human navigated the map when the cvar make_paths 
was set to 1. Here's how it works when make_paths is 1, assume 1 human
client is spawned on the map:

   a. Every 1.5 seconds the dll executes code that looks for the 
   closest reachable node to the client within 128 unit spherical radius 
   If no node is found then a new node is created with it's origin at the 
   client's position at waist level. The dll stores the closest node number 
   as the client's current node. The dll code also checks if the player his 
   pressed the jump key or pressed the fire button while using the ctf grapple 
   and stores this info for future reference. 

   b. After another 1.5 seconds has elapsed the code again checks for 
   the node closest to the the client:

       If the closest node is his current node then nothing is done.

       If the closest node is not his current node then a link is
       created from his last current node to the new closest node and the
       closest node now becomes his current node.

       If no node is found within a 128 unit spherical radius a new 
       node is created at the client's position, a link is created linking 
       his old current node to the new node and the new node becomes his 
       current node.

    c. Step b repeats until the server operator sets make_paths is to 0. 

The type of node created when make_paths is 1 depends on how and where 
the node is generated. The only types of nodes created when make_paths is
set to 1 are move, water, jump and grapple.

    If the client has not pressed the jump key and is on solid ground a node
    of type move is created.

    If the client has not pressed the jump key and is in water then a node of
    type water is created.

    If client has pressed the jump key and lands on solid ground or in water
    a new node of type jump is created if no other jump node is close, even
    if a node of type move, water or any other type is close.

    If the client uses the ctf grapple then a node of type grapple is placed
    where the hook of the grapple strikes a solid surface (if no other grapple
    nodes are close to the impact point), a link from the last node the client 
    was closest to when he fired the grapple to the new grapple node is created
    and the client's current node is set to the new grapple node. When the
    client subsequently reaches solid ground or water a link is created
    from the grapple node to the closest move, jump or item node to the client 
    (created if no non-grapple type node is close).

Note that if the client has not pressed the jump key and is not using the
ctf grapple for navigation he will create links between existing
nodes of any type except node shoot, visible and notvisible.


3.0 Optimal Procedure for Generating Routes
-------------------------------------------

To generate the best routes for a level you perform the following steps in order:
 
 a. if needed, adjust the position of some automatically generated nodes for
    platforms and teleporters

 b. while make_paths is set to 0, manually place nodes at locations that might be a 
    problem navigating 

 c. while make_paths is set to 0 add Nodes for bsp items such as func_door or
    func_train

 d. set make_paths to 1 and generate more nodes and links while walking the level 

 e  add nodes and links for secret doors and shootable buttons

 f. raise the location of each node placed above each teleporter (not the nodes 
    generated for teleporter destinations)

 g. manually 'tweak' node placement with console commands for optimal bot navigation 
    performance

There are NO path optimizations; you have complete control of the locations 
nodes are placed and the links between nodes. The bot will determine the 
shortest route to a destination from the links between nodes that you generate.


3.1 Adjust Nodes For World Items
--------------------------------
When you load an unrouted level nodes are automatically placed for "world"
objects (items in the world you can "use" but not pick up) as well as usable
items; specifically, nodes are automatically generated for teleporters, 
teleporter destinations and platforms. Follow these steps to adjust the 
positions of nodes for world objects, if needed.


1. Load the unrouted level. The default values for the cvars make_paths 
and debug_pathing are 0; leave them that way for now. Nodes for all items, 
platforms, teleporter destinations and teleporters have been created 
automatically. Set the timelimit cvar to 0. If the map is a CTF map you 
MUST have set the ctf cvar to 1 BEFORE the map is loaded or flags will NOT 
be placed on the map and item nodes will NOT be generated at the flag 
positions. Set the cvar cheats to 1 for a number of reasons (like if you're 
scoping out the nodes on a map and you're underwater you can enter the command 
'give rebreather' so you don't drown); set cheats to 1 BEFORE you load the level.

2. Run the 'noclip' command; now you can fly around the map in 'NOCLIP' 
mode (you can fly thru walls). You may have to move some of the nodes that 
are placed automatically:

a. Platform nodes may need height adjustments - this depends on the platform 
width ,the speed that platform moves and the thickness of the platform bed.
Fly up the platforms and issue the findnode command and note the node 
positions, shown with green spheres (again, it's very convenient to have the 
findnode command bound to a key). The top node should be just above the 
platform bed when the platform is at it's raised position. The bottom node 
should be well above the platform bed when the platform is at it's lowest 
position, but below the node at the top of the platform; ideally, when you 
are pathing the level you will add a move node just in front of the bottom 
of the platform and if the bot runs under the platform when it's at it's 
raised position that move node you added should be closer to the bot than 
the lower platform node. If the platform is very wide or moves upwards very 
fast you may have to adjust the node's position  upwards by increasing the 
value of it's 'z' coordinate. Use the shownode command to get the coordinates 
of the node, then use the movenode command with the node's x and y 
coordinates and the increased z coordinate value.

 Example: 
          I needed to move the bottom node of the platform upwards; I issued 
        the noclip command and I flew up above the lowered platform and used 
        the findnode command, which displayed:

           Node 16: type 2  x 300.0000  y 260.0000  z -425.0000

        To raise the node a bit issue the movenode command:

           movenode 16 300 260 -410

          Now use the shownode command to make sure it's been moved (and
        you haven't 'typo-d')
   
           shownode 16   

          displays

             Node 16: type 2  x 300.0000  y 260.0000  z -410.0000

If you fly up thru a 'platform' and find no nodes were generated, two things 
are possible; the dll placed the nodes too high or low OR what you think is a 
platform is really func_door or trigger_multiple. Either fly below and/or 
above the platform to find the nodes and move the nodes or issue the 
findstuff command to find out if the 'platform' really is a platform.

You can see on level q2dm2.bsp the lower platform nodes are moved up very high
due to the vertical speed of the platforms

b. Teleporter nodes can cause some problems when creating routes:

NOTE: After you've completed pathing the map you *MUST* raise the 
position of teleporter nodes that are above teleporters so the
bot *never* reaches the node; the teleporter_touch() function
in the dll tells the bot he has reached the teleporter node !


i. The standard Q2 teleporter is usually no problem but the 'Classic Quake' 
style types (you know, the big rectangular ones you have to step into with 
that swirly black stuff over the opening) are trouble. The problem is the node is created
inside the teleporter and cannot be "seen" (sensed, really) by the pather 
(the pathing code tries to trace a line from the pather to the teleporter 
node; that black swirly stuff prevents the trace from finding the node). So 
before the pathing code can "see" the teleporter node and add a link
from another node to it, you teleport and an erroneous link gets made from 
the node just before the teleporter to the teleporter destinantion node, 
skipping the teleporter node.Solution: you must manually move the teleporter 
node so it's position is just outside the teleporter. "Fly" into the teleporter 
and run the findnode command (bind a freakin' key already !) and find the 
node inside the teleporter of type 3. Fly straight out in front of the 
teleporter and issue a viewpos command at the point the node should be placed 
and run a movenode command with the coordinates specified by the output of 
the viewpos command.

	NOTE: I've seen a technique used by level designers quite
              often: a very wide Q1 style teleporter that you have to walk
              into may have more than 1 teleporter entity inside it (I've
              seen as many as 6 teleporter entities inside one teleporter).
              If all the teleporters entities inside the teleporter
              go to the same destination, you only need to add a link 
              between 1 teleporter node and it's destination; otherwise
              each teleporter entity connects to a unique destination
              and you must enter the teleporter multiple times at 
              varying points to make all the links.

ii. Teleporters and teleporter destinations really close to each other can 
cause problems. You know, when you step into a teleporter and you teleport to 
directly in front of another teleporter ? The problem is when the pather 
approaches the teleporter he makes a link to the teleporter destination
that's in front of the teleporter and before the pathing code senses the 
pather arrives at the teleporter the pather teleports to another destination, 
making a link between two teleporter destinations nodes, leaving out the 
link to the teleporter node itself (when this happens, the bot will look like 
he's heading into the teleporter, but just before he reaches it he'll abruptly 
turn towards the second teleporter destination node and start walking towards 
it, often walking into a wall or lava...).
 
Solution: move the teleporter destination node that is just in front of the 
teleporter SLIGHTLY away from the teleporter (about 12 units should do). 
Because it's a teleporter destination, another teleporter will have a link 
from it to the destination; the pather must make sure the closest node to 
the actual teleporter destination is for the teleporter destination; if you 
move the destination too far away you will create a link between teleporters 
when you create the path.

iii. Sometimes map designers place an item at the same position as a 
teleporter destination, ie. you step into/onto a teleporter and when you 
teleport to the destination you teleport right onto a weapon/health/armor 
etc. In this case you will fail to link the teleporter destination with the 
teleporter; instead, the link will be made between the teleporter and the 
item node directly on top of the teleporter destination (teleporter nodes, 
including the ones created at teleporter destinations, are created slightly 
higher than item nodes so an item node with the same x and y coordinates as 
a teleporter node will be slightly closer to the player's origin than the 
teleporter node). You should manually remove the link from teleporter to item, 
manually link the teleporter node at the teleporter to the teleporter node 
at the teleporter destination, then manually link the item node on top of 
the teleporter destination with the teleporter node at the teleporter 
destination; you should try to avoid going thru that teleporter while pathing 
again so you don't have to manually fix those links again, set make_paths
to 0, navigate thru the teleporter and set make_paths back to 1.


3.2 Manual Placement of Strategic Nodes                
---------------------------------------
If you're in NOCLIP mode, issue the 'noclip' command to return to normal
movement and leave the cvar make_paths set to 0; set the cvar debug_pathing to 1
or 2. Now you should manually drop nodes in strategic places on the map as you
walk around WITHOUT MAKING ANY PATHS yet. 

	*** Bind some keys to the commands "addnode 0", "addnode 5" and 
	    "findnode" so it's easy to walk around the map and "paint"
	    nodes or find existing nodes quickly.

      a. Manually drop nodes at the intersections of corridors, on each
         side of doors, on stairs/ramps which have turns, etc., wherever
         the bot will have to make a sharp turn. While you could skip this
         step, if you want to make a really good route where the bot doesn't
         run into walls and stuff, do this stuff. The bot does have some
         code that will detour around obstructions (like when he can't see
         his next node from his current position) but manually placing nodes
         where the bot might have some trouble will result in smooth
         navigation (after you've routed the map you can edit the node
         positions and links manually, but it's easier to do it before you
         add your links). 

         The following high intensity graphics illustrate the correct 
         placement of nodes for optimum navigation performance.

      Legend:

         ... - a route or potential route

         N - where you should put a node; the node should be of type 'move' 
            (type 0) unless otherwise indicated.

         B - a bot

         G - a grapple node (type 6)

         J - a jump node (type 7)

         I - an item where a node has automatically been placed (type 4)

         T - a teleporter where a node has automatically been placed
             (type 3)

         TD - teleporter destination where a node has automatically been
              placed
              (also type 3)

         PB - platform bottom where a node has automatically been placed
              (type 2)

         PT - platform top where a node has automatically been placed
              (also type 2)

         W - a water node (type 5)

         JP - a jump pad 
 
         DB - a manually placed doorbottom node	

         DT - a manually placed doortop node	

         S - a manually placed shoot node		

         DO - a manually placed dooropen node		

         TR - a manually placed train node

         V - a manually placed visible node		

         NV - a manually placed notvisible node		






         Intersection of corridors viewed from above -

         Narrow corridors .... manually place a move node at 'N'

                       |  .  |
                       |     |
                       |  .  |
                       |     |
             ----------   .   -----------
             . . . . . .  N  . . . . . . .
             ----------      ------------
                       |  .  |
                       |     |
                       |  .  |
                       |     |


          Wider corridors .... manually place a move node at all 'N's
        
                   |     .     |
                   |     .     |
                   |     .     |
                   |     .     |
         ----------     .N.     -----------
                      .  .  .          
          . . . . . N  . N .  N . . . . . .
                      .  .  .
                        .  .
         ----------      N      ------------
                   |     .     |
                   |     .     |
                   |     .     |
                   |     .     | 


          Even wider corridors .... manually place a move node at all 'N's
        
                   |  .           . |
                   |  .           . |
                   |  .           . |
                   |  .           . |
         ----------   .           .  -----------
            . . . . . N . . . . . N . . . . . .
                      . .     .   .
                      .   . .     .
                      .   .N.     .
                      . .     .    .
            . . . . . N . . . . . N . . . . . .
         ----------   .             -----------
                   |  .           . |
                   |  .           . |
                   |  .           . |
                   |  .           . |


       Especially if item nodes already exist near the intersection; you
       want the move node to be the first node the bot 'sees' when
       entering the intersection. This avoids links around corners.

                   | I        I|  manually place a move node at all 'N's;
                   |           |  
                   | I        I|  I = item nodes that have been automatically generated
                   | . .     ..|  for all items by the dll when the map is loaded
         ----------  .  .   . . -----------
             . .I .  .  .N .  .  .I . .
                    .N .     .N .
                   . .        .   .
             . .I .  .   N    .   I . .
         ----------  . .   .  . ------------
                   |         . |
                   | I        I|
                   | .        .|
                   | I        I|



         A turn in a corridor or room where items are placed near walls
         and the items are not visible to each other. The bot won't
         get hung up by the corner if you place the node where the N is.


 	                   | I        |
                           | .        | manually place a move node at 'N'
                           | I        |
                  	   |  .       |
	         ----------    .      |
                        I .... N      |
            	                      |
	        -----------------------

          or
            
                   | I            I|
                   | .            .|  manually place a move node at all 'N's
                   | I            I|
                   |  .         .  |
         ----------   .         .  -----------
            . . I . . N  . . . .N . .I . . . .

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





         Corridor leaving a room or open area -


                   |     .     |  manually place a move node at all 'N's
                   |     .     |
                   |     .     |
                   |     .     |
         ----------             ------------
         |      . . . .  N . . . . . .     |
         | N  .                        . N |
         |                                 |


         
         Items placed in a small "alcove" off a room, corridor, etc; make
         sure the bot sees the move node you place as a route to the item
         nodes...

                   -------------
                   |           |	manually place a move node at 'N'
                   |  I . . I  |
                   |  .     .  |
                   |  .     .  |
         ----------     .  .    ------------
         |      I . . .  N  . . . . I      |
         |               .                 |
         |               .                 |
                         .

          If the "alcove" is wide, try this:

                   -----------------
                   |               |
                   |  I .I .I .I.I |	manually place a move node at all 'N's
                   |  .          . |
                   |  .          . |
         ----------   .          .  ------------
         |     I . . N  . . .  . N . . . I     |
         |           .           .             |
         |           .           .             |





       These are stairways (really, they are!); do the same for ramps
        (this view looking down)

				manually place a move node at all 'N's
       ----------------------------------------------------
       |           |           | | | | | | |
       |           |           | | | | | | |
       |           |         .N|.| | | | | |
       |           |        .  | |.|.|N|.|.|.N........  
       |           |       .   | | | | | | |
       |           |      .    | | | | | | |
       |           |     N     | | | | | | |           
       |           |_____._____|----------------------------
       |           |_____._____|
       |           |_____._____|
       |        I  |_____N_____|  I(0) <---------------------------------
       |        .  |_____._____|  .                                     |
       |        .  |_____._____|   .                                    |
       |        .  |_____._____|   .                                    |
       |        .        .         .                                    |
       |       N . . . . N(2). .  N(1) <- dropping this node N(1) prevents
                                        node I(0) from being linked to the
                                        node N(2) placed at the foot of the
                                        stairs; you force the bot around the
                                        stairs and he will not run into the
                                        side wall of the stairs.



       Wide stairs; do the same for wide ramps 

       -----------------------------------------------------------
       |           |                    | | | | | | |
       |           |                    | | | | | | |
       |           |         N . . . . N|.|.| | | | |
       |           |        .        .  | | |.|N|.|.|.N . . . .  
       |           |       .        .   | | | | | | |
       |           |      .        .    | | | | | | |
       |           |     N         N    | | | | | | |           
       |           |_____._________.____|----------------------------
                   |_____._________.____|  manually place a move node at all 'N's
                   |_____._________.____|  
                I  |_____N_________N____|  I            
                .  |_____._________.____|  .            
                .  |_____._________.____|   .           
                .  |____.___________.___|   .           
                .      .             .      .           
               N . . .N  . . . . . . N . . .N




    b. Open space should be populated with move nodes, place the nodes around
       128 units apart covering the entire area. Ideally each node should have
       nodes it can reach in all directions. If you put move nodes at each of the 
       numbers, you can see that nodes 8 thru 11 and 14 thru 17 have six potential 
       adjacent nodes that can be linked to it. You would later create links
       between the nodes in each column, row and diagonal.

           1       2       3        4        5        6

 

           7       8       9        10       11       12




           13      14      15       16       17       18




           19      20      21       22       23       24

     

    c. A typical room; always put nodes at exit points.

                       ~128 units
                Scale |_________|
       ------------------------------------------------|    N    |---
       |                                                            |
       |                                                            |
       |    N         N         N         N         N       N       |
       |                                                            |       
       |                                                            |
       |                                                            |  Put move nodes
       |                                                            |  at all Ns
       |    N         N         N         N         N       N       |
       |                                                            |  
       |                                                            |
       |                                                            |
      ---                                                           |
                                                                    |
       N    N         N         N         N         N       N       |
                                                                    |
      ---                                                           |
       |                                                            |
       -------------------------------------------------------------


    d. Manually drop move nodes in front of platform bottoms and tops,
       in front of teleporters (if a teleporter destination node is
       not in front of the teleporter) and directly in front of any
       opening in a wall the bot will have to crouch to get through.
       Also manually drop nodes near both sides of doorways.


    e. Ladders - drop a move node (type 0) at the bottom a ladder; go to 
       the top of the ladder and when you are standing on the top move forward
       a little from the ladder and issue the 'laddertop' command. This will 
       create a jump node (type 7) at the ladder top. The jump node is placed 
       high enough so the bot will clear the top of the ladder and should be 
       over solid ground. Then place a move node close to the jump node to
       leave the ladder.

           Ladder, viewed from the side - the 'J' is a jump node; the laddertop
           command places it high enough so that when the bot's waist is the
           same height as jump node 'J' his feet will clear the ladder.
           Be sure to place a move node close to the ladder top.'J' should be 
           placed so that falling straight down from 'J' will reach the 
           surface the ladder leads to.

             (Side View)      
                                      J . .
                                     .     .
                                   .       . N . . . . . 
                                  .  _ -------------------------
                                  . | |
                                  . |L| manually place a move node at all 'N's
                                  . |A|
                                  . |D| the 'laddertop' command places  the
                                  . |D| jump node 'J' at the top of the ladder
                                  . |E|
                                  . |R|
                                  . | |
                                  . | |
                  N . . . . . . .N  | |
              _______________________


     f. If your route will jump or walk off a ledge, make sure there is
        a visible node to jump to; you might link to a node the bot can't
        see and he'll spin in circles trying to get to it;


        BAD ! (side view); the '=' stuff is the pather's route.

         |                                                     |
         |        N(0) B(ot) =                                 |
         __________.________   =           ____________________|
                    .       |   =         |
         ____________.______     =         ____________________
         |            .           =                            |
         |             .          =                            |
         |             .          =                            |
         |             .          =                            |
         |             .          =                            |
         |             .          =                            |
         |             .          =                            |
         |             .          =                            |
         |             .          =                            |
         |             .          =                            |
         |            I(1)        X                   I        |
         _______________________________________________________

         Here the pather walked off a ledge to point X, but node I(1) was
         found within 128 units of his landing point, linking node
	 N(0) with node I(1); when the bot reaches node N(0) he will try to 
         orient himself towards I(1) and he will spin around, never reaching 
	 I(1).


        Good ! (side view)

         |                                                     |
         |        N(0) B(ot)  .                                |
         ___________________    .          ____________________|
                            |     .       |
         ___________________       .       ____________________
         |                                                     |
         |                          .                          |
         |                                                     |
         |                          .                          |
         |                                                     |
         |                          .                          |
         |                                                     |
         |                          .                          |
         |                                                     |
         |                                                     |
         |            I(1) . . . .N(3) . . . . . . . . I       |
         _______________________________________________________

          Here the pather manually dropped move node N(3) directly below
          the gap in the floor BEFORE he created any paths; then
          when he created routes he linked N(0) with N(3) when he
          walked off the ledge. If the gap is very narrow you may want to
          change N(3) to a JUMP node (type 7) or add a crouch flag to N(3).
           
    g. Water nodes should be dropped close to the surface of the water
       when a path will be leaving water for solid ground; drop a
       water node ('addnode 5' creates a water node at your origin)
       close to the shoreline and manually move it near the surface of
       the water using the movenode command. You'll also want to drop
       a node on land very close to the shoreline near the water node
       you dropped; you can make this node type 'move' (0) or 'jump' (7)
       (jump nodes here offer slightly smoother navigation and if
       it is actually necessary to jump to get out of the water then use
       a jump node).
         
         NOTE: you should create more than one route out of a large body
         of water; makes it harder to predict where the bot leaves water
         and gives the bot more path choices.
         


         Side View ...

             Place water node W(0) close to the surface and move N(1) near 
             the water's edge; you want nodes W(0) and N(1) to be the route
             to get out of water. If you don't place those nodes there, you 
             may end up with with W(2) and I(3) as the route out of water; 
             the bot probably will get stuck at the point marked by ** .
          
      ____
          \___  I(3)    N(1)
              \_____________
                            \~~~~ W(0) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       (solid ground)        |
                             |                           
                            **                  W
                             | 
                             |                (this is water ... really!)
                             | 
                             | 
                             | 
                             |    W(2)
                             | 




   h. Drop jump nodes (type 7) manually to assure accurate node placement.
      Use jump nodes to navigate up a stack of crates, to traverse a gap, 
      etc. Remember, when you're 'auto' pathing, anytime you press the jump 
      key you'll generate a jump node where you land if a visible jump node 
      does not already exist nearby. 

        * WARNING * - jump nodes let the bot "cheat"; the bot can jump ANY
                      distance upwards/sideways if the jump node is a great
                      distance from another node with a link to it. Try to
                      keep the bot from making super-human jumps by keeping 
                      jump nodes close to nodes linked to them.

       Here the path will go up some crates to get an item. You should put
       N(1) (type move) close to the bottom crate for realism; the bot can
       jump from N(0) to J(2) if the path takes him that way but a human 
       could not. Note that if you were 'auto' pathing and had not dropped
       jump node J(4) and 'auto' dropped a node at J(3), even if you jumped 
       towards node I(5) a direct link between J(3) and I(5) would likely 
       be made because J(3) would still be visible to I(5); manually placing
       J(4) at the specified location assures the bot makes the last jump
       up the smaller crate on his way to I(5).

             (side view ...)

                                                     J(4)I(5)
                                                      _____
                                                 J(3)|     |
                                                _____|___ _|
                                               |         |
                                               |         |               
                                           J(2)|         |
                                           ____|___ _____|
                                          |        |
                                          |        |
                     N(0)           N(1)  |        |
                    ______________________|        |

           
3.3 Add Nodes For World Items
-------------------------------

3.3.1 Door Bottom and Door Top Nodes
------------------------------------
Manually add doorbottom and/or doortop nodes as needed for all doors that function 
like platforms. You should also manually add links between the nodes used to get on, 
ride and get off the door. 

Doorbottom and doortop nodes don't have to be placed in the center of the door; 
they merely tell the bot to make sure the door is in the proper position 
before getting on the door. Doors in Quake2 can work in reverse, ie. the 'top'
position can be lower than the 'bottom', use the finddoor command to determine
the state of the door. You should manually link the nodes and not rely on the
pathing code to make links.


   a. place a move node near the door at the point you get on the door

   b. You usually only need to place one doorbottom or doortop node on the door, 
      generally at it's unextended position (usually a doorbottom node at the lowest 
      position of door). Then ride the door to it's other position and place
      a move node near the center of the door; usually a crouch flag is appropriate
      at this move node to stabilize the bot as it rides the door.

   c. then place a move node off the door at it's extended position.

   d. manually link all the nodes in the proper sequence so the bot can navigate
      the door:
        1. use the addlink command to add a link from the move node in step a
           and the doorbootom or doortop node in step b.
        2. use the addlink command to add a link from the doorbottom or doortop
           node in step b and the move node on the door at it's extended position
           and the door node in step b. 
        3. use the addlink command to add a link from the move node in step b
           and the move node in step c.

      Side view: door starts at it's lowered position

       Move node N(1) is linked to doorbottom node DB(2)
       doorbottom node DB(2) is linked to move node N(3)
       move node N(3) is linked to move node N(4)
       move node N(3) should have a crouch flag unless the door moves very fast

                                       N(3)          N(4)
                                                   --------------------------
                                                   |    
                                                   |
                                                   | 
                                                   |
                                                   | Path: N(1)->DB(2)->N(3)->N(4)
                                                   |    
                                                   |
                                      DB(2)        |
                                  =================|
                             N(1) |  D O O R      ||
           ----------------------------------------- 


    e.In the rare instances that a door can the door ridden both ways, boarded
      from the bottom and navigated up and boarded the from the top and navigated
      down, put a doorbottom at the door's bottom position as well as a move
      node close to the center of the door; then put a doortop node at the 
      door's top position along with a move node at the center of the door.
      Don't link the doorbottom node to the doortop node; link the doorbottom
      node to the move node placed at the top position and the doortop node
      to the movenode placed at the bottom position.

3.3.2 Shoot Nodes
-----------------
Shoot nodes tell the bot it must stand at it's previous node and shoot at the 
shoot node until it is "visible" to the bot ( a line can be drawn from the bot 
to the shoot node that is unobstructed by any bsp objects), then proceed to the
next node on it's route; the bot does not navigate to the shoot node. See
3.6 Adding Shoot Nodes for Secret Doors for an "illustration" of a route thru
a secret door.

It's best to place shoot nodes for secret doors after the level has been completely 
pathed, but you should manually place nodes (usually type move) on either side of 
the secret door before you turn make_paths on, just like any other door. 
Note that shooting a secret door while pathing the level does not create a 
shoot node, they can only be placed manually; likewise, shoot nodes are
never linked to/from by the pathing code, links to/from shoot nodes must
be generated by the 'addlink' or '2way' commands.

You can also use a shoot node to have the bot shoot a button that operates a door.
Precise node placement is required; the shoot node must be placed so that when the
button is at it's extended position the shoot node is obscured and when the button 
is shot and the button is in it's contracted state the shoot node is visible to the bot.


   Side view: a shootable button controls an opening door. Move node N(1) is placed
   at the position where the bot will stand and shoot at the shoot node; shoot
   node S(1) is placed *inside* the button (in NO_CLIP node or as a spectator),
   move node N(2) is placed on the other side of the opening door. Then use the
   addlink command to link N(1) to S(1), then S(1) to N(2), so that the path that 
   opens the door and navigates thru it is N(1)->S(1)->N(2). When the bot gets to 
   move node N(1) it stops and shoots at shoot node S(1) until the button "dies" 
   (it's "health" is 0), the button contracts and the shoot node is visible to the 
   bot; then he walks or runs from move node N(1) to move node N(2) on the other side 
   of the door.


       Side view...                                         |                                                            
                                                       |====|
                                                       |    |
      shoot node placed inside a button -------------> |S(1)| <-- shootable button
                                                       |====|
                                                            |_______________________
                                                          =====
                                                          |   |
                                                          | D |
                                                          |   |
                                                          | O |
                                                          |   | link N(1) to S(1)
                                                          | O | link S(1) to N(2)
                                                          |   | 
                                                          | R | Path: N(1)->S(1)->N(2)
                                                          |   |
                                                          |   |
                                                          |   |
                                                          |   |
                                                          |   |
                                                          |   |
                                                          |   |
                       N(1)                               |   |  N(2)
        -----------------------------------------------------------------------                                                            

If needed, use the pvis command to determine correct shoot node position. 
In the example above:

  a. exit NO_CLIP or spectator node and navigate, make_paths set to 0, navigate to 
     move node N1

  b. use the 'viewpos' command to determine the position of your "eyes" in the world;
     the 3d coordinates you are viewing the world from are displayed between the
     brackets.

  c. use the shownode command with the node number of the shoot node to show the 3d
     coordinates the shoot node is placed at.

  d. with the button left "un-shot" in it's extended position issue the pvis command
     using the 3d coordinates from the viewpos command and the 3d coordiates from the
     shownode command as the 6 arguments to the pvis command (round off the node 
     coordinates to whole numbers). The pvis command will tell you if the coordinate
     sets of your viewpos and the shoot node are visible, they should *not* be,
     move the shoot node, use the pvis command using the new shoot node coordinates
     until the coordinate sets are *not* visible to each other.

  e. now shoot the button until it "dies" and contracts to it's unextended position
     and run the pvis command with same coordinates as in step d; if the shoot node
     is in the proper position the pvis command will tell you thats the coordinate
     sets are "visible" to each other.

Once you finish making routes for the bot you can have a bot test that the the shoot
node is in the proper location. See the loko manual document for more info.

  a. use the server command 'sv rebuildgraph' to rebuild the link graph in memory so
     the bot knows how to navigate the level.

  b. set ctf to 1, the HUD will get a little wacky, deal with it ...

  c. join the blue team with the 'team blue' command

  d. set the server cvar verbose_ctf_bots to 2, which tells the bots to report lots of
     info to the human players on it's team about it's navigation movement when the
     game is CTF

  e. navigate to a location where you can view the shootable button

  f. add a ctf bot to the blue team; the default team a bot joins when no team is
     specified is the blue team and bot skill does not matter here, so enter the
     command 'sv addbot' will add a random skilled bot to the blue team. The bot
     will default to having the name "b1"

  g. use the 'role' command to tell the bot to patrol the node *just after* the shoot 
     node; in the above example if the node at N1 is node number 125, the command is
     'role b1 patrol 125' or  'role b1 p 125'. The bot will immediately head for
     node 125, causing it to use the shoot node as a node in it's route. When it
     gets to the node just prior to the shoot node it will stop and shoot at the
     shoot node. If it shoots and misses the shootable button the node is not placed
     properly, use the movenode command to move the shoot node to a position where
     the bot shoots and hits the shootable button. If the bot shoots and hits the 
     button and the button contracts but the bot continues shooting the button then
     use the movenode command to move the shoot node further away from the wall. If
     all is well the bot will shoot the shoot node, the button will contract and
     the bot will "see" the shoot node and proceed thru the open door.


3.3.3 Door Open Nodes
---------------------
On Action Quake2 maps you should place one dooropen node near each door that 
opens and closes. You should have the server cvar aq2_doors set to 1 to test 
if the door needs to be commanded to open with the opendoor command (some doors 
on Action Quake2 maps open automatically). For rotating doors place a dooropen 
node on the side of the door the door rotates to when opening, then place a 
move node on the same side of the door outside the "arc" of the rotating door 
near enough to the door so issuing the opendoor command opens the door. For 
sliding doors place a dooropen node on any side of the door and a move node 
on the same side near enough to the door so issuing the opendoor command 
opens the door.

       Top view: 2 way links between dooropen node DO(3) and 3 move nodes
          N(1), N(2) and N(4). Move nodes N(1) and N(2) are placed just 
          outside the arc of door travel so the opening the door won't hit
          a bot waiting at the node for the door to open; the dooropen node 
          DO(3) is placed inside the arc of door travel.


                                      N(1)                2way link DO(3)<->N(1)
                            \\                            2way link DO(3)<->N(2)
                             \\                N(2)       2way link DO(3)<->N(4)
     func_door_rotating ----> \\                  
                               \\     DO(3)                Paths thru the door: 
                                \\                            N(1)->DO(3)->N(4)
     ============================             ========        N(2)->DO(3)->N(4)
                                                              N(4)->DO(3)->N(1)
                                       N(4)                   N(4)->DO(3)->N(2)




3.3.4 Visible Nodes
-------------------
Use a visible node to tell a bot when the path is unobstructed. You must manually
use the addlink command to link the nodes in the proper sequence, visible nodes
are ignored when make_paths is set to 1 are never linked to or from by the  

   Side view: the bot wants to navigate from move node N(3) to move node N(4); the 
     door is only navigable from bottom to top and may or may not be at it's 
     lowered position. Visible node V(1) can be placed anywhere where the bot can "see" 
     the visible node when the door is at it's lowered position and can't "see" the 
     visible node when the door is at it's raised position. Use addlink to link N(3) 
     to V(1) and V(1) to N(4) so the route is N(3)->V(1)->N(4). The bot does not try 
     to navigate to visible node V(1); when the bot reachs node N(3) it checks if node 
     V(1) is visible; if V(1) isn't visible it stands at N(3) until V(1) is visible, 
     then proceeds to N(4). The bot ignores doorbottom node DB(1) as it's not in the
     path from N(3) to N(4).


                                 |
                                 |
                                 |        N(2)         N(3)
                                 |                  --------------------------
           -----------------------                 |    
                                                   |  addlink: N(3) to V(1)
                                    V(1)           |  addlink: V(1) to N(4)
                                                   |
                                                   |  Path: N(3)->V(1)->N(4)
                                                   |    
                                                   |
                                      DB(1)        |
                                  =================|  the door acts like a platform,
                       N(4)  N(1) |  D O O R      ||  raise and lowers; this works
           -----------------------------------------  for func_plat too.



3.3.5 Notvisible Nodes
----------------------
Use a notvisible node to tell a bot when the a bsp object is in place. The bot waits
until it's view of the notvisible node is obstructed by a bsp object before proceeding
on it's route; the bot does not navigate to the notvisble node but instead to the node 
after the notvisible node in the sequence of nodes in it's route. You must manually
use the addlink command to link the nodes in the proper sequence. See 3.3.6.1b for 
an "illustration" using a notvisible node.


3.3.6 Train Nodes
-----------------
When bots ride a func_train they try to always stay at the very center of the
func_train so place all train nodes so the path stays on the center of the train
bed. Train nodes can be placed much less densely than other nodes because the bot
assumes the train ride will take a long time, you should place a train node
on a long train ride about every 10 seconds of travel time, but don't let the 
travel time between train nodes get above 20 seconds. Bots are unaware of
path_corners and they don't need to sense them.

If you create a route to a destination that uses a train and another route is
available that uses grapple nodes the bot will always choose the route with grapple
nodes so if you don't ban the off-hand hook the bot will never ride the train; for
example, the bot will only ride the train on q2dm2.bsp if the hook is banned.


3.3.6.1 Getting on the Train
----------------------------
a. If the func_train can be boarded easily without having to jump on the train bed
   you can use a train node to help bots board the train; the bot waits until any 
   portion of the train is directly under the train node before he boards the train 
   so the boarding train node must be placed when the train is close to the ledge
   it is boarded from.

    
    Side view: a horizontal train that stops at or slowly approaches and departs
      from the ledge; the train travels all the way to the ledge surface and can
      be walked onto. Move node N(1) should be placed near the edge of the ledge, 
      train node T(1) should be placed as indicated, train node T(2) can be placed 
      about 10 seconds travel time away from train node T(1).


        N              N(1)   T(1)                              T(2)
      ---------------------- =============
                            || T R A I N |  <--- train travels in both directions --->
                            |=============
                            |  ^
                            |  |
                            |  |
                            |  ------- The bot waits at N(1) until any portion
                            |          of the train is under T(1) before boarding
                            |          then boards the train maintaining position
                            |          at the center of the train bed while riding
                            |          the train to T(2)


b. If the train must be jumped on use a combination of node types to create
   a route that boards the train; a notvisible node tells the bot the train is in
   place and it is safe to jump to a jump node to board the train. You must manually
   create links with the addlink command for this route.

    Side view: a horizontal train that does not travel all the way to the ledge or
      approaches and departs the ledge very quickly. Move node N(1) should be placed 
      near the edge of the ledge, notvisible node NV(2) is placed so that when then train
      is in place to be jumped on the notvisible node is obstructed from view from
      move node N(1) (use noclip), jump node J(3) should be placed when riding the
      train over notvisible node NV(2), train node T(4) should be placed a short
      distance from jump node J(3), train node T(5) can be placed 10 seconds travel 
      time away from T(4)

      link move node N(1) to notvisible node NV(2)
      link notvisible node NV(2) to jump node J(3)
      link jump node J(3) to train node T(4)
      link train node T(4) to train node T(5)
      Path is N(1)->NV(2)->J(3)->T(4)->T(5)     
 
                                ------------------ end of train travel                      
                                |
                                |
                                V      
     N                N(1)        J(3)  T(4)                              T(5)
    ----------------------      =============
                          |     | T R A I N |  <--- train travels in both directions --->
                          |     =============
                          |      NV(2)
                          |       ^
                          |       |
                          |       |
                          |       -- The bot waits at N(1) until the traveling train
                          |          obscures it's view of notvisible node NV(2),
                          |          then jumps to jump node J(3); once on the train
                          |          it maintains position at the center of the train
                          |          bed while riding the train to train nodes T(4) 
                                     and T(5)
                               

                                
3.3.6.2 Getting off the Train
-----------------------------
The bot will always ride the train at the very center of the train bed when it's next
node is a train node; when it is riding a train and it's next node is not a train node 
it will abandon the center position of the train and navigate off the train. You must 
assure the bot will be close enough to the last train node to consider it visited before 
the bot gets off the train; specifically, the distance the last train node is placed 
from the leading edge of the train bed must be more than half the width of the train 
bed in the direction the train is travelling.
   
       Side view: the bot rides the train from train node T(1) to train node T(2),
           maintaining a position at the center of the train bed. When it reaches
           train node T(2), it's next node is not a train node but move node N(2)
           so it stops maintaining center position on the train bed and walks to
           N(2). If T(2) had been placed where the 'X' is, the center of the
           train doesn't reach that point and a bot riding a train at the center
           of the train won't either. If the train moves very fast make N(3) a
           jump node so the bot jumps off the train.


                                 Center of train
                                        |              
                                        |
        T(1)                       T(2) V        X         N(3)
                       ================================= --------------------------
                       |            T R A I N          | | 
                       ================================= |
                                                         |
          <--- train travels in both directions --->     | Path: T(1)->T(2)->N(3)
                                                         |
                                                         |


       Side view: same as above except the train does not travel all the way to the
            ledge; train node T(2) is placed so it is reached by the bot before the
            train changes direction as the bot travels in the center of the train bed; 
            when it reaches T(2) it jumps to jump node J(3).



                                 Center of train
                                        |                                           
                                        |
        T(1)                       T(2) V                          J(3)
                       =================================          -----------
                       |            T R A I N          |         | 
                       =================================         |
                                                       ^         | Path: T(1)->T(2)->J(3)
  <--- train travels in both directions --->           |         |
                                                       |         |
                                 end of train travel---|               



3.4 Walking The Map To Generate Nodes/Links
----------------------------------------------
   After you've fiddled with any problem nodes (teleporters and platforms) 
and have manually dropped your strategic nodes, set debug_pathing 1 or 2
and make_paths are both set to 1. When make_paths is set greater than 0 if 
there are no visible nodes within 128 units a new node will be created at 
your position, slightly below your waist. As you walk around the map 
generating new nodes and visit existing nodes, links between the nodes 
will be created.

       NOTES:
       ------
        a. It's best to walk, not run, when 'auto' pathing; the pathing
           code checks every 1.5 seconds to see if you've reached another 
           node from the node you last visited. Also, if you're walking you'll 
           be less likely to fall accidentally .If you must make a long 
           horizontal jump, use the 'run' key when you need to. Always walk
           when decending stairs or ramps, stopping periodically.
           
        b. Don't jump if you don't have to; when you press the jump key, 
           when you land a 'jump' node will be generated at your landing 
           point if no other close jump nodes exist nearby, even if nodes
           of other types are nearby. Also, try not to accidently fall any 
           distance that could cause health damage while you're pathing because 
           you'll make a link from a high node to a low node; the bots assume     
           an existing path is fairly safe and don't check if moving along 
           the path can be dangerous,and if they choose this route when their 
           health is low the damage from falling may kill them. If you do 
           fall any great distance and want to get rid of the erroneous link
           you create, immediatly set make_paths to 0 and remove the 
           erroneous link manually using the removelink command, navigate to 
           where you fell from then set make_paths back to 1 and continue
           pathing. If you want to create a link from one node to a much
           lower node and the lower node is not in water, read the section 
           later about grapple nodes.
       
        c. You should never place any nodes in lava or slime; again, if
           the node has links to and/or from it a bot will eventually 
           try to navigate to it with little checking for safety. If
           the pathing code senses the pather is in lava or slime it
           won't drop a node there (EXCEPTIONS: the code does not check
           for grapple or jump nodes in lava or slime, so try not to
           do any swan dives into toxic substances (a good rule for
           real life too)).

        d. You might be tempted to keep your nodes well away from lava or
           slime, reasoning that if the bot doesn't get close to it it won't
           fall into it. The opposite is true. Most of the bot's attacks 
           ignore the path and he may move into an area where there are no
           nodes. Then when his attack ends he will try to re-orient himself
           to his destination path by finding the closest node to himself; if
           no close nodes exist he will wander around looking for a node. It 
           is when the bot is wandering that he's most likely to fall into 
           lava or slime. So you don't have to place nodes right up to the 
           edge of lava or slime (you can if you want to) but nodes SHOULD 
           be placed closer than 128 units to lava or slime.    

        e. Nodes are never placed automatically if you are off the 
           ground and not underwater. 
          
           NOTE: Be aware of the following quirk in the Q2 physics:

              If you jump down or fall onto a slope and you start to slide
           (from gravity or momentum) the Q2 physics does not recognize
           you as being a 'groundentity' (technically, you are airborn)
           even though your feet are touching the ground; you become
           a 'groundentity' again when your velocity is 0 (you stop
           sliding). While you can exploit this bug/feature to avoid
           falling damage, the downside is that if you're pathing the
           level with make_paths set to 1 and you jump or fall down onto a
           slope (expecting to automatically drop a node where you landed)
           the node won't be dropped until you stop sliding. For example,
           on the iD level strike.bsp (Outlands) I was pathing the level 
           with make_paths set to 1, automatically dropping nodes when 
           there were no other nodes close to me, and was near the room at 
           one end of the map, above where the BFG sits on a small island 
           in the water. After I crossed the bridge and was about to go thru 
           the valley/tunnel I slipped and slid down a slope towards 
           the water. As I was falling the slope curved, causing me to 
           change directions as I slid towards the water. I had just 
           'auto' dropped a node before I fell so while I was sliding 
           down the slope no other 'auto' nodes were dropped because
           the Q2 engine considered me airborn; when I hit the water I had
           slid to a point underneath the bridge I had just crossed and a
           water node was dropped. This created a link between the node
           'auto' dropped at the top of the slope and the 'auto' water
           node created when I entered the water. If I would have left
           the link in place, if a bot chose to use this link as a path
           he would reach the node at the end of the bridge and then 
           start to move in the direction of the water node dropped after
           I slid down the slope; however the water node was directly under
           the bridge so what the bot would do is walk back across the bridge
           and when his xy coordinates (2D, excluding height) matched those
           of his next node (that water node I dropped after sliding) he 
           would stop his forward motion and try to menuveur downward THRU 
           the bridge ! Of course, I immediately set make_paths to 0
           and removed the link; I had debug_pathing set to 1 so I was aware 
           that no nodes were dropped as I was sliding down the slope. Just be 
           aware of this quirk when you fall or jump down a slope, steep 
           ramp or even steep stairs and have make_paths set to 1.
           When creating a path down a steep ramp or steep stairs, try
           to stand still at regular intervals so the Q2 engine recognizes
           that your not 'airborn' and you drop a node or link to a node
           on the ramp/stairs.
  

        f. Bots understand platforms, doors, func_train and teleporters but 
           don't know squat about push buttons and 'trigger_multiple';
           However, the bot can deal with most of these entity types with a 
           little ingenuity while pathing; be sure to read the section below 
           titled 'Workarounds'.
         
        g. No 'auto' links are made and no 'auto' nodes are created if you 
           are in spectator or noclip mode, even if make_paths is set to 1.

        h. What type of node that is placed when you're pathing depends on
           how you move and what your moving through. Normally, if you're
           walking over solid ground you'll drop a move node, if you're 
           standing in or are immersed in water you'll drop a water node,
           if you're jumping you'll drop a jump node and if your using the 
           CTF grapple you'll drop a grapple node (ladder nodes are no longer
           supported).

        i. CTF maps are usually symetric in nature; often the red base and the
           blue base are more or less mirrors of each other. If you create
           better paths to the blue base than to the red base, the blue team 
           bots will have an advantage when they are returning the enemy's flag 
           to their base. If the bases are mirrors of each other you should try 
           to create the same basic paths to the flags at each base so bots on
           one team don't have an advantage over bots on the other team.

        j. Remember, all links you create (manually using the addlink command
           or when 'auto' pathing) are one-way links; make sure you create 
           paths in EVERY navigable direction possible. If the pather walks
           down a corridor in one direction and never doubles back in the 
           opposite direction then the bot will only follow the corridor in
           the direction that has a path. If you fail to path a portion of the 
           map the bot will never go there; if a deathmatch spawn point exists
           in an unpathed portion of the map and a bot spawns there he will not
           know how to navigate the area and will wander around. The bot uses
           the path for more than just item acquisition; he'll chase enemies
           or follow sounds using the path, use the path to find air when 
           drowning, follow the path as an escape route, etc.

	k. You must add shoot nodes manually when make_paths is turned off
           but you should still walk the path thru the secret door and create
           erroneous links between the nodes on either side of the door; after 
           you finish making paths by walking you will add the needed shoot 
           nodes and correct the links. You should have placed move nodes on 
           either side of the door that can "see" each other thru the open 
           door before you turned make_paths on. With make_paths on, 
           walk towards the door until you make a link to the move node in 
           front of the closed door, shoot the door open and walk thru the 
           open door to make a link to the move node on the other side of the 
           door. 

         l. Grapple nodes can be placed manually (addnode 6 creates a
            grapple node just below your origin) or placed when
            the cvar make_paths is set to 1 and you use the CTF
            GRAPPLE ONLY ! (NOT the off-hand hook !). Sorry, but the code
            for the CTF grapple is more explicit (the code can detect the
            state of the grapple ie. flying thru the air, hooked, etc so
            the pathing code knows when to drop a grapple node), even 
            though the bot uses the off-hand hook for normal naviagation
            (the bot only uses the CTF grapple as a weapon or when he
            attempts to 'tarzan' out of lava or slime). You should place
            grapple nodes intelligently ie. when you absolutely need to
            grapple somewhere; avoid using grapple nodes 'coz I thought
            it would look cool ...' or when an existing nearby map entity 
            (platform, ladder, etc.) will allow you to navigate to your 
            destination. Some convenient macros for using the grapple are
            aliased automatically by the dll:

                  +ctfhook is an alias for "use grapple;+attack"
                  -ctfhook is an alias for "-attack;weaplast"

             Bind a key to "+ctfhook"; when pressed it switches weapons
             to the grapple and fires it. When you release the bound key 
             you unhook the grapple and switch to the last weapon you were
             using.
    
              NOTE: the physics of the off-hand hook and the CTF grapple
              are slightly different; you'll notice that if you fire the
              CTF grapple at a wall the grapple will hit where your
              crosshairs are (is ?); the off-hand hook will land slightly
              to the left of the crosshairs. Also, the off-hand hook 
              is faster than the CTF grapple. Take this into account
              when using the grapple when pathing.

             1. Create grapple nodes to navigate to the upper levels
                of an 'atrium-style' level ONLY if there is no close
                platform, ladder or teleporter node or jump pad that can 
		get you to the same place.

             2. Create grapple nodes to reach otherwise unreachable
                 locations (where you might have to rocket-jump) ie.
                 to get the MegaHealth in The Edge (q2dm1).

             3. Use a grapple node as an alternate route to/from a place
                which might have only one walkable route to/from it.

             4. Use grapple nodes to safely navigate DOWN from great
                heights; then the bot won't sustain falling damage.

         m. On Action Quake2 maps which you have manually placed dooropen nodes
            make sure the path thru the door goes thru a dooropen node in each 
            direction so bots will know if they should check for and open closed
            doors.
            



   You can use any method of walking the map you like as you 'auto' path, as 
long as you walk each path in both directions. I prefer to work 
incrementally: completely path each room, corridor, etc. one by one as you 
encounter them, backtracking as needed to make paths in each direction. For 
example, if I re-spawn inside a room, I'd walk paths to and from each item 
in the room, exit and enter each enterance to the room, walk direct paths to 
and from each enterance to the room, etc. until every possible path in the 
room has been walked, then do same for the next room encountered.
         
    a. If a corridor 'dead-ends' at a teleporter or platform, make sure you 
       walk a path from the dead end back to the entrance of the corridor 
       as well as walking down the corridor and using the teleporter or 
       platform. 

    b. Make sure your paths use every teleporter and platform on the map. 
           
    c. Navigate thru secret doors while pathing just like you want the bot
       to. You will make erroneous links to the nodes on either side of the 
       door; later you need to add the shoot nodes and link/unlink as needed.
                           
3.5 Identifying Unlinked and Unreachable Nodes
----------------------------------------------
  It's pretty easy to miss making links to/from nodes you placed manually,
considering they're invisible. It's difficult to remember if you made paths
to/from each item on a very large map. If you think you've made links to all
the nodes on the map, issue the "unlinked" command (see 2.1). The first 15
nodes that have no link to another node will be listed in the HUD along with 
their coordinates; a colored sphere is drawn at the location of each unlinked 
node. The make_paths cvar should be set to 1, walk around the map, find 
the unlinked nodes and make links to and from them. Repeat until all nodes 
are linked !
  Similarly, issue the cantreach command to find all nodes which don't have 
any other nodes as a link TO the node; find them and link them.

3.6 Adding Shoot Nodes for Secret Doors 
---------------------------------------
You should be finished making all your paths on the map and become a 
spectator (type "spectator 1" at the console). You must place a shoot node 
(type 11) when the path takes the bot thru a secret door. The bot will shoot 
the blaster in the direction of the shoot node until the shoot node is 
visible. You should have placed move nodes on either side of the door that 
can "see" each other thru the open door before you turned make_paths on
and walked the path thru the secret door making links between the nodes on
either side of the door. Become a spectator and 'fly' thru the map until you 
get to the secret door. Then fly thru to the other side of the door to a point 
which the bot will be able to 'see' thru the open door (it's ok if this point 
is well above the ground as long as the bot will be able to 'see' it ) and 
run the 'addnode 11' command to add the shoot node, remove the link from the 
node in front of the door to the node in back of the door, add a link from 
the node in front of the node to the shoot node, then add a link from the 
shoot node to the node in back of the door. That sounds complicated but it 
really is pretty logical; walk to the move node, shoot at the shoot node 
until it is visible, walk to the move node. If the node in front of the door 
is node 55 and the node in back of the door is node 56 and the shoot node is 
node 200 and 55 is already linked to 56 then

	removelink 55 56
	addlink 55 200
	addlink 200 56

creates the corrected path thru the door. If the path also goes the other 
way thru the secret door (from 56 to 55) then you must add  shoot nodes on 
both sides of the door with the appropriate links.


An "illustrated" example:

	S = shoot node
	N = move node
        ... path

	Sideview:
			     SECRET DOOR
	----------------------------------------------------------------
				|     |
				|     |
				|DOOR |
				|     |
				|     |   
				|     |
			S(2)	|     |	      S(1)
				|     |
				|     |
				|     |
				|     |
				|     |
		N(0)..... N(1)..|     |.N(2)..........N(3)
	----------------------------------------------------------------
  
        To get from N(0) to N(3) the path is:

		N(0), N(1), S(1), N(2), N(3)

	The bot gets to N(1), shoots at S(1) until it is visible then
		proceeds to N(2) then N(3)

	To get from N(3) to N(0) the path is:

		N(3), N(2), S(2), N(1), N(0)		


You can also use shoot nodes to get the bot to trigger buttons that must be 
shot to open a door, as long as the button recedes into the wall upon 
activation. Use the same procedure as placing a shoot node to open a secret 
door except become a spectator and 'fly' to a spot just in front the button 
so you're view is just 'inside' the unactivated button and issue the 
'addnode 11' command to add the shoot node; link the nodes as illustrated 
above. The shoot node must *not* be visible to the bot until he shoots the 
button and it recedes into the wall on activation. You'll probably have to 
move the node using the movenode command until you have placed it in the 
optimal position. 

3.7 Relocate Nodes above Teleporters
------------------------------------
   When you've finished making all your paths you *MUST* raise the position
of all teleporter nodes above teleporters so the bot never actually reaches
the node when he walks towards it. This may seem silly but it is a necessary
step because the teleportation event tells the bot he has reached the 
teleporter node. While experimenting with making routes thru teleporters I
found the bot could not reliably detect his "closeness" to the teleporter
node and would easily become disoriented either just before or just after
the teleportation. The best solution was to have the teleporter touch 
function tell the bot that he reached the teleporter node. The trick is that
the teleporter node is manually raised to a point the bot cannot reach; when
trying to reach the teleporter node before he can get close to it he 
teleports which tells him he's reached the node.

NOTE: this applies to teleporter nodes above teleporter nodes, not teleporter
nodes above teleporter destinatons (a design flaw I should have corrected).

  In 'NOCLIP' mode you should "fly" to each teleporter, locate the teleporter
node above it with the "findnode" command (teleporters are type 3) which gives
you the xyz coordinates of the nod; use the "movenode" command to move 
the node about 50 units higher than originally placed.

NOTE: remember, after you do this if you ever turn on make_paths and walk
the path on this map again you'll never get to these nodes! If you go thru
a teleporter while pathing after you've raised the teleporter nodes you'll
screw up the path; either avoid going thru teleporters or manually correct
the links using the "addlink" and "removelink" commands. Better yet, turn off
make_paths, navigate thru the teleporter, then turn make_paths back on.


3.8 Tweaking The Path
---------------------
  Now that you have the map entirely routed set the server cvar make_paths
to 0, save the node table to disk with the server command savenodes, rebuild
the node graph with the server command rebuildgraph, switch to spectator
mode, set the cvar show_bot_ai to 1 to display the bot movement ai in the
HUD and the server cvar show_path_errors to 1:

     make_paths 0
     sv savenodes
     sv rebuildgraph
     spectator 1
     show_bot_ai 1
     show_path_errors 1

  You should have run the unlinked and cantreach commands as specified in 3.5 
and linked any nodes specified as unlinked or unreachable. This will eliminate 
all obvious path errors. Now we will look for not so obvious path errors.

  Setting the show_path_errors server cvar to 1 will cause a bot to report 
any errors the bot encounters when trying to determine the shortest
path from one node to another.

  Add 1 skill 3 bot (sv addbot 3). Watch the bot with the chase cam by 
pressing the +moveup key (jump); you can change the cam view using the
invuse key (usually ENTER). The bot is the only one in the game and won't
find any enemies so he will traverse the map using the path to get to 
items. He picks an item  a good distance away, computes the shortest path 
to the item (which is stored in the graph) and follows the path to the 
item. Then he picks another item, computes the shortest path to it, etc.
Look at dat bot go ! 
  The bot ignores any nodes that are outside the map and any nodes that
have no link from themselves to another node but doesn't determine if a
path exists to a node until he tries to get to it. If you see the message:

     NEXT NODE INVALID FOLLOW PATH GOAL NODE aaa CURRNODE bbb

then a path from node bbb to node aaa cannot be computed. Assuming you've
cleaned up any nodes reported by the unlinked and cantreach commands, this 
error message means there are 1 or more nodes in an "island" of nodes which
are linked to/from themselves but do not have links from any nodes outside 
the "island"; the node specified by aaa is among those nodes in the "island"
and the node specied by bbb is the node outside the island bot is located at.
You must navigate to the "island" of nodes and make links to/from nodes in
the "island" to nodes outside it. You must rebuild the node graph after making
the links (sv rebuildgraph). To verify you've linked to the island,
run the command:

      shortpath bbb aaa

substituting nodes displayed in the error message for the nodes in the command.
If the shortpath command displays -1 instead of a list of nodes in the path
then you haven't eliminated the "island" of nodes.
  
You will also receive the 'NEXT NODE INVALID FOLLOW PATH ...' message when 
show_path_errors is set to 1, the hook is is banned and navigation to an area 
of the level requires using the hook. A bot assumes all nodes that have links
from them are reachable, but won't realize the break in the path due to the lack
of a hook renders the nodes in the area are unreachable until they try to calculate
a route to the node;  when it can't find a route to a node that has links from it
a counter is incrimented for the node signifying the a path could not be found to it,
then the bot does something else for a while. Bots will continue trying to get to
the node until the unreachable counter hits 30, the bots will then ignore the node
as a potential goal node. 



4. Workarounds
--------------

    The l0k0b0t cannot recognize certain entities on maps so you have to 
supply the 'navigation AI' by the clever use of the existing node types. 
Sorry, but the bot cannot detect lasers on maps and if a path walks thru an 
activated laser the bot will merrily walk right into it; there are few 
deathmatch levels with map lasers, so I probably won't add any code to 
support laser detection, just don't create a path thru a 'lethal' laser.


4.1 Jump Pads
-------------

   Even though the bot does not know too much about jump pads, with proper 
   placement of nodes it will be able to navigate them well. Most of the time
   nodes are not placed directly on jump pads, nodes are placed to guide the bot 
   on to the jump pad in the correct direction.



        a. The direction the jump pad pushes you in is the same direction
           as the 'approach' to the jump pad: all nodes N are move nodes (type 0).
           The jump pad is indicated by the JPJP.... Nothing special here,
           just make sure you manually place N(1) just before the jump pad
           and N(2) near the jump destination BEFORE 'auto' pathing; N(1),
           the jump pad and N(2) should form a straight line over the center 
           of jump pad in the xy plane.

	
	(side view)
                                         ^ . . N(2) . . . .
                                      ^     ------------------
                                           |
                                    ^      |
                                           |  ** no need for a node directly
                                   ^       |  on the jump pad
           path --> --> -->                |
                                   ^       |
             N(0) . . . . N(1) . JPJPJPJP  |  place move nodes at all Ns
        -----------------------------------


        b. The direction the jump pad pushes you in is OPPOSITE in direction
           from the 'approach' to the jump pad: all nodes N are move nodes 
          (type 0). The jump pad is indicated by the JPJP.... Place N(1), N(2)
          and N(3) manually BEFORE 'auto' pathing. Yes, node N(2) is placed
          in a position where the bot will activate the jump pad before he 
          reaches the node; the "closeness" requirement (the distance from the
          the bot to the node at which the bot considers he has successfully
          reached the node) is relaxed by a factor of 2 when a bot activates a 
          jump pad. The instant just before the bot activates the jump pad he
          is too far away from node N(2) to consider the node reached but the
          instant he activates the jump pad the distance requirement is doubled
          and the bot now is close enough to node N(2) to consider it reached.
          You may have to become a spectator or use "noclip"  and "fly" to the 
          jump pad to place manually with the addnode command and manually link 
          the nodes with the addlink command.

		
		(side view)
                                            |
             <-- <-- <-- N(3) <--<--        |
           --------------------    ^        |
           --------------------    |        |
                                   ^        |
                                   |        |
                                   ^        |
           path --> --> --> --> -->         |  ** node placed directly over 
                                     N(2)   |     jump pad
           N(0) . . . . N(1) . JPJPJPJP     |
        ------------------------------------



        An angled jump pad which pushes the bot in the opposite direction;
        place move node N(2) manually in 'NOCLIP' mode with the addnode
        command and make links manually with the addlink command.


		(side view)
                                
                  <-- <-- N(3) <-
                  ------------    \
                  ------------     \
                                    \ N(2)P |  
                                     \   J  |     
                                      \ P   | ** node placed directly over 
                 path --> --> --> -->  J    |    jump pad 
                                      P     |    
               N(0) . . . . N(1) . . J      |
         -----------------------------------




4.2 Push Buttons
----------------

   The bot does not recognize push buttons and never knows what function the 
button performs. Through the clever placement of move nodes you can get the 
bot to push buttons to open doors. Sometimes this means you should use a 
portion of the path you create ONLY to push a button and navigate through a 
door. Sometimes this is not worth the hassle; certain maps have so many 
buttons to press to navigate the level that you might consider using the 
grapple for bot navigation, or maybe not path the level at all. If the door
the button opens is not close to the door it opens, don't even bother because
the bot won't make it. For example, the map q2ctf3 is not supported because
the buttons are too far from the the objects the buttons control.

         Examples:

        The func_door marked by the 'DDDD..' is opened when the button protruding
        from the wall (marked by the 'UUUU..') is pressed. Each 'N' signifies
        where you should place move nodes BEFORE you set make_paths on;
        then when you ARE creating 'auto' links make the ONLY POSSIBLE PATH
        through the door PRESS THE BUTTON FIRST. Place N(2) and N(3) close 
        enough to the wall so if a bot moves in a straight line between N(2) 
        and N(3) he'll depress the button by rubbing against it. The ONLY path                 
        to the door should be N(2)->N(3)->N(4)->N(5); the path that DOES NOT 
        go thru the door should be N(0)->N(6)->N(7)->N(8) etc.  Also, the 
        links to/from N(3), N(4) and N(5) ARE CRITICAL; the ONLY link to N(3) 
        should be from N(2), forcing the button to be pressed, and the ONLY 
        link to N(4) from outside the door should be N(3). If, for example, 
        you created a link from N(7) to N(3) or from N(8) to N(4) the bot 
        would not have to push the button on his way to node N(4).

        
           
                                                  |            |
          (looking downward...)                   |            |
                                                  |     N(5)   |
                                                  |      .     |
                                                  |      .     |
                              (button)            |   (door)   |
        __________________________________________|DDDDDDDDDDDD|_________
                                UUUUU                    .
                       .  N(2) .UUUUU .  . N(3) .  .  . N(4)
                    .  route to door -> -> -> -> -> -> ->
               N(0)                        
                    .                      
                       .
                          N(6)  .  .  .  . N(7)  .  .  .N(8) .  .  .  N(9)     
         


      Buttons that activate func_doors that function as platforms are easy
      to path if the button that raises the object is placed in a certain
      way. Below, the UUU stuff indicates a button that activates the
      func_door that acts like a platform (indicated by the DDDD... stuff).
      Set make_paths to 0; use the addnode command to add the nodes and the
      addlink command to link the nodes. Add a move node at N(0) and a doorbottom 
      node at DB(1), push the button and ride the door up to the door's top 
      position, staying directly over the button, add move node N(3) at this 
      location, step off the raised door and add a move node N(4) to get the bot
      off the door. Then add the links with the addlink command, N(0) to DB(1),
      DB(1) to N(2) and N(2) to N(3). 

            (side view...)            

                   N(3)     N(2) <----- move node placed over the the push button;
             ---------------            the bot pushes the button when trying to
                           |.           get to from DB(1) to N(2).
                           | 
                           |.
                           |
                           |
                           |.           Path: N(0)->DB(1)->N(2)->N(3)
                           |
                           |.
                           | 
                           |.
                           |
                           |.
                           |
                           UUU
            push button -> UUU                     <------ direction of pather/bot
                           UUU
                           |
                           |. . . . DB(1). . . . . . .
                           | DDDDDDDDDDDDDDDDDDDD     .
                           | DDDDDDDDDDDDDDDDDDDD      . . N(0)
                                    ^
                                 func_door
            


5.0 Other Advice
----------------

5.1 Deep Thoughts about The Path
--------------------------------
1. The bot determines the shortest path possible between two nodes only from 
   the links made by the pather; it assumes that if there is no link from node a 
   to node b that you can't navigate from node a directly to node b.

2. When computing the shortest path, there are 'rewards' and 'penalties' doled
   out while determining the distance between two nodes adjacent in the path
   (a direct link from one node to another):

   a. Water nodes and all nodes submerged in water are 'penalized' by artificially
     increasing the computed distance between them by a factor controlled by the
     server cvar bot_hydrophobia. Decreasing the value of bot_hydrophobia will
     decrease the distance penalty, causing the bot to choose more watery routes.

   b. The distance from one node to a grapple node is 'rewarded' by artificially 
     decreasing the computed distance by a factor of 2; ie. the computed distance 
     is halved. If the server cvar no_hook_navigation is set to 1 the distances
     to and from grapple nodes are 'penalized' by setting the computed distances
     to infinity.

   c. The distance from a teleporter node to another node more than 192 units 
      away is 'rewarded' by setting the computed distance to 64 units when the
      server cvar teleport_dislike is set to 0; when set above 0 a penalty
      proportional to the value of teleport_dislike is imposed.

   d. The distance between the bottom node and top node of a platform is neither
      rewarded nor penalized.

   e. The computed distance to or from a shoot node is set to 128 units which
      may be a penalty or a reward.

   f. The distance from one node to a train node is neither rewarded nor 
      penalized when the server cvar train_dislike is set to 0; when set above 
      0 a penalty proportional to the value of train_dislike is imposed.

   f. For all nodes that aren't teleporter, grapple, shoot, visible, notvisible
      or platform nodes, if the actual distance from one node to another is greater 
      than 192 units then the computed distance is rewarded by setting it to half 
      the actual distance. If you've followed these instructions and made a quality 
      path then the only times this should occur is a large change in elevation 
      between nodes (jumping off a tall cliff into a body of water) or the bot must
      navigate between distant nodes using a jump pad or wind tunnel.

3. Generally, the order in which the links are made from one particular node
to any adjacent nodes that can be navigated to is inconsequential, ie. all
links are always tested when determining the shortest path between two nodes.
   There is one important exception, being the nodes linked FROM the node closest
to a team flag when the game is CTF. When playing CTF, some bots will defend their 
base by patrolling the area around their team's flag. A bot patrolling it's teams 
base will **ALWAYS !!!** choose **THE FIRST NODE LINKED FROM** the node closest 
to it's team flag as a base node to patrol from; he will navigate to that base node, 
when he gets to it he picks a random node that is between 300 and 600 quake units 
away as a temporary destination node, navigates to this temporary destination node,
upon reaching the temporary destination node the bot heads back to it's base 
patrol node , chooses another temporary destination node and repeats this cycle. 
It might be easier to explain what is NOT desirable as a base patrol node and why:

   a. You don't want the base patrol node to be a teleporter node over a teleporter;
      the bot may be teleported to the other side of the map, making his patrol
      route a significant portion of the map and leaving the bot far from the
      flag it's supposed to be patrolling.

   b. You don't want the base patrol node to be a node type that requires a 
      discreet action to reach other than walking or swimming. On it's own,
      a bot only chooses nodes of type move, water and item as destination nodes;
      one reason for this is when the bot reaches it's destination node it
      forgets this node and re-determines it's current node, only choosing nodes
      of type move, water, item, or teleporter as a current node. A grapple node
      or the bottom node of a platform node pair might not have any nodes near
      of type move, water, item, or teleporter; if a bot determining it's current
      node can't find any nodes of these types close it will become disoriented 
      and start to wander. Also, a bot will become confused if it's destination 
      node is a platform, doorbottom, doortop or dooropen which he may have to 
      wait for the door or platform associated with the node to be in the proper 
      position of it's destination node is a shoot node.

So try to make the first node linked FROM the node closest to a CTF team flag
a node of type move, water or item.



5.2 Ways to Test The Path
-------------------------
After you've completed making paths on the map, here's a number of suggestions
for testing the path. 

1. a. Use the noclip command to enter NOCLIP mode (fly thru walls)
   b. Pick an arbitrary point on the map, use the findnode command to 
      find a close node (node1)
,  c. Fly a good distance away and pick another arbitrary point, use the
      findnode command to find a close node (node2)
   d. Run the showpath command to show the path back to node1 ie. if node1
      was 50 and node2 was 422:
		showpath 422 50
      The nodes of the path are represented by glowing spheres and the links
      between the nodes are represented by the 'debugtrail' effect.

2. Set the cvar ctf to 1, add a few bots to one team and use the chase cam
   to watch the bots navigate around the level.

3. To test navigation to a specific node, set the cvar ctf to 1, join a team
   and add one bot to your team; set the server cvar verbose_ctf_bots to 2.
   Use the role command to command the bot on your team to patrol the node,
   ie. if the bot is named b1 and the node you want the bot to navigate to
   is node 401 the command would be 'role b1 patrol 401' or 'role b1 p 401'.
   See the lOkO manual for more info on commanding team bots.
   


5.3 Optimal Path Creation in Large Open Areas
---------------------------------------------
   I define a "Large Open Area" as an area of mostly open space on fairly 
level ground (or in water) that has dimensions > 500 units in each horizontal 
direction. 
   The idea here is to create a grid of nodes fairly evenly spaced over 
the entire area to minimize the amount of nodes used and assure a node
and path exist at any given point in the area.



1. Set debug_pathing to 1 (on) and make_paths to 0 (off). And I can't
   say this enough: bind a key to the findnode command 
     (ie. bind F11 "findnode")
   and the "addnode 0" command (bind F5 "addnode 0") for dropping move 
   nodes.
2. Drop move nodes at entrances/exits to/from the area, if any.
3. Pick a spot close to the perimeter of the area near an existing node;if 
   no node is close then add a move node at your location. You should not be
   "hugging" the perimeter, you should be about 32 units away.
   Remember this spot for reference later (write down the node number you 
   started at). 
4. Navigate along the entire perimeter of the area, any time you travel
   about 128 units from an existing node and no node exists at your 
   position drop a move node. If you reach a corner in the area drop a
   move node there if there is no existing node within 64 units 
   of the corner. Continue along the perimeter until you reach the node 
   you started at on step 3.

       Top View
       ---------
                ~128 units
         Scale |______|  M = move node

                            |   M     M    |
         ___________________               ___________________________________
         |                                                                    |
         | M     M      M     M    M    M        M      M      M      M    M  |
         |                                                                    |
         |                                                                    |
         |                                                                    |
         | M                                                               M  |
         |                                                                    |
         |                                                                    |
         |                                                                    |
         | M                                                               M  |
         |                                                                    |
         |                                                                    |
         |                                                                    |
         | M                                                               M  |
         |                                                                    |
       ---                                                                    |
                                                                              |
      M    M                                                               M  |
                                                                              |
                                                                              |
       ---                                                                    |
         | M                                                               M  |
         |                                                                    |
         |                                                                    |
         |                                                                    |
         | M                                                               M  |
         |                                                                    |
         |                                                                    |
         |                                                                    |
         | M     M      M     M    M    M        M      M      M   M  M    M  | 
         |______________________________________________________       _______|
                                                                |  M   |



5. Navigate to a corner of the area (if the area is circular then pick
   an the location of an arbitrary node on the perimeter). You should have
   dropped a move node at the corner. Now navigate along 1 wall about
   128 units away from the corner (since you "noded" the perimeter
   there should be a node close). Now turn facing away from the wall and
   navigate 128 units forward. Drop a move node if your not close to 
   an existing node. Move forward another 128 units . Again, if no
   node is close, drop a move node. You want to end with a grid like this:

       Top View
       ---------
                ~128 units
         Scale |______|  M = move node

                            |   M     M    |
         ___________________               ___________________________________
         |                                                                    |
         | M     M      M     M    M    M        M      M      M      M    M  |
         |                                                                    |
         |                                                                    |
         |                                                                    |
         | M     M      M     M    M    M        M      M      M      M    M  |
         |                                                                    |
         |                                                                    |
         |                                                                    |
         | M     M      M     M    M    M        M      M      M      M    M  |
         |                                                                    |
         |                                                                    |
         |                                                                    |
         | M     M      M     M    M    M        M      M      M      M    M  |
         |                                                                    |
       ---                                                                    |
                                                                              |
      M    M     M      M     M    M    M        M      M      M      M    M  |
                                                                              |
                                                                              |
       ---                                                                    |
         | M     M      M     M    M    M        M      M      M      M    M  |
         |                                                                    |
         |                                                                    |
         |                                                                    |
         | M     M      M     M    M    M        M      M      M      M    M  |
         |                                                                    |
         |                                                                    |
         |                                                                    |
         | M     M      M     M    M    M        M      M      M   M  M    M  | 
         |______________________________________________________       _______|
                                                                |  M   |

6. Set make_paths 1 and navigate to the area.

7. You're creating the paths now. Enter the area and navigate the entire 
perimeter in one direction; when you come to an entrance/exit navigate in
and out of each entrance/exit to link this area with other areas. Once you
have navigated the entire perimeter in one direction, navigate the entire
perimeter in the opposite direction.

       Top View
       ---------
                ~128 units
         Scale |______|  M = move node  @ = path created

                            |   M     M    |
         ___________________               ___________________________________
         |                                                                    |
         | M  @ M   @   M  @  M  @ M  @ M  @  @  M  @ @ M @ @  M @ @  M  @ M  |
         |                                                                    |
         | @                                                               @    |
         |                                                                    |
         | M     M      M     M    M    M        M      M      M      M    M  |
         |                                                                    |
         | @                                                               @  |
         |                                                                    |
         | M     M      M     M    M    M        M      M      M      M    M  |
         |                                                                    |
         | @                                                               @  |
         |                                                                    |
         | M     M      M     M    M    M        M      M      M      M    M  |
         |                                                                    |
       --- @                                                               @  |
                                                                              |
      M  @ M     M      M     M    M    M        M      M      M      M    M  |
                                                                              |
            @                                                                 |
       ---                                                                    |
         | M     M      M     M    M    M        M      M      M      M    M  |
         |                                                                    |
         | @                                                                  |
         |                                                                    |
         | M     M      M     M    M    M        M      M      M      M    M  |
         |                                                                    |
         | @                                                               @  |
         |                                                                    |
         | M  @  M   @  M  @  M  @ M  @ M   @    M   @  M   @  M @ M @ M @ M  | 
         |______________________________________________________       _______|
                                                                |  M   |
           ^
           | "north"

8. Now that the perimeter has been "pathed", we want to link the nodes away 
from the parimeter. Navigate to a corner of the area, in the above example 
start at the lower left corner. Now move "east" along the "southern" wall 
until you reach the first "column" of nodes off the "west" perimeter; use the
findnode command to show the closest node to you (bind a key ...).
Navigate up AND down the "column" of nodes. Move "east" along the 
"southern" wall to the next "column" and do the same, navigate up and down
the column of nodes. Repeat for all the remaining "columns". Then do the
all "horizontal" rows in each direction, east and west.

       Top View
       ---------
                ~128 units
         Scale |______|  M = move node  . = path existed  @ = path created

                            |   M     M    |
         ___________________               ________________________________
         |                                                                 |
         | M  . M   .   M  .  M  . M  . M  .  M  . . M . .  M . .  M  . M  |
         |                                                                 |
         | .     @      @     @    @    @     @      @      @      @    .  |
         |                                                                 |
         | M  @  M  @   M  @  M  @ M  @ M  @  M   @  M   @  M   @  M  @ M  |
         |                                                                 |
         | .     @      @     @    @    @     @      @      @      @    .  |
         |                                                                 |
         | M  @  M  @   M  @  M  @ M  @ M  @  M   @  M   @  M   @  M  @ M  |
         |                                                                 |
         | .     @      @     @    @    @     @      @      @      @    .  |
         |                                                                 |
         | M  @  M  @   M  @  M  @ M  @ M  @  M   @  M   @  M   @  M  @ M  |
         |                                                                 |
       --- .     @      @     @    @    @     @      @      @      @    .  |
                                                                           |
      M  @ M  @  M  @   M  @  M  @ M  @ M  @  M   @  M   @  M   @  M  @ M  |
                                                                           |
           .     @      @     @    @    @     @      @      @      @    .  |
       ---                                                                 |
         | M  @  M  @   M  @  M  @ M  @ M  @  M   @  M   @  M   @  M  @ M  |
         |                                                                 |
         | .     @      @     @    @    @     @      @      @      @    .  |
         |                                                                 |
         | M  @  M  @   M  @  M  @ M  @ M  @  M   @  M   @  M   @  M  @ M  |
         |                                                                 |
         | .     @      @     @    @    @     @      @      @      @    .  |
         |                                                                 |
         | M  @  M  @   M  @  M  @ M  @ M  @  M   @  M   @  M   @  M  @ M  |
         |______________________________________________________  .  . ____|
                                                                |  M   |
           ^
           | "north"


9. The last step, linking the nodes diagonally! Refer to the neato illustration 
   *below*:

    Go to the node closest to A; 
    Go to the node closest to B, then back to A.
    Go to the node closest C, then to D, then back to C.
    Repeat until you finish J to K to J.
    Now Go to P, then Q, then back to P.
    Go to R, then S, then back to R.
    Repeat until you finish X to Y to X. 


       Top View
       ---------
                ~128 units
         Scale |______|  M = move node  . = path  @ = path created

                Q       S   |   M     M    |                       K
         ___________________               ________________________________
         |                                                                 |
         | M  . M   .   M  .  M  . M  . M  .  M  . . M . .  M . .  M  . M  |
         |                                                                 |
         | .  @  .  @   .  @  .  @ .  @ .  @  .  @   .   @  .   @  .  @ .  |
         |                                                                 |
        P| M  .  M  .   M  .  M  . M  . M  .  M   .  M   .  M   .  M  . M  | J
         |                                                                 |
         | .  @  .  @   .  @  .  @ .  @ .  @  .  @   .   @  .   @  .  @ .  |
         |                                                                 |
        R| M  .  M  .   M  .  M  . M  . M  .  M   .  M   .  M   .  M  . M  |
         |                                                                 |
         | .  @  .  @   .  @  .  @ .  @ .  @  .  @   .   @  .   @  .  @ .  |
         |                                                                 |
         | M  .  M  .   M  .  M  . M  . M  .  M   .  M   .  M   .  M  . M  |
         |                                                                 |
       --- .  @  .  @   .  @  .  @ .  @ .  @  .  @   .   @  .   @  .  @ .  |
                                                                           |
      M  . M  .  M  .   M  .  M  . M  . M  .  M   .  M   .  M   .  M  . M  |
                                                                           |
           .  @  .  @   .  @  .  @ .  @ .  @  .  @   .   @  .   @  .  @ .  |
       ---                                                                 |
        D| M  .  M  .   M  .  M  . M  . M  .  M   .  M   .  M   .  M  . M  |
         |                                                                 |
         | .  @  .  @   .  @  .  @ .  @ .  @  .  @   .   @  .   @  .  @ .  |
         |                                                                 |
        B| M  .  M  .   M  .  M  . M  . M  .  M   .  M   .  M   .  M  . M  |Y
         |                                                                 |
         | .  @  .  @   .  @  .  @ .  @ .  @  .  @   .   @  .   @  .  @ .  |
         |                                                                 |
         | M  .  M  .   M  .  M  . M  . M  .  M   .  M   .  M   .  M  . M  |
         |______________________________________________________  .  . ____|
                 A      C                                     X |  M   |
           ^
           | "north"

  

5.4 Jump Node Additional Notes
------------------------------
1. When you add a Jump node either with the 'addnode 7' command or jumping when 
the make_paths cvar is set to 1 the node is placed at the origin of the 
your player model, 24 quake units above the ground. This assures that bots 
jumping up to node will clear any ledge it might encounter. Occasionally you
will want the bot to jump up to, say, the ledge of an open window and the 
height of the open window is barely greater than the Quake2 player model.
When a bot encounters a node of type jump it's velocity is boosted towards
the jump node. If you place the jump node on the open window ledge and leave
it at it's default position 24 units above the window ledge, when the
bot encounters the node it will boost it's velocity towards the node but
it can't navigate thru the open window because it's 'head' is hitting the
wall above the window opening; the bot will appear to hang in the air against
the wall for a number of seconds. To fix this you can safely move a jump node
up to 8 units down from the default location of 24 units above ground, ie.

running the findnode command returns:
	node: 27 type: 7 x: 245.000 y: -822.25 z: 96.125

move the node down 6 units with the movenode command:
	movenode 27 245.0 -822.25 90.125

running the findnode command again returns:
	node: 27 type: 7 x: 245.000 y: -822.25 z: 90.125

You may have to experiment to find the optimal height of the jump node, this
depends on the height of the opening.

2. You will want to place a move node very close to any jump nodes you place
if a node of type move, item, water, or teleporter does not exist nearby,
especially near a jump node at the top of a ladder.

     Jumping both ways across a gap...

	Side View : N = move node   J = jump node  ... = path

         |                                                     |
         | . . . . N(0) J(0) . . . . . .  J(1) N(1) . . . .    |
         ___________________               ____________________|
                            |             |
         ___________________               ____________________
         |                                                     |
         |                                                     |
         |                                                     |
         |                                                     |
         |                                                     |

3. Avoid having a jump node as a direct link to a node of type platform,
door open, door bottom or door top; the bot tends to "fly" up to the 
platform node. Try placing a move node with an added crouch flag between
the jump node and the platform.


5.5 Grapple Node Additional Notes
---------------------------------
1. When make_paths is set to 1 and you fire the grappling hook a grapple
node is placed at the hook impact point if no close grapple nodes exist.
You can also create a grapple node with the addnode command (ie.addnode 6).
Grapple nodes should be placed where a vertical surface (a wall) will stop
the bot's horizontal motion.

2. Grapple nodes can be placed or moved as far as 64 units away from a wall,
floor or ceiling. This may be advantageous in situations where the grapple
node is placed at the corner of two surfaces. If the bot fires the grapple
or off-hand hook and the point where the hook sticks to a surface is more 
than 64 units from the node the bot is trying to reach he will continually
retract and fire the hook, never reaching the node.

3. If possible, avoid making paths where the only route to an area uses grapple
nodes; if the hook is banned bots won't be able to calculate a path to any items
in the area and will never go there.