3 <title>Q3Radiant Editor Manual: Appendix C</title>
\r
4 <link rel = "stylesheet" type = "text/css" href = "../styles/q3rad.css">
\r
7 <h1 class = "MsoTitle">Q3Radiant Editor Manual</h1>
\r
9 <h1>Appendix C: Bot Navigation Files</h1>
\r
11 (Original Document Title: BSP Converter)
\r
15 <td width = 60%>= 1.8</td>
\r
19 <td width = 60%>= 2000-01-11</td>
\r
23 <td width = 60%>= Mr. Elusive</td>
\r
27 <h2><a name = "intro">Introduction</a></h2>
\r
29 This appendix is based on documentation that has been released
\r
30 and updated by Mr. Elusive. It deals with the Navigation file that
\r
31 must be created in order for the <i>Quake III Arena</i> bots to be
\r
32 able to navigate and play in game maps. It is not a manual for the
\r
35 <h2><a name = "desc">Description</a></h2>
\r
37 The BSPC tool is used to create AAS files from BSP files. An AAS
\r
38 file is a file with areas used by the Quake III Arena bot in order
\r
39 to navigate and understand a map.
\r
41 <h2><a name = "install">Installation</a></h2>
\r
43 Place the BSPC program in your Quake III Arena folder.
\r
45 <h2><a name = "usage">Usage</a></h2>
\r
47 Unless you are using a front-end utility, which gives you
\r
48 check-button access to compiler functions, you will need to run
\r
49 this program from the command line of your DOS Command Prompt
\r
50 program. If the command line is not already pointing the <i>Quake
\r
51 III Arena</i> directory, change directories (cd\quake III
\r
54 <p>The command line should be formatted as follows:
\r
56 <ul class = "type">bspc [-<switch> [-<switch> ...]]</ul>
\r
58 <p><strong>Example 1:</strong> <span class = "type">bspc -bsp2aas d:\quake3\baseq3\maps\mymap?.bsp</span>
\r
60 <br><strong>Example 2:</strong> <span class = "type">bspc -bsp2aas
\r
61 d:\quake3\baseq3\pak0.pk3\maps/q3dm*.bsp</span>
\r
63 <p>In the first example a "?" is used as a metacharacter variable
\r
64 to indicate any single keyboard character. This allows you to
\r
65 compile the latest version of a map ("mymap1" or "mymapb").
\r
67 <p>In the second example a "*" is used as a metacharacter variable
\r
68 to indicate any string of keyboard characters. This allows you to
\r
69 compile the latest version of a map ("mymap1" or "mymapb").
\r
71 <p>The bot navigation compile process can be further modified by
\r
72 the use of "switches" that change some of the parmeters used in
\r
73 compilation. Some of these can be used to compile only
\r
74 certain features, such as reachability. Others allow the compiler
\r
75 to use more than a single processor, as is the case with
\r
81 <td>bsp2aas <[pakfilter/]filter.bsp></td>
\r
82 <td width = 60%>= convert BSP to AAS</td>
\r
85 <td>reach <filter.bsp></td>
\r
86 <td width = 60%>= compute reachability & clusters</td>
\r
89 <td>cluster <filter.aas></td>
\r
90 <td width = 60%>= compute clusters</td>
\r
93 <td>aasopt <filter.aas> </td>
\r
94 <td width = 60%>= optimize aas file</td>
\r
97 <td>output <output path> </td>
\r
98 <td width = 60%>= set output path</td>
\r
101 <td>threads <X> </td>
\r
102 <td width = 60%>= set number of threads to X</td>
\r
105 <td>cfg <filename> </td>
\r
106 <td width = 60%>= use this cfg file</td>
\r
110 <td width = 60%>= enable optimization</td>
\r
113 <td>noverbose </td>
\r
114 <td width = 60%>= disable verbose output</td>
\r
117 <td>breathfirst </td>
\r
118 <td width = 60%>= breath first bsp building</td>
\r
121 <td>nobrushmerge </td>
\r
122 <td width = 60%>= don't merge brushes</td>
\r
126 <td width = 60%>= free the bsp tree</td>
\r
130 <td width = 60%>= disables brush chopping</td>
\r
133 <td>forcesidesvisible </td>
\r
134 <td width = 60%>= force all sides to be visible</td>
\r
137 <td>grapplereach </td>
\r
138 <td width = 60%>= calculate grapple reachabilities</td>
\r
142 <p>Several metacharacters may be used in the filter and
\r
148 <td width - 90%>Match any string of zero or more characters</td>
\r
152 <td width = 90%>Match any single character</td>
\r
156 <td>Match any of the enclosed characters; a hyphen can be used to specify a range (e.g. a-z, A-Z, 0-9)</td>
\r
160 <p>.pk3 files are accessed as if they are normal folders (whether
\r
161 they are compressed or not).
\r
163 <p>For instance, use "d:\quake3\baseq3\pak0.pk3\maps/q3dm1.bsp" to
\r
164 access the map q3dm1.bsp from the pak0.pk3 file.
\r
166 <p>Multiple files may be listed after the switches bsp2map,
\r
167 bsp2aas, reach, cluster and aasopt.
\r
169 <p>If a BSP file is being converted to an AAS file and no output
\r
170 path is entered on the command line then the AAS file will
\r
171 automatically be stored in the same folder as the BSP file. However
\r
172 if the BSP file was stored in a .pk3 file then the AAS file will be
\r
173 stored in a folder with the name 'maps' outside the .pk3 file.
\r
175 <h2><a name = "update">Updating the Entity Lump</a></h2>
\r
177 If an AAS file is already available for a BSP file and you ONLY
\r
178 change the entities inside this BSP file then you only have to
\r
179 recalculate the reachabilities. This way you can move items,
\r
180 platforms etc. around without the need to recalculate the whole AAS
\r
181 file -- which can save quite some compile time. You can recalculate
\r
182 the reachabilities as follows:
\r
184 <ul class = "type">bspc -reach mymap.bsp</ul>
\r
186 <p>Where mymap.bsp is the BSP file. The mymap.aas file has to be in
\r
187 the same folder as mymap.bsp or should be in the output folder
\r
188 specified with the -output option.
\r
190 <p>Keep in mind that as soon as ANY geometry in the map changes
\r
191 (including b_models and trigger brushes) the whole AAS file HAS to
\r
192 be recalculated in order to play with bots.
\r
194 <h2><a name="leaks">Leaks</a></h2>
\r
196 Just like there can be vis "leaks" in a map there can also be
\r
197 clipping leaks. Two things can be wrong when the BSPC tool outputs
\r
202 There are no entities in the map at all, or all entities that are
\r
203 actually in the map are placed in solid locations (see Test Solid
\r
204 below). In this case the BSPC tool outputs: "WARNING: no entities
\r
205 inside." The map must contain at least one player start entity to
\r
210 There is a spot in the map where players can go outside the map
\r
211 into the void. This is bad, players should never be able to fall
\r
212 out of a level. In this case the BSPC tool outputs: "WARNING:
\r
213 entity reached from outside." The BSPC tool also writes a mymap.lin
\r
214 file that can be loaded in the Q3Radiant editor to show lines that
\r
215 go through the actual leak.</ol>
\r
217 <p>Make sure the .lin file is stored in the same folder as where
\r
218 q3radiant stores the .bsp file. Load the map in q3radiant and use
\r
219 the menu > File > Pointfile... to load the .lin file.
\r
220 A thick red line will be shown in the map. Follow this line to find
\r
223 <h2><a name="mapinfo">Useful Map Information</a></h2>
\r
225 The following information is given as a reference for bot
\r
226 capabilities. The area file information is used by bots. It tells
\r
227 them when and where they can make jumps. Human players don't have
\r
228 this information readily available to them, so you may want to be
\r
229 more forgiving when designing tricky jumps.
\r
231 <p><div class = "subheading">Map Boundaries</div>
\r
233 Currently all the contained area of a <i>Quake III Arena</i> map
\r
234 should fall within the bounds (8192, 8192, 8192) - (-8192, -8192,
\r
235 -8192) for the bspc tool to compile. These are the same bounds as
\r
236 the Q3Map compilers.
\r
238 <p><div class = "subheading">Game Physics</div>
\r
240 <strong>Player Dimensions</strong>
\r
242 <br><b>Model size:</b> The player model's actual size is a bounding
\r
243 box 30 units by 30 units square with a height of 56 units. In the
\r
244 game world, eight units roughly equal one foot (30.5 cm). From
\r
245 this, we deduce that the characters are a heroic 7 feet tall (2.13
\r
248 <p><strong>Step Heights</strong>
\r
250 <br>For scale purposes, "normal" steps should be no higher than 8
\r
251 units. However, the maximum value that a player may step up is 18
\r
252 units (just keep steps 16 units or lower).
\r
254 <p><strong>Normal Jumps</strong>
\r
256 <br>The maximum height for barriers the bots will jump on is 32
\r
259 <p><strong>Water Jump Heights (or "Everyone, out of the pool!")</strong>
\r
261 <br>The maximum distance that a bot may jump to exit water is 18
\r
262 units. This is the height difference between the water surface and
\r
263 the adjacent floor that the bot is jumping onto. If the water jump
\r
264 height is made higher, human players will have a hard time getting
\r
267 <p><strong>Rocket Jumps</strong>
\r
269 <br>With normal gravity and without the quad, the maximum rocket
\r
270 jump height is around 280 units (you can sometimes jump a few units
\r
271 higher but this is a safe value for reference). In practice, except
\r
272 for especially tricky jumps, this value should be substantially
\r
273 lower. Test rocket jumps repeatedly before settling on a
\r
276 <p><strong>Math for Map Makers</strong>
\r
278 <br>Here's some math to calculate some other values of interest:
\r
280 <p><b>Gravity</b> = 800;
\r
282 <br><b>Jump velocity</b> = 270;
\r
284 <br><b>Max vertical rocketjump velocity</b> = 670;
\r
286 <br><b>Max run velocity</b> = 320;
\r
288 <br><b>Max step height</b> = 18;
\r
290 <br><b>Max jump height</b> = 0.5 * gravity *
\r
291 (jumpvelocity/gravity)*(jumpvelocity/gravity);
\r
293 <br><b>Max normal jump height</b> = 45 units
\r
295 <br><b>NOTE:</b> even
\r
296 though this is the mathematical maximum jump height always keep the
\r
297 the 32 units maximum barrier height for bots in mind when building
\r
300 <br><b>Maximum horizontal jump distance</b> over a gap from one spot
\r
301 to another when both are at the same height:
\r
303 <ul>t = sqrt((maxjumpheight + maxstep) / (0.5 * gravity));
\r
305 <br>t = 0.3986 seconds;
\r
307 <br>dist = maxrunvelocity * (t + jumpvelocity / gravity);
\r
309 <br>dist = 235 units;</ul>
\r
311 <p>Because players use a bounding box we can jump a full bounding
\r
312 box width further in the ideal case. (15 units at the jump starting
\r
313 position and 15 at the landing place).
\r
315 <ul>235 + 15 + 15 = 265 units.</ul>
\r
317 <p>Again, remember that this is the mathematical maximum which
\r
318 players can only reach under ideal circumstances.
\r
320 <h2><a name = "optimise">Optimizing a Map for bspc Compiling</a></h2>
\r
322 The area file is the tool that the bots use to understand the
\r
323 map. If it is overly complex, it can cause navigation problems.
\r
324 With careful attention to detail, many of these problems can be
\r
325 eliminated, or avoided altogether.
\r
327 <p>First, understand that hint brushes, which are of great use to
\r
328 the bsp compiler, have no effect on the bspc tool that creates area
\r
329 files. Only solid, clip and liquid brushes and curve patches are
\r
330 used by the bspc tool. Using these mapcomponents, the bspc tool
\r
331 outputs how many "areas" will be created for a map. Having fewer
\r
332 areas in a map is better than having more.
\r
334 <p>Quite often, map trim and detail create many of these small
\r
335 areas. For the most part, these small areas are too small to enter
\r
336 and are thus useless to the bots. Brushes that project out into the
\r
337 map's floor cut it up and create additional areas. Often the number
\r
338 of areas can be greatly reduced by adding additional clip brushes.
\r
339 Take a look at Q3DM7 in the map editor, and you will see the walls
\r
340 are literally covered with clip brushes. This not only
\r
341 smooths out passage for human players, but also has the added
\r
342 benefit of eliminating unnecesary navigation areas. This is
\r
343 also why, as many "camping style" players have found, many areas
\r
344 above door and window trim have also been clipped off.
\r
346 <p>Another way to reduce complexity is to use clip brushes to
\r
347 simplify the collision area around complex objects. For exmple, the
\r
348 map maker can add clip brushes with simple shapes (axial or
\r
349 "square" brushes are prefered) around (small) detail brushes.
\r
350 Simple shaped clip brushes can also be added around curves to
\r
351 reduce the collision complexity (for instance, place an axial clip
\r
352 brush around a small cylinder). It is better to place the clip
\r
353 brushes around the whole curve (not just part of the curve). The
\r
354 map maker should also use shader scripts to make the textures on
\r
355 brushes or curve patches non-solid (surfaceparm nonsolid) when they
\r
356 are enclosed by (full) clip brushes. This will also speed up bspc
\r
359 <p>Always try to align your geometry to the grids. Always use the
\r
360 largest grid possible for alignment of your geometry. Also try to
\r
361 align the backsides of brushes which may not be visible. The more
\r
362 brush sides are aligned the better. This will also speed up bspc
\r
365 <p>Align adjacent brushes as much as possible. Make sure that badly
\r
366 aligned brushes create no tiny faces.
\r
368 <p>Quite often there are also places in a map that are visible to
\r
369 players but where players can never go (even determined,
\r
370 rocket-jumping players). If a player could reach that area, they
\r
371 would be able to walk around upon it. If the mapmaker decides not
\r
372 to allow that, he or she should use large clip brushes to enclose
\r
373 the entire unreachable space. This will also speed up bspc
\r
374 calculations and reduce the number of areas created by the bspc
\r
377 <p><b>Note:</b> the number of areas relative to the map size tells
\r
378 something about the navigation complexity for players in general
\r
379 (also human players). Reducing the collision complexity for bots
\r
380 also makes the map easier to navigate for human players
\r
382 <h2><a name = "entnav">Entities & the Navigation File</a></h2>
\r
384 There are specific rules and guidelines for using a number of
\r
385 entities and entity-like textures with the bspc tool.
\r
387 <p><div class = "subheading">Func_plat and Func_bobbing</div>
\r
389 When func_plat or func_bobbing entities are placed in a map, the
\r
390 bots will use them if possible. The bots assume they can stand on
\r
391 top of the bounding box (xy extents of all components used to
\r
392 create the entity) of the model used for the func_plat or
\r
393 func_bobbing entity. As a result, creating complex-shaped func_plat
\r
394 or func_bobbing models is mostly a bad idea. You have to make sure
\r
395 the bots (and players) can actually stand everywhere on top of the
\r
396 bounding box of the model. The basic rule: If a bot is going to use
\r
397 a func_plat or a func_bobbing, make sure the top surface is a
\r
398 solid, rectilinear rectangle or square.
\r
400 <p><div class = "subheading">Cluster Portals</div>
\r
402 Cluster portals are one of the several "texture entities" used
\r
403 by the game engine. These are textures, which as used by the game
\r
404 engine, function like entities. The bspc tool divides the map into
\r
405 many, much smaller areas, which are essentially the surfaces a bot
\r
406 can move upon during play. Several of these areas can be grouped
\r
407 together to create a cluster. The clusters are seperated by cluster
\r
408 portals, which are also areas themselves. One of the things the bot
\r
409 uses these clusters for is to create a multi-level routing
\r
410 algorithm. When a map is efficiently divided up into clusters bot
\r
411 calculations (in run time) will be faster.
\r
413 <p><strong>Guidelines to Consider When Placing Cluster Portals:</strong>
\r
415 <ul><li>The BSPC tool creates cluster portals automatically, but placing
\r
416 "clusterportal" brushes can create additional cluster portals.
\r
418 <li>Placing "clusterportal" brushes inside the map manually creates
\r
421 <li>The "clusterportal" brushes should not be used outside the world
\r
424 <li>The cluster portals do not have any effect on map vis.
\r
426 <li>If a door is already sealed with an areaportal brush, a
\r
427 clusterportal is not necessary there. (areaportals are used by the
\r
428 bspc tool as if they were cluster portals).
\r
430 <li>Just like the areaportals, the cluster portals must seal a space
\r
431 off entirely from other areas.
\r
433 <li>The cluster portal areas should seal off a cluster in a way that
\r
434 the only path towards another cluster is through a cluster portal
\r
437 <li>Only create cluster portals where people can walk or swim
\r
440 <li>Don't create cluster portals in gaps in the floor. (people would
\r
443 <li>Cluster portals must separate no more and no less than two (2)
\r
446 <li>Try to create clusters with all the same number of
\r
447 "reachability" areas. For instance if the map has 5,400 areas try
\r
448 to create 10 clusters with 540 areas each, or 12 clusters with 450
\r
449 areas each, etc. The BSPC tool lists the number of reachability
\r
450 areas in each cluster.
\r
452 <li>Avoid creating clusters with only a few (less than 10)
\r
455 <li>When adding "cluster portal" brushes, try to place them in
\r
456 places with minimal geometric complexity. For instance place them
\r
457 inside convex door openings or small hallways (not in front of door
\r
458 openings). Ideally, the shape of the face through which a player
\r
459 walks or swims into the cluster portal is the same as the shape of
\r
460 the face through which a player leaves the cluster portal. Also
\r
461 ideally, the open space inside the cluster portal brush is
\r
464 <li>Make cluster portals about 16 or 32 units thick.</ul>
\r
466 <p><div class = "subheading">"Do Not Enter" Areas</div>
\r
467 The Do Not Enter texture is another one of the "texture
\r
468 entities" that the game engine uses as if they were entities. In
\r
469 some regards, it is like a clip brush, intended to prevent a bot
\r
470 from moving into or through it. However, this works more as a
\r
471 "strong suggestion" and is, in reality, not a physical barrier to
\r
472 the bot. A simple example of how a bot may enter a "Do Not Enter"
\r
473 area is knockback. If an explosion tosses a bot about, it may end
\r
474 up inside a prohibited area. Bots may pass out of such areas, but
\r
475 they will not actively try to enter them.
\r
477 <p>When bot navigation problems show up or you want to make sure a
\r
478 bot never tries to go to a certain place use a "do not enter"
\r
481 <p><strong>Guidelines to consider when placing "Do Not Enter"
\r
484 <ul><li>The "do not enter" brushes should not be used outside the world
\r
487 <li>The "do not enter" brush is Not a clip brush for the bot.
\r
489 <li>The "do not enter" brush is a tool of last resort. Do not use it
\r
490 unless there are serious navigation problems.
\r
492 <li>The number of "do not enter" brushes should be minimized because
\r
493 these brushes create additional areas for the bots.
\r
495 <li>The "do not enter" brush will create a new area that the bot
\r
496 will try to avoid. However if the bot somehow ends up inside a "do
\r
497 not enter" area or there is a valid goal (game entity or
\r
498 item_botroam entity) inside the "do not enter" area then the bot is
\r
499 allowed to go into and out of that area. So if the bot somehow gets
\r
500 in a "do not enter" area the bot will be able to get out.</ul>
\r
502 <p><div class = "subheading">Bot Control Entities</div>
\r
504 These entities encourage a bot to move about and use more parts
\r
507 <p><strong>Item_botroam</strong>
\r
508 <br>The item_botroam entity can be used when a bot does not roam the
\r
509 whole level or prefers to go to only specific areas. This
\r
510 (invisible) item can be placed in a map just like regular items.
\r
511 Nobody can actually pick up the item. It's only used to attract
\r
512 bots to certain places of the map.
\r
514 <p>The item_botroam has a key "origin" that is set by Q3Radiant
\r
517 <p>The item_botroam also has a key "weight." The value is the
\r
518 weight of the roam item and is relative to the weight of other
\r
519 items in the map, which are individual to each bot. The bot
\r
520 character-specific item weights are stored with the bot characters
\r
521 in the botfiles/bots/ sub-folder in the .pk3 file. The value of the
\r
522 weight is a non-zero floating-point value, most often in the range
\r
523 0 to 400. Higher values are allowed but keep in mind that the bot
\r
524 should also still go for normal items, so don't make the
\r
525 item_botroam weight too high.
\r
527 <p><strong>"Notbot" Means "Don't Touch"</strong>
\r
529 <br>When a bot should <i>never</i> go for a specific item, the key
\r
530 "notbot" with a value of "1" can be used for that item. This
\r
531 notbot key and its value can be used for every available item in
\r
532 <i>Quake III Arena.<o:p><i></i></o:p></i>
\r
534 <p><strong>Info_Camp</strong>
\r
536 <br>This entity suggests locations where the bot can wait for
\r
537 enemies to come into view.
\r
540 <p><strong>Suspended</strong>
\r
542 <br>The suspended checkbox flag can be used on all items
\r
543 (item_botroam included). However keep in mind that when a suspended
\r
544 item is not anywhere near the ground the bot will ONLY try to go
\r
545 for this suspended item using jump pads.
\r
547 <h2><a name = "testaas">Testing .AAS files</a></h2>
\r
549 <div class = "subheading">Solid Areas</div>
\r
551 A solid area in the map is an area that looks empty to the human
\r
552 player, but is solid, like a wall, to a bot player. One of the
\r
553 easiest ways to test the AAS file for solid areas is to load the
\r
554 map in <i>Quake III Arena</i> in teamplay mode (type /set
\r
555 g_gametype 3 on the console before loading the map). Enter a team
\r
556 and add a bot to your team. Use the team order menu (by default
\r
557 bound to the F3 key) to command the bot to follow you. Walk around
\r
558 the map and see if the bot is able to follow you everywhere. If a
\r
559 bot stops at any point, it may have encountered an area of the map
\r
560 that appears to be unblocked to you, but to the bot, it is like it
\r
561 has encountered a solid wall.
\r
563 <p><strong>Test Solid</strong>
\r
565 <br>In most cases, solid areas are the result of careless design.
\r
566 But, if you insist on making maps that are not axial in layout
\r
567 (say, your average cave), they can result from brushes meeting at
\r
568 non-axial angles. These "map bugs" can sometimes cause certain
\r
569 places in the map to show up solid in the AAS file. To test for
\r
570 these solid places set the cvar bot_testsolid to "1" on the
\r
571 console. (type /set bot_testsolid 1)
\r
573 <p>As you walk through the map, either "empty area" or "SOLID area"
\r
574 will be printed on the screen while traveling through a map.
\r
576 <p><strong>The Culprits: What May Cause Map Bugs</strong>
\r
578 <br>Several map bugs can cause these solid places in the AAS
\r
581 <ul><li>Sometimes microscopic brushes are created by CSG subtraction on
\r
582 one or more brushes. Search for such brushes in the problem area
\r
585 <li>Tiny brush faces (not curves) can also cause problems. Due to
\r
586 vertex snapping in the q3map tool, those tiny brush faces can be
\r
587 snapped out of existence. Such faces will not show up in <i>Quake
\r
588 III Arena</i> and you'll see tiny peek holes or slits where you can
\r
589 view through the geometry (often into other rooms). Align vertexes
\r
590 of adjacent brushes to remove and avoid such tiny faces. Placing a
\r
591 clip brush in front of the face that is snapped out of existence
\r
592 will also remove the "solid area" but of course it's preferred to
\r
593 remove the peek hole or slit. Another cause could be a brush with a
\r
594 collapsed side. Check how many sides a brush has and how many sides
\r
595 actually have a surface. Rebuild brushes with collapsed sides.
\r
597 <li>Lava creates a solid area. All faces contained within liquid
\r
598 brushes using a shader without "surfaceparm trans" set will be
\r
599 removed (this includes some lava textures). Those contained
\r
600 surfaces will not be visible and can cause the liquid to appear
\r
601 "solid" in the aas file.</ul>
\r
603 <p><strong>Hacking Away the Problem</strong>
\r
605 <br>If you insist creating an .AAS file for a map with bugs, then
\r
606 the BSPC compile option <b>-forcesidesvisible</b> can be used. This
\r
607 should fix all the problems with areas showing up solid in the .AAS
\r
608 file. However creating an .AAS file with this option takes a lot
\r
609 longer (often more than twice the normal compile time). This is not
\r
610 recommended as a default option for compiling.
\r
612 <p><strong>Testing Jump and Launch Pads</strong>
\r
614 <br>Jumppads can also be tested. Type the following on the <i>Quake
\r
615 III Arena</i> console, before loading your map:
\r
617 <p>/set bot_maxdebugpolys 1024
\r
619 <br>/set bot_visualizejumppads 1
\r
621 <br>/set bot_forcereachability 1
\r
623 <p>Now load the map. A counter will be shown and goes from 0% to
\r
624 100%. When the counter has reached 100% type /set r_debugSurface 2
\r
625 on the console. For every jumppad the default arc of travel
\r
626 (without using air control) will be visualized.
\r
628 <h2><a name = "version">Version Changes</a></h2>
\r
630 <strong>1.8 (2000-01-08)</strong>
\r
632 <br>- increased max points on winding
\r
634 <br>- made "HashVec: point x y z outside valid range" non-fatal
\r
636 <br>- fixed rocket jump reachabilities
\r
638 <br>- added force sides visible option
\r
640 <br>- increased simulated stack size for area traces
\r
642 <p><strong>1.7 (1999-12-22)</strong>
\r
644 <br>- fixed ducked bounding box size
\r
646 <br>- fixed sv_maxsteepness being zero in aas configuration
\r
648 <br>- AAS files are now automatically stored in BSP file folder
\r
650 <br>- fixed crash bug caused by overflow of a simulated stack
\r
652 <p align = "center"><a href = "appn_b_9.htm">Back</a> | <a href = "../index.htm">Home</a> | <a href = "appn_d.htm">Next</a>
\r
projects / xonotic / netradiant.git / blob