.:: Bots United ::. - View Single Post - Limitation of actions in the aiscript file

TomTom · **Re: Limitation of actions in the aiscript file -** 09-12-2007

For a first WIP very good.
I'll just give some general advise and preferences here. Specific observations I'll leave for a PM later.

Aim actions:
There are 2 general styles IMO. I prefer to use an action_add 3 3 70 1023 1 0 0 style. That is an aim-only action that is enabled at game start and remains active forever. An alternate style is to place the aim actions in with the camp actions e.g. action_add 0 3 40 1023 1 X -1. The problem with the latter and with other aim actions that are not active throughout the game is that it adds another thing that you need to keep track off to prevent error messages (and bots turned in a random direction). Likewise if you make your aim actions team specific (action_add 3 -1...) you will probably have to either add more actions (and there is a limit) or find and re-edit your existing aim actions. Conceivably the only reason you would ever want to disable an aim action would be if you had one camp linked to multiple aims and I don't recommend that. Also the aim direction need not be exact, bots scan within their FOV better than most human players and are expert at discerning the direction you are firing from.

Roams and Alt roams:
Bots do not need to touch/enter the action radius of a roam to satisfy it. They only need to touch the roam's closenode. So a good practice is to place the action on top of the node that you want them to navigate to. This is very important if you are trying get the bot to touch something (like a heath and ammo cabinet...). And like all actions double checking the closenode attribute can be very important when looking to do a quality release.

Route nodes:
the bindlestiff is the expert on these, but I will put in my 2 cents. Routes at spawns if they are to cover all the spawn pads (visible for your team with command: mal_showspawns 1) ,then the radius can get rather large. And when the spawns are scattered you may make even larger. But the one thing you do not want is the route's radius to touch any of the alt-roams that are used by this roam. Now the editor menu goes upto 1024 for the draw distance so routes that are smaller than that you should be able to see the spokes when viewing with draw radiuses on. Therefore it is a good idea to keep route radii under 1024. Now if spawn pads are badly scattered (>1024) you can always use multiple identical routes and cover the spawns that way.

Camps except mg42 and panzer:
Bots are quite happy to waste ammo into the wall in front of them, so set the action radius and stand-up flag (action_ent of 1) as needed.

Zombies:
If you see bots standing still spamming simple messages (I'm attacking etc.) for more than 5 seconds then they are likely zombied because an action they have selected to pursue they can not find a path to that action's closenode. This typically happens through a game state that has enabled the action but disconnected the path (through the aiscript or a conflict between the aiscript and the goal tracker). To diagnose this problem you need to compare the g_action_info goal with the current goal_num to see if the action is currently equal (active). Then check that the closenode can be navigated to by that bot. Checking the closenode is very important. I can't tell you how much time I lost on dm_hillb2 and NOTW because the closenode of just one action in the whole waypoiints were wrong. When you review the ability of the bot to navigate to the closenode you need also be aware that the node flag for dangerous leap and team-specific nodes may prevent the bot navigating. There is one exception to the 5 sec. rule. Engineers that select a dynamite objective that already has dynamite planted, only seconds away from blowing up will till the dynamite to blows or is defused before moving.

Active forever:
When using aiscript activation/deactivation, all actions should be set as active forever (action_active x 1). Forgetting this step can complicate debugging because those actions that stop working were likely stopped by the goal tracker. IMO only ports of maps from RTCW are candidates for using the goal tracker (but do use goal 0 for actions that must be active from the start of the game).

I'll keep these tips in mind should we redo Denny's RTCW tutorial.

	(#9)
TomTom ET Waypointing team member Status: Offline Posts: 745 Join Date: Jun 2006	Re: Limitation of actions in the aiscript file - 09-12-2007 For a first WIP very good. I'll just give some general advise and preferences here. Specific observations I'll leave for a PM later. Aim actions: There are 2 general styles IMO. I prefer to use an action_add 3 3 70 1023 1 0 0 style. That is an aim-only action that is enabled at game start and remains active forever. An alternate style is to place the aim actions in with the camp actions e.g. action_add 0 3 40 1023 1 X -1. The problem with the latter and with other aim actions that are not active throughout the game is that it adds another thing that you need to keep track off to prevent error messages (and bots turned in a random direction). Likewise if you make your aim actions team specific (action_add 3 -1...) you will probably have to either add more actions (and there is a limit) or find and re-edit your existing aim actions. Conceivably the only reason you would ever want to disable an aim action would be if you had one camp linked to multiple aims and I don't recommend that. Also the aim direction need not be exact, bots scan within their FOV better than most human players and are expert at discerning the direction you are firing from. Roams and Alt roams: Bots do not need to touch/enter the action radius of a roam to satisfy it. They only need to touch the roam's closenode. So a good practice is to place the action on top of the node that you want them to navigate to. This is very important if you are trying get the bot to touch something (like a heath and ammo cabinet...). And like all actions double checking the closenode attribute can be very important when looking to do a quality release. Route nodes: the bindlestiff is the expert on these, but I will put in my 2 cents. Routes at spawns if they are to cover all the spawn pads (visible for your team with command: mal_showspawns 1) ,then the radius can get rather large. And when the spawns are scattered you may make even larger. But the one thing you do not want is the route's radius to touch any of the alt-roams that are used by this roam. Now the editor menu goes upto 1024 for the draw distance so routes that are smaller than that you should be able to see the spokes when viewing with draw radiuses on. Therefore it is a good idea to keep route radii under 1024. Now if spawn pads are badly scattered (>1024) you can always use multiple identical routes and cover the spawns that way. Camps except mg42 and panzer: Bots are quite happy to waste ammo into the wall in front of them, so set the action radius and stand-up flag (action_ent of 1) as needed. Zombies: If you see bots standing still spamming simple messages (I'm attacking etc.) for more than 5 seconds then they are likely zombied because an action they have selected to pursue they can not find a path to that action's closenode. This typically happens through a game state that has enabled the action but disconnected the path (through the aiscript or a conflict between the aiscript and the goal tracker). To diagnose this problem you need to compare the g_action_info goal with the current goal_num to see if the action is currently equal (active). Then check that the closenode can be navigated to by that bot. Checking the closenode is very important. I can't tell you how much time I lost on dm_hillb2 and NOTW because the closenode of just one action in the whole waypoiints were wrong. When you review the ability of the bot to navigate to the closenode you need also be aware that the node flag for dangerous leap and team-specific nodes may prevent the bot navigating. There is one exception to the 5 sec. rule. Engineers that select a dynamite objective that already has dynamite planted, only seconds away from blowing up will till the dynamite to blows or is defused before moving. Active forever: When using aiscript activation/deactivation, all actions should be set as active forever (action_active x 1). Forgetting this step can complicate debugging because those actions that stop working were likely stopped by the goal tracker. IMO only ports of maps from RTCW are candidates for using the goal tracker (but do use goal 0 for actions that must be active from the start of the game). I'll keep these tips in mind should we redo Denny's RTCW tutorial.