- = WFA BOTS =-
Optimizing your map for AAS
The aas anyone can make off of the bsp; what you need are some information on how things are handled by the process. I am writing documents on it right now, and making changes as they happen. If you are wondering what is in the works or what has happened, icq or email me. If you try the current bots without the latest Bot files, you will not see the true affect of them.
Never before has this item been so widely necessary. The bots understand it, and will make relations to it. Say for instance, where do you want defense to stay and wait for enemies, or where to look. I am working on now actually having them give alerts based on the target location. Just like humans, but never erring.
Cluster Portal Texture:
The Clusterportal is nothing more then a semi-transparent texture used in mapping. It does not affect the vis process per se, it effects how the bots see entitles in the map.
Take 2fort7 for example, the most widely played map in WF ever. Picture the map. You are a mapper. You are also a Bot who sees nothing but little lights that glow different colors depending on what they are, and different brightness depending on how much they make you feel good, and every wall is nothing but a neutral gray texture.
You must break down the map down into 'clusters'. Clusters are logical divisions within the world. Without these clusters a Bot will 'vis' another Bot across the whole map (in theory, but the bspc tool now breaks down some areas automatically, if you are really careless. Read on.) So a red Bot in the red flag room will always be thinking about the blue Bot in the blue flag room. So if there are 20 bots, well, each Bot is thinking about the 19 other ones; so you get lag as the quake3 engine works itís balls of trying to re-define cases and switches on them for each item and action, distance and weights, and their interrelationships.
How would you alleviate this problem? Simple, really. What needs to be done is the map needs 'clusterportals'. Now take the same map, 2fort7
You would logically break the map down into clusters wherever it was most convenient, and most effective. These clusterportals are treated the same as areaportals for the Bot in a twisted sort of way, but do not affect vis in any way. Also keep in mind that an areaportal and a clusterportal are the same to a Bot.
On 2fort7 there would be a clusterportal at the top of the ramp, right at the doorway that leads to the top area. Also at the hole in the floor right by the ramp. At the bottom of the ramp by the flag room entrance, at the elevator top, at the doorways into the fort, at the water entrance and exit, at the elevator entrance, at the top of the elevator entrance, at the entrances to the top of the fort at the balconies, at the junction of the entrance (where there is a jump pad now, used to be crates) to the courtyard, anywhere where you would put a door to block vis if you wanted to
Now these clusterportals must be about 16-32 units wide and sunk in a bit into the walls/floors, small, just like areaportals. But you need to make sure you don't have 'clip' leaks. Now how far you go to determine efficiency is up to you, but this is what I did for reactor-wfa. I copied the whole map minus entities (just turn the view off before selection) and I started sealing up areas with caulk where the clusterportals were, and putting entities on both sides, but not in the cluster, and then punched a hole through it. If it leaked, that area wasn't sealed. This procedure will take a while, but not that long once you get into a pattern of destroying your map bit by bit and hitting undo allot. All you are doing is checking for leaks. Then I took all those caulked walls and made them clusterportals by selecting all of them then selecting the clusterportal texture, then copied and pasted them into the original map.
Its' only a texture.
Think of it as opaque curtains, and entities as glowing light bulbs. If there is something that is beyond that curtain, it will just glow dimly (except the flags, that's done during aas compile). The more clusters, the more dim the objects get as they get farther from each other, so eventually the Bot doesn't even care or take it into consideration when weighing particular situations.
Now keep in mind also that the bots are affected by sound and light, just like regular people. Stick a Bot in a pitch-black room and he has trouble and will usually just stand there and look around, until you fire a weapon or go up a platform. This is why I think that ID changed the code for sound.
Some notes from the manual that I think are the most important besides the above:
The cluster portal areas should seal off a cluster in a way that the only path towards another cluster is through a cluster portal area.
Cluster portals must separate no more and no less than two (2) clusters.
Avoid creating clusters with only a few (less than 10) areas.
The bot_roam is for attracting a Bot to a certain area of a map. This entity acts like a great big magnet, or a nice pretty light that the Bot seems attracted to like a moth to a bug zapper. Each Bot is affected by its tendency to roam, which is selected individually and not controlled by the mapper. Generally itís used to keep bots from taking the same path over and over again, or to add pull to a Bot when he seems to be taking the wrong route. A marine wonít roam (single-minded jar-head) but the arsonist and the nurse will wander. Some classes will roam when you tell them, until an action changes their goals (flag taken, flag captured, they get hit and are weighed heavily as a vengeful class, another Bot calls them for help); then they fall back on their natural tendencies.
The info_camp is the same thing as the Bot roam, but more targeted. If a Bot is a camping class, it will simply wander around (depending on itís configuration) until it finds this item. Due to the nature of CTF, this must be weighed rather heavily for it to be effective for say, a sniper who likes to camp.
Entity Key bot_notteam
This entity key works similar to the
wf_team, but will have the same affect if the goal is on the other side, say an
ammo room, and none of the ammo is marked with this key. So, this may still
attract opposite bots if they visualize a goal on the other side. See below.
Do_Not_Enter (ripped from the manual)
The Do Not Enter texture is another one of the "texture entities" that the game engine uses as if they were entities. In some regards, it is like a clip brush, intended to prevent a Bot from moving into or through it. However, this works more as a "strong suggestion" and is, in reality, not a physical barrier to the Bot. A simple example of how a Bot may enter a "Do Not Enter" area is knockback. If an explosion tosses a Bot about, it may end up inside a prohibited area. Bots may pass out of such areas, but they will not actively try to enter them.
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 "do not enter" brushes should not be used outside the world hull.
∑ The "do not enter" brush is Not a clip brush for the Bot.
∑ The "do not enter" brush is a tool of last resort. Do not use it unless there are serious navigation problems.
∑ The number of "do not enter" brushes should be minimized because these brushes create additional areas for the bots.
∑ The "do not enter" brush will create a new area that the Bot will try to avoid. However if the Bot somehow ends up inside a "do not enter" area or there is a valid goal (game entity or item_botroam entity) inside the "do not enter" area then the Bot is allowed to go into and out of that area. So if the Bot somehow gets in a "do not enter" area the Bot will be able to get out.
"Notbot" Means "Don'tTouch"
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 only a few functions of WFA, namely the func_buttons and func_plat
|bot_aasoptimize "0"||Optimize the .aas file when writing.|
|bot_debug "0"||Debuging tool for bots.|
|bot_developer "0"||Developer mode for bots.|
|bot_enable "0"||Allow bots in the game or not. NOTE: If a server disables bots, then the CD is not required in the drive.|
|bot_fastchat "0"||Frequent or infrequent chat strings.|
|bot_forceclustering "0"||Recalculates the aas clusters.|
|bot_forcereachability "0"||Recalculates the aas reachability.|
|bot_forcewrite "0"||Writes out a new aas file.|
|bot_grapple "0"||Determines if bots will use a grappling hook.|
|bot_interbreedbots "10"||Number of bots used for goal fuzzy logic interbreeding.|
|bot_interbreedchar ""||Bot character to be used with goal fuzzy logic interbreeding.|
|bot_interbreedcycle "20"||Number of matches between interbreeding.|
|bot_interbreedwrite ""||File to write interbreeded goal fuzzy logic to.|
|bot_maxdebugpolys "128"||Max number of polygons available for visualizing things when debugging.|
|bot_memorydump "0"||Memory allocation for bots?|
|bot_minplayers "0"||Makes certain that a minimum # of players are on a server by adding bots to bring it to that level. If a player joins, they will take a bots spot.|
|bot_nochat "0"||Determines if bots will chat.|
|bot_pause "0"||Debug command to pause the bots.|
|bot_reloadcharacters "0"||Set to 1 to disable Bot character file caching. This is used when creating Bot characters while keeping Q3A running. Kicking and re-adding a Bot will reload the Bot character files.|
|bot_report "0"||Debug command to have the bots report what they are doing in CTF.|
|bot_rocketjump "1"||Determines if bots will use rocket jumps.|
|bot_testichat "0"||Tests the initial Bot chats. Set this to 1 and add a Bot and the Bot will spit out all initial chats.|
|bot_testrchat "0"||Tests the reply chats. Set this to 1 and add a Bot and the Bot will always reply and dump all possible replies.|
|bot_testsolid "0"||Tests for "solid areas" in the .aas file.|
|bot_thinktime "100"||Sets the amount of time in milliseconds a Bot thinks about a move before making it.|
|bot_visualizejumppads "0"||Viisualizes the default arch of a jumppad.|
More from the bspc.txt
Title: BSP Converter
Author: Mr. Elusive
The BSPC tool is used to create AAS files from BSP files. An AAS file is a file with areas used by the Quake III Arena bot in order to navigate and understand a map. The Quake III Arena maps are stored in
bspc [-<switch> [-<switch> ...]]
Example 1: bspc -bsp2aas d:\quake3\baseq3\maps\mymap?.bsp
Example 2: bspc -bsp2aas d:\quake3\baseq3\pak0.pk3\maps/q3dm*.bsp
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
breadthfirst = breadth 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 metacharacter 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. 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.
Updating entity lump
If an AAS file is already available for a BSP file and you ONLY change the entities inside this BSP file then you only have to recalculate the reachabilities. This way you can move items, platforms etc. around without the need to recalculate the whole AAS file which can save quite some compile time. You can recalculate the reachabilities as follows:
bspc -reach mymap.bsp
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 the whole AAS file HAS to be recalculated in order to play with bots.
NOTE: -reach does not work on optimized .AAS files!
Just like there can be vis leaks in a map there can also be clipping leaks. Two things can be wrong when the BSPC tool outputs that a map leaks.
1. There are no entities in the map at all, or all entities that are actually in the map are placed in solid. In this case the BSPC tool outputs "WARNING: no entities inside". (At least a player start entity is needed to load a map.)
2. There is a spot in the map where players can go outside the map into the void. This is bad, players should never be able to fall out of a level. In this case the BSPC tool outputs "WARNING: entity reached from outside". The BSPC tool also writes a mymap.lin file that can be loaded in the Q3Radiant editor to show lines that go through the actual leak.
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.
Currently a map should be within the bounds (-8192, -8192, -8192) - (8192, 8192, 8192) for the bspc tool to compile. These are the same limits the q3map tool has.
The player bounding box is a 30 units by 30 units square with a height of 56 units. If we assume 1.75 meters being the average height of a human and a player in Quake III Arena being 56 units high we get 32 = 1 meter.
Maximum step height of a player is 18 units (just keep steps 16 units or lower).
The maximum water jump height for bots has been set to 18 units. (height difference between water surface and the floor jumping onto). If the waterjump 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).
The maximum height for barriers the bots will jump on is 32 units.
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 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 both at the same height:
t = sqrt((maxjumpheight + maxstep) / (0.5 * gravity));
t = 0.3986 seconds;
dist = maxrunvelocity * (t + jumpvelocity / gravity);
dist = 235 units;
Because players use a bounding box we can jump a full bounding box width furter in the ideal case. (15 units at the jump start and 15 at the landing place).
235 + 15 + 15 = 265 units.
Again this is the mathematical maximum which players can only reach under ideal circumstances.
Optimizing a map for bspc
Hint brushes have no effect on the bspc tool. Only solid, clip and liquid brushes are used by the bspc tool.
The bspc tool outputs how many areas are created for a map. Less areas is better. Often the number of areas can be reduced by adding additional clip brushes. By adding these additional brushes the complexity of the geometry used for collision can be reduced. For instance add clip brushes with simple shapes (prefered axial) 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's preferred to place the clip brushes around the whole curve (not just part of the curve). You can also make brushes or curves non-solid when they are enclosed by (full) clip brushes to 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
back sides 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 no tiny faces are created by badly aligned brushes.
Quite often there are also places in a map that are visible to players but players can never get there. Players would be able to walk around there but since players can never reach such places they will never actually move around there. If players should never be able to get to such places it's better to put a large clip brush which encloses that whole 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
func_plat and func_bobbing
When func_plat or func_bobbing entities are placed in a map the bots will use them if possible. The bots assume they can stand on top of the bounding box of the model used for the func_plat or func_bobbing entity. As a result creating complex shaped func_plat or func_bobbing models is mostly a bad idea. You have to make sure the bots (and players) can actually stand everywhere ontop of the bounding box of the model.
A map is divided into areas. Several of these areas can be grouped together to create a cluster. The clusters are seperated by cluster portals which are areas themselves. One of the things the bot uses these clusters for is a multi-level routing algorithm. When a map is efficiently divided up into clusters bot calculations will be faster.
several things to take into account:
- The BSPC tool creates cluster portals automatically but additional cluster portals can be created by placing "clusterportal" brushes.
- Cluster portals are manually created by placing "clusterportal" brushes inside the map.
- The "clusterportal" brushes should not be used outside the world hull.
- The cluster portals do not have any effect on vis.
- If a door is already sealed with an areaportal brush, a clusterportal is not necessary there. (area portals are also used as cluster portals).
- Just like the area portals, the cluster portals must seal a space off entirely from other areas.
- The cluster portal areas should seal off a cluster in a way that the only path towards another cluster is through a cluster portal area.
- Only create cluster portals where people can walk or swim through.
- Don't create cluster portals in gaps in the floor. (people would fall through)
- Cluster portals must seperate no more and no less than two (2) clusters.
- Try to create clusters with all the same number of 'reachability' areas. for instance if the map has 5400 areas try to create 10 clusters with 540 areas each, or 12 clusters with 450 areas each, etc. The BSPC tool lists the number of reachability areas in each cluster.
- Avoid creating clusters with only a few (less than 10) areas.
- When adding "cluster portal" brushes try to place them in places with minimal geometric complexity. For instance place them inside convex door
openings or small hallways (not infront of door openings). Ideally the shape of the face through which a player walks or swims into the cluster portal is the same as the shape of the face through which a player leaves the cluster portal. Also ideally the open space inside the cluster portal brush is convex.
- Make cluster portals about 16 or 32 units thick.
Do Not Enter areas
When bot navigation problems show up or you want to make sure a bot never tries
to go to a certain place "do not enter" brushes can be used.
several things to take into account:
- The "do not enter" brushes should not be used outside the world hull.
- The "do not enter" brush is Not a clip brush for the bot.
- The "do not enter" brush is a tool of last resort. Do not use it unless there are serious navigation problems.
- The number of "do not enter" brushes should be minimized because these brushes create additional areas for the bots.
- The "do not enter" brush will create a New area that the bot will try to avoid. However if the bot somehow ends up in a "do not enter" area or there is a valid goal inside the "do not enter" area then the bot is allowed to go into and out of that area. So if the bot somehow gets in a "do not enter" area the bot will be able to get out.
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". The value 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. 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 to high.)
When a bot should never go for a specific item the key "notbot" with value "1"
can be used for that item. This key with value can be used for every available
item in Quake III Arena.
The suspended 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.
Testing AAS files
One of the easiest ways to test the AAS file is to load the map in
Quake3 in teamplay mode (type /set g_gametype 3 on the console before
loading the map). Enter a team and add a bot to your team. Use the
team order menu (by default bound to the key F3) to command the bot
to follow you. Walk around the map and see if the bot is able to
follow you everywhere.
Map bugs can sometimes cause certain places in the map to show up
'solid' in the AAS file. The bots cannot travel through these 'solid'
areas. To test for these 'solid' places set the cvar bot_testsolid
to 1 on the console. (type /set bot_testsolid 1) The map has to be
started with devmap instead of map before the cvar bot_testsolid can
be set. When the cvar is set to 1 then either "empty area" or
"SOLID area" will be printed on the screen while traveling through a map.
Several map bugs can cause these 'solid' places in the AAS file.
- Sometimes microscopic brushes are left over after a brush CSG. Search
for such brushes in the problem area and delete them.
- Tiny brush faces (not curves) can also cause problems. Due to vertex
snapping in the q3map tool those tiny brush faces can be snapped out
of existence. Such faces will not show up in Quake3 and you'll see
tiny peek holes or slits where you can view through the geometry.
Allign vertexes of and edges of adjacent brushes to remove and avoid
such tiny faces. Placing a clip brush in front of the face that is
snapped out of existence will also remove the 'solid' area but of course
it's much better to remove the peek holes and slits.
- Another cause could be a brush with a collapsed side. Check how many
sides a brush has and how many sides actually have a surface. Rebuild
brushes with collapsed sides.
- All faces contained within liquid brushes using a shader without
"surfaceparm trans" set will be removed. Those contained surfaces will
not be visible and can cause the lava to appear "solid" in the aas file.
If you insist creating an AAS file for a map with bugs then the 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).
Clusters can be tested with the cvar bot_testclusters.
(type "/set bot_testclusters 1" on the console)
Jumppads can also be tested. Type the following on the Quake3 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 arch of travel (without using
air control) will be visualized.
Level designers should not worry too much about the following messages and/or warnings. The things reported are non fatal and won't cause any major problems. Some of the messages are just debug leftovers.
"AAS_CheckArea: area %d face %d is flipped\n"
"AAS_CheckArea: area %d center is %f %f %f\n"
"AAS_CheckFaceWindingPlane: face %d winding plane unequal to face plane\r\n"
"AAS_CheckFaceWindingPlane: face %d winding reversed\r\n"
"area %d face %d flipped: front area %d, back area %d\n"
"area %d face %d is tiny\r\n"
"face %d and %d, same front and back area but flipped planes\r\n"
"AAS_SplitFace: tiny back face\r\n"
"AAS_SplitFace: tiny back face\r\n"
"AAS_SplitArea: front area without faces\n"
"AAS_SplitArea: back area without faces\n"
"gsubdiv: area %d has a tiny winding\r\n"
"AAS_TestSplitPlane: tried face plane as splitter\n"
"found %d epsilon faces trying to split area %d\r\n"
"AAS_SplitArea: front area without faces\n"
"AAS_GetFace: face %d had degenerate edge %d-%d\r\n"
"AAS_GetFace: face %d was tiny\r\n"
"WARNING: huge winding\n"
"bogus brush after clip"
"split removed brush"
"split not on both sides"
"two tiny brushes\r\n"
"possible portal: %d\r\n"
"portal %d: area %d\r\n"
"WARNING: CM_GridPlane unresolvable\n"
"WARNING: CM_AddFacetBevels... invalid bevel\n"
"WARNING: CM_SetBorderInward: mixed plane sides\n"
"WARNING: bevel plane already used\n"
"trigger_multiple model = \"%s\"\n"
"trigger_teleport model = \"%s\"\n"
"found a trigger_push with velocity %f %f %f\n"
"AAS_TraceBoundingBox: stack overflow\n"
"AAS_TraceAreas: stack overflow\n"
"AAS_LinkEntity: stack overflow\n"
"MergeWindings: degenerate edge on winding %f %f %f\n"
"Warning: MergeWindings: front to back found twice\n"
"FindPlaneSeperatingWindings: winding1 non-convex\r\n"
"FindPlaneSeperatingWindings: winding2 non-convex\r\n"
When one of the following messages, errors or warnings is found then there is often something to be fixed.
"WARNING! HashVec: point %f %f %f outside valid range\n"
"This should never happen!\n"
While storing the AAS file some vertex was found outside the valid map bounds. When this happens some part of the map is likely to have badly aligned brushes or weird shaped curves. Clipping off or rebuilding complex shapes often helps.
"trigger_push start solid\n"
The trigger_push start point is in solid. Try making the trigger_push brush a bit larger or move it around a bit.
"trigger_push without target entity %s\n"
Could not find the target entity of the trigger_push with the target field %s.
"trigger_push without time\n"
trigger_push entity found without "time" field.
"trigger_multiple not in any jump pad area\n"
"trigger_push not in any jump pad area\n"
A trigger_push entity was found not to be in any valid jumppad area. (the message states trigger_multiple but it should have been trigger_push) Try making the trigger_push brush a bit larger or move it around a bit.
"trigger_multiple at %1.0f %1.0f %1.0f without target\n"
A trigger multiple was found at the given coordinates without a "target" field.
"target_teleporter without target\n"
A target_teleporter entity was found without target field.
"trigger_teleport at %1.0f %1.0f %1.0f without target\n"
A trigger_teleport entity was found at the given coordinates without "target" field.
"teleporter without misc_teleporter_dest (%s)\n"
The destination of a teleporter with target field %s could not be found.
"teleporter destination (%s) without origin\n"
A teleporter destination with the target name %s was found without origin field.
"teleporter destination (%s) in solid\n"
A teleporter destination with the targetname %s was found to be in solid.
"teleported into slime or lava at dest %s\n"
A player would be pushed into slime or lave at the teleporter destination with the targetname %s.
"trigger_multiple not in any area\n"
A teleporter trigger was found not to be in any valid area. Try moving the trigger around a bit.
"func_plat without model\n"
A func_plat entity was found without model field.
"func_plat with invalid model number\n"
A func_plat entity was found with the model field set to some invalid number.
"func_bobbing without model\n"
A func_bobbing entity was found without model field.
"func_bobbing with invalid model number\n"
A func_bobbing entity was found with the model field set to some invalid number.
"%s in solid at (%1.1f %1.1f %1.1f)\n"
An item with classname %s was found to be in solid at the given coordinates.
"empty aas link heap\n"
Some part of the map has some rather complex clipping. Reduce the geometric complexity or use clip brushes to reduce the clipping complexity.
"too many entities in BSP file\n"
There are too many entities in the bsp file.
"error opening %s\n"
Could not create a new AAS file. Hard disk might be full.
"error writing lump %s\n"
Could not write an AAS lump to file. Hard disk might be full.
Bot Commands | Bot News