Omni-bot Waypointing
From Omni-bot Wiki
| Main Page | Omni-bot Waypointing |
What are waypoints?
Omni-bot, like every bot needs a data structure that it can use to find its way around the map. Nearly every bot requires waypointing of some sort, whether it be automatically calculated from looking at the map geometry or hand placed like the majority of 3rd party bots.
Waypoints are basically a graph representation of the map geometry. Waypoints are vertices, and paths between them are edges. When a bot wants to get from where he his to a destination, the waypoint graph is used to find the way.
Waypoints are stored in .way files in the nav directory.
Important Waypoint Notes
Enemy Territory uses a unique method of drawing waypoints. At first, lines were drawn similar to g_debugbullets, but this method uses an entity for each line, and is dependent on free entities and scales horribly to large numbers of drawn lines. Unfortunately, the debug drawing functionality present in vanilla Quake3 bot lib seems to have been removed in ET. With the entity based drawing, the client would hitch every 2 seconds while they recieved a new snapshot containing hundreds of lines. My solution to this problem was to set up an interprocess communication channel between the bot dll and the ET client dll(cgame). This means that the bot dll and client DLL communicate with a message queue of draw requests. The resulting system is much more capable of drawing much larger numbers of lines(now limited only by the polygon buffer on the client) without being constrained by free entities, and without hitching the client or bad flickering of waypoints.
This method is not without its quirks. Due to how the InterProcess Communication works, it requires the use of a temporary file. To make sure it can create this temporary file, make sure you have the following.
- Linux: A temporary directory pointed to by TMP or TEMP environment variable. They are checked in that order.
- Windows: A temporary directory pointed to by TMPDIR, TMP, or TEMP environment variable. They are checked in that order.
Waypointing in ET
Due to the special method of waypointing in ET, waypointing is only available in the omnibot mod, which is a modification of etmain. This means you cannot waypoint in etpub, jaymod, or NQ. The authors of these mods and I thought it best to not add a needless dependency to their mods client dll. If you need to waypoint in ET, run the omnibot mod as a listen server, and run cg_omnibotdrawing 1 in the client console. Waypointing is not supported on dedicated servers, you must run a listen server.
A recap.
- Waypoint only in omnibot mod in ET. Not in the mod(s) etpub, jaymod, or NQ.
- cg_omnibotdrawing 1
- listen server only
Backwards Compatibility
Occasionally the waypoint file format needs to be updated in order to support a new feature. Whenever this happens, Omni-bot is still capable of loading old version waypoints, and will save them as the new format if you waypoint_save them. Omni-bot isn't however, forward compatible. That means old versions of Omni-bot cannot load a waypoint version file that was added in a newer version.
How do bots use waypoints?
A basic understanding of how the bots use the waypoint graph can help you make good decisions on how to place waypoints, how to set radius, and how to understand when things might not be behaving as expected.
When a bot spawns into the map and decides where to goal, he performs a path search to determine how to get there. The overview of how the path search works is:
- Get the closest allowed waypoint to the bot.
- Get the closest allowed waypoint to the goal.
- Find a path between them, ignoring paths through waypoints that are limited to other teams, closed, or that exceed the bots movement capabilities.
Getting Stuck
Bots can't move perfectly, and sometimes they can fall off edges or otherwise get pushed or dislodged from their intended path, usually due to weapon push or game physics. When this happens, they can sometimes get stuck. When the bot is unable to make meaningful progress in his path for a small amount of time, it assumes it has become stuck, and the current path attempt will fail. The important part of this process is that there is suitable waypoint placement to recover from getting stuck. Here's an example.
In this screenshot, we see a path that goes across the top of the thin wall. Occasionally the bot may fall off the wall and end up in the small square enclosure below it. You may not think it necessary to place waypoints on that square area below the edge, because the bot should never need to go there, but without the 3 waypoints, when the bot falls down and fails his goal and goes to re-plan a new path, we need to make sure he finds a starting waypoint in a reachable location. If we didn't have the waypoints in the square area below the wall chances are he would pick the waypoints on top of the wall as the nearest points to start from, and result in a stuck loop since he can't get to the waypoints on top.
Here's another example that illustrates this kind of problem. In the following screenshot, the bot is obviously trying to reach the waypoint marked 1, because this is the closest waypoint to the bot's current position. An obvious solution would be to add another waypoint, close to the spot marked 2 in the image, and (bi)connect it to some other waypoint on the right.
This is a common problem with stuckage in maps. By understanding this you should be able to pick out areas of a map that could have this problem. Simply place a waypoint in the corner where they tend to get stuck and link it back to make them backtrack a bit and try again.
Also see the section about blockable paths below. Failure to mark paths as blockable is another very common cause of stuckage problems.
How to waypoint
- Overview
- Start a listen server
- Load a map
- Join as a player (it won't work while you're spectating)
- Enable waypoint view: /bot waypoint_view 1
- Place waypoints while running around the map as a normal player would: /bot waypoint_add
- Connect waypoints: /bot waypoint_(bi)connect
- Save the waypoints to a file: /bot waypoint_save
- Create a script for the map that provides hints and assists the bots to focus on applicable goals. (This is strongly recommended, but might be unnecessary on very simple maps.)
See the Enemy Territory Waypointing Tutorial.
Waypoint Visual Aids
These screenshots show the waypointing aids in their default color configurations.
This is what a single waypoint looks like after a waypoint_add command. The vertical line is the visual representation of the waypoint. When aiming at waypoints, you will see a circular configuration representing the waypoints radius. The size will vary according to the radius of the waypoint and is useful to determine just how large the radius actually is. The default radius shown here is 35 game units, which is almost always a good choice to start with.
When connecting waypoints, it is important to understand how connections are displayed. In this screenshot, it shows 2 waypoints connected by a one way path. We know the connection here is from the left waypoint to the right because of the angle of the link. Link direction is shown with a downward sloping link. The reason for this is because a slope is a better indication of direction and one/two way links than a single line, even if it is colored differently.
Here we see what a two way connection looks like. Since there is a connection going both ways, the resulting link appears as an 'X' between the waypoints.
Special Case Waypointing
Although not required, there are some configurations of waypoints that can help streamline bot navigation a bit. T-connections for example can be waypointed with triangular shape of 3 waypoints in order to have a bit more control over the bots corner cutting. This isn't a required configuration for T-connections, and you can get pretty much the same behavior by increasing the radius of the waypoint at the intersection.
Doors are typically waypointed depending on how they operate. In many games, doors are automatic and simply open when the player approaches them. It isn't necessary to do anything special in the case of those doors. In some games, doors have to be 'used', such as in Enemy Territory. In these cases, the "door" waypoint flag is useful. The "door" flag is used by adding the flag to the 2 waypoints on either side of a door. This tells the bot to hit the USE key while moving across the link between the 2 waypoints. In this picture we see both waypoints flagged with door, and in this case they are team specific.
See also: an extra page on adding sniper spots to a map.
Placing Waypoints at MGs
Before placing waypoints at an MG, you should ideally display the MG's bounding box, using the command
/bot draw_goals on ".*mg42.*"
Then make sure you place the waypoint immediately in front of one of the horizontal edges of the bounding box, not at one of its corners. This will make it much easier for the bots to mount the MG.
The following screenshot 1 shows a good position for a waypoint, screenshot 2 a bad one:
Although screenshot 2 shows a position that is a perfectly natural way for a human player to approach the weapon, it is badly suited for the bots' navigation. Frequently this will result in strange bot movements, as shown in screenshot 3:
Blockable Waypoints
Blockable waypoints are a special case flag that deserves special mentioning. Similar to doors, the blockable flag needs to be placed on both sides of the object. Additionally, the blockable flag must be used in conjunction with another flag that determines the type of blockable path that is desired. Blockable paths are a feature of Omni-bot that allow paths to update their own blocked status, saving some scripting effort. The type of flag used in addition to the blockable flag determines how they figure out their blocked status.
- Blockable Types
- wall - If line of sight check passes between the 2 waypoints, the path is opened, otherwise it is closed.
- bridge - If an object isn't detected half-way between the 2 waypoints(such as a bridge), the object is blocked, otherwise it is open.
In the picture above, we see the dynamite wall in the old city in the oasis map. To manage the connection between the waypoints on either side of the wall, it is using the "blockable" and "wall" flag. On the left side, when the wall is present, the path is blocked, which is shown by the red line as the link. On the right, when the wall is destroyed, the line of sight test passes and the path is opened up automatically.
This is an example of a use for "blockable" and "bridge". The check for "bridge" is basically a probe to see if there is a surface detected under the link between the waypoints. When there is no bridge built, the probe doesn't detect the surface, and results in a blocked path. When the bridge is built, the surface is detected, and the link is opened.
Due to this method of detecting the blocked status of a path across a bridge, rope bridges and similar constructions with a slightly curved shape may require three or more waypoints, all of which should have blockable and bridge flags. Otherwise, the detection of a surface beneath the path might fail, as can be seen in this example (taken from the Bergen map):
With more than two waypoints, the path is correctly recognized as usable by the bots:
In a few cases, it makes sense to use both the wall and bridge flag on a single waypoint. The example below shows a bunker entrance with a destructible barrier in front of it (from the JFF Playground map). Waypoint 1 is marked blockable and bridge, waypoint 3 (inside the bunker) has the blockable and wall flag set, while waypoint 2 has all three flags: blockable, wall, and bridge. This is because it is connected to two different blockable waypoints. Depending on the status of the wooden barrier, the paths 2-3 and 2-1 will toggle between blocked and unblocked. (The reason for this complicated construction is that the bots should jump through the small opening marked 0 in the image if the barrier is intact.)
A similar example: The following screenshot shows a destructible assault ramp, again taken from JFF Playground. All the waypoints shown here, except 4, have the blockable and bridge flags set, waypoints 1 and 4 blockable and wall. When the ramp has been built, the path 1-4 is blocked, while 1-2-3 is free:
When the barrier is destroyed, the status of both paths is toggled:
Additionally, a new waypoint 5 (partly hidden by the crates) was added between the shots. The monodirectional connections 2-5 and 3-5 tell the bots that they can move from 2 or 3 to 5, but not vice versa.
You may wonder what waypoint 4 in the above example is good for. While it is not strictly necessary, it is not a bad idea to have it, mainly for two reasons: Without waypoint 4, a bot that got pushed under the barrier due to some circumstances would try to move towards waypoint 2 (because it's the closest one) and get stuck there. The connection between 4 and 5 enables the bot to find a working path back. Furthermore, waypoint 4 is probably a good place for engineer bots to plant dynamite, slightly better than 2, because it it is less exposed.
Keep in mind that paths can be blocked by vehicles too. All the waypoints along the path of a vehicle should have the blockable and wall flag set. There is a page dedicated to vehicle pathing.
Waypointing Tips
- Save often. Although the bot is pretty stable, it is a good habit to save often.
- Disable the time limit of the map or set it to something very high if possible. In ET, use the command /ref timelimit 0 to have unlimited time on a map. If a map restarts while you are editing waypoints, your unsaved changes will be lost.
- When learning to waypoint, spend some time looking at existing waypoints, in particular the ones handled by the main Omni-bot developers.
- Have a decent understanding of the objectives of the map. It should help you create more direct paths between spawn areas and the objectives each team will likely be heading for during play.
- Understand the radius. The radius is effectively the tolerance for moving toward a waypoint. If you need the bot to get closer, use a smaller radius, if the waypoint represents a large room, use a large radius.
- Don't use radius values of less than 10-20 or so. You may need to experiment with this.
- TEST. There is no substitution for testing when it comes to verifying the bots can accomplish the objectives and that any problem spots for navigation can be recovered from. Play through full matches on both sides as well as spectator to watch the bots as they navigate.
- Make sure to place waypoints in areas where the bots can accidentally get off the main path.
- Try and limit useage of one way paths. Keep in mind that the bots use pathing for short term goals as well, so any area that a player or bot may need to be revived should have two way connections.
- If you see a bot get stuck during waypoint testing, add waypoints to the area while the bot is still stuck. The waypoints are updated dynamically so you should see the bot use any new waypoints you add to unstick them.
- Use key bindings. This does not only save a lot of typing. In some situations (e.g. with underwater waypoints) it may even be close to impossible to edit waypoints without shortcut keys. In ET for example, a bot command is bound to a key using the following command in the game console: /bind <key> "bot <command>". For example: /bind f5 "bot waypoint_setradius 25"
- You can easily save lots of these bind commands to a plain text file, say waypointing.cfg, and later execute this file by issuing the following in the console: /exec waypointing.cfg
- Use the game's devmap command to load the map, e.g. /devmap Venice. This enables a 'cheat mode' that enables you to walk through walls, warp to a certain position, etc. Read more about devmap.
- If the map is based on an "escort the vehicle" mission, read about the Vehicle Pathing utility before you start. It may save you a lot of trouble.
Waypoint Commands
Waypoint commands are accepted through the games console, and can commonly be assigned to key bindings in the supported games.
Executing a command
- In ET, ETF, or other Quake 3 engine based games - /bot waypoint_view 1
- In Quake4, Fortress Forever, and other Half-life 2 or Doom 3 engine based games, the / isn't required, so simply: bot waypoint_view 1
NOTE: ALL of these commands, except waypoint_view can only be executed when waypoint_view is enabled.
waypoint_add
Usage: waypoint_add
Example: waypoint_add
- Adds a waypoint at the location where you are currently standing. When executing waypoint_add, a new waypoint will be created at the location you are currently standing. Some waypoint flags may be automatically placed on the waypoint.
- If the waypoint is underwater, the underwater flag should be automatically added.
- If you are crouching when you place the waypoint, the crouch flag should be automatically added.
- If you are proning when you place the waypoint, the crouch flag should be automatically added instead of adding prone flag.
waypoint_addflag
Usage: waypoint_addflag flags[string] ...
Example: waypoint_addflag crouch
- Flags the nearest waypoint with named properties, or clears the flag from the waypoint if it already exists. This command can take any number of waypoint flags. See the list of flags below.
waypoint_addflagx
Usage: waypoint_addflagx flags[string] ...
Example: waypoint_addflagx crouch
- Same as waypoint_addflag, only instead of the nearest waypoint, uses the waypoint you are currently aimed at.
waypoint_autobuild
Usage: waypoint_autobuild dc[1/0] bbox[1/0] limitheight[#] limitdist[#] maxconnections[#]
Example: waypoint_autobuild 1 0 32 1024 4
- This command automatically creates connections between waypoints based on the parameters used. It is a time saving function that can generate a pretty good starting point for paths between waypoints. It is not meant to do all the work for you, and will likely need additional cleanup after using where you may need to add additional connections it missed, or removed bad connections in may have added.
- dc - Disconnect all current connections before auto connecting.
- bbox - Use a small bounding box when casting the ray between waypoints. Useful for filtering out some connections that clip closely to a wall.
- limitheight - Only make connections to waypoints that are only within this height difference. Useful to prevent connections between multiple levels in a wide open room, even if there is line of sight between them.
- limitdist - Only make connections to other waypoints within this distance.
- maxconnections - Only make a maximum of this many connections. 3-5 tends to be a good range to start with.
waypoint_autoradius
Usage: waypoint_autoradius all/cur[string] height[#] minradius[#] maxradius[#]
Example: waypoint_autoradius all 32 20 200
- Automatically detects a waypoint radius on the nearest or all waypoints(depending on 1st parameter).
- all/cur - all performs autoradius on all waypoints, cur performs it on the nearest.
- height - A vertical offset from the waypoint position to perform the collision tests with. This is useful due to differences in waypoint position between games. In Doom3 & HL2 engine games, the position is at the ground, while in ET the position is about half-way up a players height.
- minradius - The minimum radius to use.
- maxradius - The maximum radius to use.
waypoint_benchmark
Usage: waypoint_benchmark
Example: waypoint_benchmark
- Development tool. Executes a path search between every waypoint and every other waypoint. Used to test the speed of the path finding system.
waypoint_benchmarkgc
Usage: waypoint_benchmarkgc iterations[#]
Example: waypoint_benchmarkgc 1
- Development tool. Performs a GetClosestWaypoint test with every waypoint. Used to test the speed of nearest waypoint lookups.
waypoint_benchtrace
Usage: waypoint_benchtrace iterations[#]
Example: waypoint_benchtrace 1
- Development tool. Performs a traceline collision test between every waypoint. Useful for internal testing of traceline speed.
waypoint_biconnect
Usage: waypoint_biconnect
Example: waypoint_biconnect
- Same as waypoint_connect, but results in a 2 way connection between the waypoints.
waypoint_biconnectx
Usage: waypoint_biconnectx
Example: waypoint_biconnectx
- Same as waypoint_connectx, but results in a 2 way connection between the waypoints.
waypoint_changeradius
Usage: waypoint_changeradius change[#]
Example: waypoint_changeradius -10
- Change the radius of the nearest waypoint by the change amount. Useful if you want to bind a increase and decrease radius key, such as a mouse wheel.
waypoint_clearallflags
Usage: waypoint_clearallflags flags[string] ...
Example: waypoint_clearallflags crouch
- Clears a list of flags from all waypoints in the map. Like waypoint_addflag, it can take any number of flag names, and clears the flags from all waypoints in the map. Useful if you want to remove all of a particular flag from a map.
waypoint_clearcon
Usage: waypoint_clearcon
Example: waypoint_clearcon
- Clears all the connections from the nearest waypoint or all selected waypoints(if any).
waypoint_clearproperty
Usage: waypoint_clearproperty name[string]
Example: waypoint_clearproperty bias
- Clears a property from a waypoint by its name.
waypoint_color
Usage: waypoint_color
Example: waypoint_color type[string] red[#] green[#] blue[#]
- Allows colors to be configured for certain types of waypoints.
- waypoint_color - Default color of waypoints.
- waypoint_selected - Selected waypoints.
- link_closedcolor - If the waypoint has a closed flag.
- link_teleport - If the waypoint has a teleport flag.
- link_1way - One-way connection links.
- link_2way - Two-way connection link.
- blockable_blocked - Blockable line indicators when it is blocked.
- blockable_open - Blockable line indicators when it is open(unblocked).
- aimentity - Color of the box drawn around entities when you aim at them with waypoint_view enabled.
- radius - Color of the radius indicator.
- team1 - Team 1 flagged waypoints
- team2 - Team 2 flagged waypoints
- team3 - Team 3 flagged waypoints (not for ET)
- team4 - Team 4 flagged waypoints (not for ET)
waypoint_connect
Usage: waypoint_connect
Example: waypoint_connect
- Flags the nearest waypoint for a connection. If a waypoint is already flagged for connection that waypoint will be connected to this waypoint with a 1-way connection.
waypoint_connectx
Usage: waypoint_connectx
Example: waypoint_connectx
- Same as waypoint_connect, only uses the waypoint you are aiming at.
waypoint_dcall
Usage: waypoint_dcall
Example: waypoint_dcall
- Disconnect all waypoints in the map. This removes all connections, while leaving only the waypoints.
waypoint_del
Usage: waypoint_del
Example: waypoint_del
- Deletes a nearest waypoint that you are standing within 100 units of. All connections from and to the waypoint will get automatically removed as well.
waypoint_deleteaxis
Usage: waypoint_deleteaxis axis[string]
Example: waypoint_deleteaxis
- Deletes all waypoints on a specified side of a specified axis.
- axis - x, y, z, -x, -y, -z, which side of which axis to delete all waypoints from. Mainly useful for symmetrical maps when you wish to delete a side, make adjustments, and re-mirror the waypoints.
waypoint_info
Usage: waypoint_info
Example: waypoint_info
- Prints some basic information about the nearest waypoint.
waypoint_load
Usage: waypoint_load name[string, optional]
Example: waypoint_load
- name is optional and if used, loads the waypoints for the currently loaded map with the suffix name. For example, if the map d3ctf1 is loaded, waypoint_load half would load from the nav directory the file d3ctf1half.way
- Loads the waypoints for the currently loaded map. Waypoints are loaded from the nav directory under the mod currently running. Warning: Any changes you may have made to the waypoints since the last load will be lost. This command is typically used for undoing changes made after the last save.
waypoint_lockselected
Usage: waypoint_lockselected
Example: waypoint_lockselected
- Locks all currently selected waypoints. Locked waypoints aren't effected by waypoint_translate.
waypoint_mirror
Usage: waypoint_mirror axis[string] p[optional]
- axis can be defined as x, y, or z
- p is optional, and if defined will use your current position to define an axis
Example: waypoint_mirror x
- This command mirrors all current waypoints and rotates the mirrored waypoints across the origin of a provided axis. This function is useful for mirroring the waypoints in a symmetrical map, where each team has an identical base. The optional p parameter is useful for when the map isn't centered around the 0 axis. Stand as closely to the center of the map as possible and execute the command including the optional p parameter and the waypoints will be mirrored and offset based on the player position.
waypoint_move
Usage: waypoint_move
Example: waypoint_move
- Grabs the nearest waypoint for moving. If a waypoint has already been grabbed by a previous call to waypoint_move, it is dropped at your current position. Connections are maintained throughout waypoint moving.
waypoint_save
Usage: waypoint_save
Example: waypoint_save
- name is optional and if used, saves the waypoints for the currently loaded map with the suffix name. For example, if the map d3ctf1 is loaded, waypoint_save half would save the waypoints to the nav directory as the file d3ctf1half.way
- Saves the waypoints for the currently loaded map. Waypoints are saved to a file called mapname.way in the nav directory under the mod currently running. Warning: This will overwrite an existing waypoint file of the same name without asking. Rename or backup your original waypoint files when you want to experiment.
waypoint_select
Usage: waypoint_select radius[#]
Example: waypoint_select 500
- Selects all waypoints in the provided radius. If no radius is provided, the selection is cleared. Some of the above functions work on selected waypoints.
waypoint_setdefaultradius
Usage: waypoint_setdefaultradius radius[#]
Example: waypoint_setdefaultradius 100
- Sets the default radius that is used with all waypoints placed. Useful if you plan to waypoint_add a bunch of waypoints that will share a radius different from the current default to save time going back and changing radius manually.
waypoint_setfacing
Usage: waypoint_setfacing
Example: waypoint_setfacing
- Sets the facing for the nearest waypoint to your current facing. A waypoint's facing is basically a vector associated with a waypoint that tells the bot in which direction to look when the bot is camping on that waypoint (due to a sniper or defend flag in most cases). Waypoint facing can also be used for various purposes in scripts.
waypoint_setname
Usage: waypoint_setname name[string]
Example: waypoint_setname spawnarea
- Sets the name of the nearest waypoint. Waypoint names are used as part of the map goal name for any goals that are created as a result of the flags on a waypoint. For example, if you set a waypoint's name to "barrier_axis1" and the waypoint has a sniper flag set, it will appear as MAP_SNIPER_SPOT_barrier_axis1 in the bots' goal list. It's much easier and less error-prone to manipulate goals in a mapscript based on meaningful names rather than UIDs.
waypoint_setproperty
Usage: waypoint_setproperty name[string] value[string]
Example: waypoint_setproperty bias 0.6
- Sets an arbitrary propery value by name. This is the current method of allowing a waypointer to set the bias of a goal by setting a bias as a property on goals that are then used to create maps goals.
waypoint_setradius
Usage: waypoint_setradius radius[#]
Example: waypoint_setradius 100
- Sets the radius of the nearest waypoint.
waypoint_shownames
Usage: waypoint_shownames expression[string, optional]
Example: waypoint_shownames ATTACK.*
- Prints all waypoint id's and names that optionally match an expression.
waypoint_stats
Usage: waypoint_stats
Example: waypoint_stats
- Prints out some basic information for the waypoint pathing system. Primarily a debug tool, but useful if you want to see the total number of waypoints currently placed.
waypoint_translate
Usage: waypoint_translate x[#] y[#] z[#]
Example: waypoint_translate 10 0 0
- Translates(moves) all waypoints, or the currently selected waypoints by Vector3(x,y,z)
waypoint_unlockall
Usage: waypoint_unlockall
Example: waypoint_unlockall
- Unlocks all waypoints.
waypoint_view
Usage: waypoint_view enable[1,0,true,false,on,off]
Example: waypoint_view 1
- Enables or disables waypoint rendering.
waypoint_viewfacing
Usage: waypoint_viewfacing enable[1,0,true,false,on,off]
Example: waypoint_viewfacing 1
- Enables or disables rendering of the facing vector for waypoints if they have a facing vector.
Waypoint Flag List
allies (ET specific)
- An ET alias for the team2 flag. Often used with team doors, or at spawn points.
ammo
- Flag this waypoint as having ammo nearby.
armor
- Flag this waypoint as having armor nearby.
arty_spot (ET specific)
- A location for the bot to go to to look for arty_target_s or arty_target_d points
arty_target_d (ET specific)
- Dynamic artillery strike target. An artillery using bot will watch this position and attempt to call artillery strikes ahead of an enemy that approaches this target location.
arty_target_s (ET specific)
- Static artillery strike target. An artillery using bot will call an artillery on this position, whether there is anything there or not.
attack
- A location a bot will go to and attack. Currently implemented as a simple goto location. No camping or anything else. To be improved in the future.
axis (ET specific)
- An ET alias for the team1 flag. Often used with team doors, or at spawn points.
blockable
- Flags the path between two waypoints as blockable.
Note: This flag has to be used in conjunction with additional flags to determine the type of checking that will be done for the blockable path! See above.
bridge (ET specific)
- Flags a path between two waypoints that leads over a destructible bridge or ramp. Use with 'blockable' flag.
cappoint
- A capture point for stolen items like documents, radar parts or whatever map makers come up with. This is where the bot carrying the stolen item should head to. Example: the boat in Venice.
climb
- Flag this waypoint as climb, for ladders or other climbable objects.
closed
- Flag this waypoint as closed, and therefor un-usable in path searches.
This flag is best added and removed from a script. Syntax example:
Wp.SetWaypointFlag("waypoint_name1","closed",false);
Wp.SetWaypointFlag("waypoint_name2","closed",true);
note: It is recommended that when using this function that you set the "default" flag in OnMapLoad. Meaning that you will want to set it to whatever it should be at map start:
global Map =
{
sometrigger = function( trigger )
{
// open up the node now that this event has triggered
Wp.SetWaypointFlag("waypoint_name1","closed",false);
}
};
global OnMapLoad = function()
{
// at the beginning of the round, make sure this waypoint is closed
Wp.SetWaypointFlag("waypoint_name1","closed",true);
};
crouch
- Flag this waypoint as crouch, causing bots to crouch when they are within its radius.
defend
- A location a bot will go to and defend. Currently implemented as a simple camp spot. To be improved in the future. Tip: If you add this flag don't forget to do the waypoint_setfacing command for this waypoint. Otherwise bots might stare into walls or don't even look at objects to defend while camping.
detpack (ETF specific)
- Flag this waypoint as a location for a Grenadier to lay a detpack.
door
- Flag this waypoint as door, causing bots to be aware of special case door behaviors.
elevator
- Flag this waypoint as elevator, causing the bot to use special elevator logic.
goto
- Flag this waypoint as a GoTo point. This causes a GoTo goal to be created. It is scriptable like other goals, and is simply a goal that will cause the bots to move to the location.
health
- Flag this waypoint as having health nearby.
inwater
- Flag this waypoint as being in water. This should eventually be auto-detected on placement. Will eventually be used for smarter swimming logic.
jump
- Flag this waypoint as jump, causing the bot to jump.
jumpgap
- Flag this waypoint as jumpgap, causing the bot to check the ground ahead and jump near before gaps in the ground.
jumplow
- Flag this waypoint as jumplow, causing the bot to check a short distance in front of the bot and jump over low obstacles such as small walls, crates, boxes...
mg42 (ET specific)
- Flags this waypoint as an MG42 camping spot for soldier bots with mg42s. Not yet used in 0.66.
mine
- Flags this waypoint as a spot to lay mines. Normally the bots will plant only one mine per mine spot.
mortar
- (under wiki construction)
mortar_target_d
- (under wiki construction)
mortar_target_s
- (under wiki construction)
movable
- Flag this waypoint as being movable. Not yet implemented, but in the future this will be used to implement waypoints that move along with the objects they are placed on, such as trains, platforms, etc...
pipetrap (ETF specific)
- Flag this waypoint as a location for a Grenadier to lay a pipe trap FROM.
pipetrap2 (ETF specific)
- Flag this waypoint as a location for a Grenadier to shoot his pipe trap TOWARDS.
prone
- Flag this waypoint as prone, causing the bot to go prone and crawl along the path. Prone is also used in some circumstances as a stance to be in, such as with sniper points and such.
script
- (under wiki construction)
sentry (ETF secific)
- Flag this waypoint as a location for an Engineer to build a sentry.
sneak
- Flag this waypoint as sneak, causing the bot to walk or sneak while in its radius.
snipe
- Flag this waypoint as a snipe point, causing sniper bots to use it as a snipe point. Requires a valid facing for the waypoint. Often used in conjunction with the prone or crouch flags, and/or team flags. Read more about this flag on the sniper spots page.
sprint
- Flag this waypoint as sprint, causing the bot sprinting along the path.
supplystation (ETF specific)
- Flag this waypoint as a location for an Engineer to build a supplystation.
team1
- Flag this waypoint as usable for team1 only.
team2
- Flag this waypoint as usable for team2 only.
team3 (Not ET related)
- Flag this waypoint as usable for team3 only.
team4 (Not ET related)
- Flag this waypoint as usable for team4 only.
teamonly
- Internal flag. Don't use this directly. Automatically set and un-set based on using other team flags.
teleport
- Flag this waypoint as a teleport. The paths between 2 teleport waypoints is considered 0 length since navigation is considered instant.
underwater
- Flag this waypoint as being under water. This should eventually be auto-detected on placement. Will eventually be used for smarter swimming logic.
wall (ET specific)
- Flags a path between two waypoints that is blocked by a wall or similar obstacle. Use with 'blockable' flag.
waterblockable
- Flags the path between two waypoints as blockable by water. Example: the caves in Oasis.
Community Waypoint Guidelines
Note that this information may be partially outdated by the new waypoint database!
Until there is the waypoint database running it would be nice if waypoint file / map script contributions could follow a few guidelines to make it easier for everybody to find the appropiate waypoint version.
1.) When submitting waypoint files please put them in a zip together with any additional information you want to include, e.g. readme.txt or whatever.
2.) While waypoint packs may have their uses I think it is generally better to submit single waypoints, cause in this way users will more easily find them without having to look at all the details of the package to find out if the needed waypoint file is in there. If you want to submit a package, please at least include the map list in the download description.
3.) When uploading please name the download following this pattern: MAPNAME-BOTVERSION-WAYPOINTREVISION Example: oasis-0.51-1.0
4.) Please try to limit the number of contained subfolders.
5.) When contributing map scripts it is important that the waypoint file matches the map script or they may not work as intended. Therefore please either include them directly in the zip together with the matching waypoint file or if you want to submit them independently please reference the waypoint file needed in the download description.
6.) Don't upload vis files. They will be automatically generated on map start and should not be submitted together with the waypoint files.
A couple of concluding notes: We hope to get a real waypoint database going in the future that will ease up things a lot but I can give no date to when that'll be the case. If someone is interested we could use an "Official Waypoint Tester".
Hope those notes don't sound offensive. We're very thankful for all the user contributions we get and without you this whole project certainly wouldn't be as successful as it is.