|Author:||= Mr. Elusive|
The command line should be formatted as follows:
Example 1: bspc -bsp2aas d:\quake3\baseq3\maps\mymap?.bsp
Example 2: bspc -bsp2aas d:\quake3\baseq3\pak0.pk3\maps/q3dm*.bsp
In the first example a "?" is used as a metacharacter variable to indicate any single keyboard character. This allows you to compile the latest version of a map ("mymap1" or "mymapb").
In the second example a "*" is used as a metacharacter variable to indicate any string of keyboard characters. This allows you to compile the latest version of a map ("mymap1" or "mymapb").
The bot navigation compile process can be further modified by the use of "switches" that change some of the parmeters used in compilation. Some of these can be used to compile only certain features, such as reachability. Others allow the compiler to use more than a single processor, as is the case with "threads."
|bsp2aas <[pakfilter/]filter.bsp>||= convert BSP to AAS|
|reach <filter.bsp>||= compute reachability & clusters|
|cluster <filter.aas>||= compute clusters|
|aasopt <filter.aas>||= optimize aas file|
|output <output path>||= set output path|
|threads <X>||= set number of threads to X|
|cfg <filename>||= use this cfg file|
|optimize||= enable optimization|
|noverbose||= disable verbose output|
|breathfirst||= breath first bsp building|
|nobrushmerge||= don't merge brushes|
|freetree||= free the bsp tree|
|nocsg||= disables brush chopping|
|forcesidesvisible||= force all sides to be visible|
|grapplereach||= calculate grapple reachabilities|
Several metacharacters may be used in the filter and pakfilter.
|*||Match any string of zero or more characters|
|?||Match any single character|
|[abc...]||Match any of the enclosed characters; a hyphen can be used to specify a range (e.g. a-z, A-Z, 0-9)|
.pk3 files are accessed as if they are normal folders (whether they are compressed or not).
For instance, use "d:\quake3\baseq3\pak0.pk3\maps/q3dm1.bsp" to access the map q3dm1.bsp from the pak0.pk3 file.
Multiple files may be listed after the switches bsp2map, bsp2aas, reach, cluster and aasopt.
If a BSP file is being converted to an AAS file and no output path is entered on the command line then the AAS file will automatically be stored in the same folder as the BSP file. However if the BSP file was stored in a .pk3 file then the AAS file will be stored in a folder with the name 'maps' outside the .pk3 file.
Where mymap.bsp is the BSP file. The mymap.aas file has to be in the same folder as mymap.bsp or should be in the output folder specified with the -output option.
Keep in mind that as soon as ANY geometry in the map changes (including b_models and trigger brushes) the whole AAS file HAS to be recalculated in order to play with bots.
Make sure the .lin file is stored in the same folder as where q3radiant stores the .bsp file. Load the map in q3radiant and use the menu > File > Pointfile... to load the .lin file. A thick red line will be shown in the map. Follow this line to find the leak.
For scale purposes, "normal" steps should be no higher than 8 units. However, the maximum value that a player may step up is 18 units (just keep steps 16 units or lower).
The maximum height for barriers the bots will jump on is 32 units.
Water Jump Heights (or "Everyone, out of the pool!")
The maximum distance that a bot may jump to exit water is 18 units. This is the height difference between the water surface and the adjacent floor that the bot is jumping onto. If the water jump height is made higher, human players will have a hard time getting out of the water.
With normal gravity and without the quad, the maximum rocket jump height is around 280 units (you can sometimes jump a few units higher but this is a safe value for reference). In practice, except for especially tricky jumps, this value should be substantially lower. Test rocket jumps repeatedly before settling on a final height.
Math for Map Makers
Here's some math to calculate some other values of interest:
Gravity = 800;
Jump velocity = 270;
Max vertical rocketjump velocity = 670;
Max run velocity = 320;
Max step height = 18;
Max jump height = 0.5 * gravity * (jumpvelocity/gravity)*(jumpvelocity/gravity);
Max normal jump height = 45 units
NOTE: even though this is the mathematical maximum jump height always keep the the 32 units maximum barrier height for bots in mind when building maps.
Maximum horizontal jump distance over a gap from one spot to another when both are at the same height:
Because players use a bounding box we can jump a full bounding box width further in the ideal case. (15 units at the jump starting position and 15 at the landing place).
Again, remember that this is the mathematical maximum which players can only reach under ideal circumstances.
First, understand that hint brushes, which are of great use to the bsp compiler, have no effect on the bspc tool that creates area files. Only solid, clip and liquid brushes and curve patches are used by the bspc tool. Using these mapcomponents, the bspc tool outputs how many "areas" will be created for a map. Having fewer areas in a map is better than having more.
Quite often, map trim and detail create many of these small areas. For the most part, these small areas are too small to enter and are thus useless to the bots. Brushes that project out into the map's floor cut it up and create additional areas. Often the number of areas can be greatly reduced by adding additional clip brushes. Take a look at Q3DM7 in the map editor, and you will see the walls are literally covered with clip brushes. This not only smooths out passage for human players, but also has the added benefit of eliminating unnecesary navigation areas. This is also why, as many "camping style" players have found, many areas above door and window trim have also been clipped off.
Another way to reduce complexity is to use clip brushes to simplify the collision area around complex objects. For exmple, the map maker can add clip brushes with simple shapes (axial or "square" brushes are prefered) around (small) detail brushes. Simple shaped clip brushes can also be added around curves to reduce the collision complexity (for instance, place an axial clip brush around a small cylinder). It is better to place the clip brushes around the whole curve (not just part of the curve). The map maker should also use shader scripts to make the textures on brushes or curve patches non-solid (surfaceparm nonsolid) when they are enclosed by (full) clip brushes. This will also speed up bspc calculations.
Always try to align your geometry to the grids. Always use the largest grid possible for alignment of your geometry. Also try to align the backsides of brushes which may not be visible. The more brush sides are aligned the better. This will also speed up bspc calculations.
Align adjacent brushes as much as possible. Make sure that badly aligned brushes create no tiny faces.
Quite often there are also places in a map that are visible to players but where players can never go (even determined, rocket-jumping players). If a player could reach that area, they would be able to walk around upon it. If the mapmaker decides not to allow that, he or she should use large clip brushes to enclose the entire unreachable space. This will also speed up bspc calculations and reduce the number of areas created by the bspc tool.
Note: the number of areas relative to the map size tells something about the navigation complexity for players in general (also human players). Reducing the collision complexity for bots also makes the map easier to navigate for human players
Guidelines to Consider When Placing Cluster Portals:
When bot navigation problems show up or you want to make sure a bot never tries to go to a certain place use a "do not enter" brush.
Guidelines to consider when placing "Do Not Enter" brushes:
The item_botroam entity can be used when a bot does not roam the whole level or prefers to go to only specific areas. This (invisible) item can be placed in a map just like regular items. Nobody can actually pick up the item. It's only used to attract bots to certain places of the map.
The item_botroam has a key "origin" that is set by Q3Radiant automatically.
The item_botroam also has a key "weight." The value is the weight of the roam item and is relative to the weight of other items in the map, which are individual to each bot. The bot character-specific item weights are stored with the bot characters in the botfiles/bots/ sub-folder in the .pk3 file. The value of the weight is a non-zero floating-point value, most often in the range 0 to 400. Higher values are allowed but keep in mind that the bot should also still go for normal items, so don't make the item_botroam weight too high.
"Notbot" Means "Don't Touch"
When a bot should never go for a specific item, the key "notbot" with a value of "1" can be used for that item. This notbot key and its value can be used for every available item in Quake III Arena.
This entity suggests locations where the bot can wait for enemies to come into view.
The suspended checkbox flag can be used on all items (item_botroam included). However keep in mind that when a suspended item is not anywhere near the ground the bot will ONLY try to go for this suspended item using jump pads.
In most cases, solid areas are the result of careless design. But, if you insist on making maps that are not axial in layout (say, your average cave), they can result from brushes meeting at non-axial angles. These "map bugs" can sometimes cause certain places in the map to show up solid in the AAS file. To test for these solid places set the cvar bot_testsolid to "1" on the console. (type /set bot_testsolid 1)
As you walk through the map, either "empty area" or "SOLID area" will be printed on the screen while traveling through a map.
The Culprits: What May Cause Map Bugs
Several map bugs can cause these solid places in the AAS file.
Hacking Away the Problem
If you insist creating an .AAS file for a map with bugs, then the BSPC compile option -forcesidesvisible can be used. This should fix all the problems with areas showing up solid in the .AAS file. However creating an .AAS file with this option takes a lot longer (often more than twice the normal compile time). This is not recommended as a default option for compiling.
Testing Jump and Launch Pads
Jumppads can also be tested. Type the following on the Quake III Arena console, before loading your map:
/set bot_maxdebugpolys 1024
/set bot_visualizejumppads 1
/set bot_forcereachability 1
Now load the map. A counter will be shown and goes from 0% to 100%. When the counter has reached 100% type /set r_debugSurface 2 on the console. For every jumppad the default arc of travel (without using air control) will be visualized.
- fixed ducked bounding box size
- fixed sv_maxsteepness being zero in aas configuration
- AAS files are now automatically stored in BSP file folder
- fixed crash bug caused by overflow of a simulated stack
Back | Home | Next