FritzBot ET Actions

From Bots-United Wiki

Jump to: navigation, search

This article forms the third section of the FritzBot ET waypointing tutorial. If you are looking for the RTCW tutorial go Here.

THIS ARTICLE IS UNDER CONSTRUCTION. IF YOU WANT TO HELP FEEL FREE TO USE THE DISCUSSION PAGE. OTHERWISE PLEASE COME BACK LATER

Contents

[hide]

Basic Info

Having learned how nodes make it possible for the bots to navigate the map, now it is time you give the bots a reason to follow them. The bots know nothing about the map, so they have no reason to leave the spawn area. But by adding action points to the map the bots can chose to navigate to them to perform an action that you specify. These action points can describe where to perform map objectives, or where to place defensive positions or attack support, or patrol points or even hint about where to put a smoke screen. Properly placed nodes may help make the bots' movement look more human. But to emulate humans they also need your knowledge about what to do, where to do it, and when to do it. By waypointing in Actions, that information is provided by the action attributes, by the action placement and by the AIscript (discussed later). In this section we also introduce the concept of the goal tracker (a counter that monitors main objectives). Used mainly in FritzBot for RTCW, in FritzBot ET the goal tracker is effectively replaced by improved aiscript functionality. But the goal tracker remains part of the game logic and does help in debugging your waypoint actions.

The number of actions you place in the map will affect the play style of the bots. Too many actions may spread the bots out, decreasing their chance of massing to attack and win. Too few actions and you may find the bots somewhat predictable. You should never need to exceed the 256 Action limit. At a minimum (for objective-type maps) you might need 50-70 actions to complete the map, 100+ to make it interesting, with big maps possibly needing double these numbers. It is a good idea to start by placing the objective actions first, and minimal numbers of the optional Actions. Then work on the aiscript on/off sequencing and test the results. Once you are satisfied that the logic works, add in more Actions to improve the attack/defense behavior based on the style and strategy you prefer. Styles include the camp-ambush and the roaming fighter style. Strategies can be fixed to a step-at-a-time progression, or use a fluid multiple-point attack to probe for weaknesses. Each waypointer has their own style and preference where the map design allows.

Once you understand what action types are available and how they can be turned on/off, learning to write down a bot-strategy is a good idea. A bot-strategy helps give order to your waypointing, making it easier to fix mistakes. But more about that later.

Below we will also show how you can save your waypoints at any stage, reload the map, add a few bots and see what they do with your actions. But first lets discuss what are the properties and attributes of Actions.

Action HUD & Finding Action Info

With so many properties, having to use the console to query action attributes could be tedious. So using the in-game heads-up-display (HUD) is a faster way to review properties and see changes. To enable the HUD you should first enable the waypoint editor (if not already). This can be done in the console by;

And then enable the drawing of Actions in the map.

/node_vis 2

Restart the video if you can't see the existing yellow action spindles.

/vid_restart

Now that you can see the location of Action spindles from the console turn on the Action HUD

/node_drawhud 2 

then press enter and you should see a list of properties similar to this;

Image:Action_wHUDrad.jpg

The list may appear similar to that for nodes, and like that HUD, the action HUD refers to the Action closest to your position.

Action Num = Displays the number of the action you are closest to. This number is also displayed above the action itself.

Allied Obj = This is the specific action type set for the Allies for the action you're nearest. By default it's set to -1 (no action)

Axis Obj = Similar to Allied Obj but this one is the Axis action set for the same action point. By default this is also set to -1 (no Action). A single action point can have the same or different actions for the two teams or just have an action for one team (the other team having -1 or no action)

Action Group ID = This is the Action Group ID the particular action is part of. By grouping Actions we can turn them all on or all off by a single command in the aiscript.

Active Forever = Indicates if the particular action remains active irregardless of the Goal tracker. For legacy reasons this defaults to -1 but as will be discussed later should be 1.

Closest Node = This is the node the bot navigates to in order to find this action. By default set to the closest node. If this value is incorrect or or the node too far away (>500) the bot may not find the action when it choses it.

Action Radius = This is the logical area the action takes up on the map as shown by the radii spokes. Like nodes, action locations are spheres in 3D space, with many actions requiring the bot to touch or enter the sphere before performing the action indicated.

Action EntNum = This is the number of the map entity the particular action is linked to. For a few actions that do not depend on map entities this property is used for special logical flags.

Action Classes = This is used to tell the bots which player classes (Soldier, Medic, Engineer, Field Op or Covert Op) may use this action (if possible).

Action GoalNum = This is the goal tracker goal_num that can be used to enable this action. In aiscript control method you would only use values to either enable at the start of the round (GoalNum 0) or to leave the action so it is not enabled by the goal tracker (e.g. GoalNum -1, or 999).

Action Prone = This is the flag to tell the bot to lie down when performing the action (if possible). Use value 1 for lie down/prone, 0 for crouch/normal posture.

Action Behind and, Behind GoalNum were not implemented so ignore them and do not change their values.

Linked Actions = This is used to link certain other actions to this action. The type of actions that can be linked depends on the action type (Axis Obj and Allied Obj). Generally speaking a linked action should be active at the same time as the action that links it.

Adding an Action

Adding an action is similar to adding navigation nodes. That being said, most added navigation nodes are left in place using the default node settings. However none of the actions you are going to add will be left with all the default action settings. So you need to be familiar with the commands that change the action properties.

To add an action, first stand at the center of where you want the action to occur. This has to be close to a navigation node that the bot can use to find the action. And if the action interacts with a map entity like a MG42 nest or construction or dynamite objective then it must be placed where that map entity allows. Once you are in place open the console and type;

/action_add

and hit enter.

And nothing happens!?!

Actually no, the console says an Action was added and it was. But the default action objectives (types) when not specified are -1 meaning none. And an action is only displayed in the map editor and HUD if at least one team's objective is set.

Now you can set or modify a specific action's team objective with the two team specific commands;

action_Axis and action_Allies

To set the objective for team Axis on say action number 4 type;

/action_Axis 4 n 

where n is the number referring to the type of action you want the axis to perform here. Action types are covered in a later section below. For the Allies

/action_Allies X n

command will set action X to objective type n

Extra Parameters for action_Add command

Rather than deal with initially invisible added actions, you can set the objective types and other properties on the command line with the action_Add command. Even just using a safe type can help avoid the confusion of not seeing the action when first added. For instance an action_aim type can be added but have no effect unless connected(linked) to another action (more on linking later). So

/action_Add 3 -1

Adds an aim action (3) for team Axis but sets no action type(-1) for the Allies.

The parameters that can be added to the action_Add command are for the following properties; Axis objective, Allies objective, action radius, entity number, active attribute, action group, goalnum activate, bot class, and the prone operation option. We will discuss these properties later (below).

TO DO: more on effect of closenode , "no node in sight"

Deleting Actions

There is no action_delete command. But you can make any single action invisible and the bots will then ignore it. Better still you can change it to reuse it someplace else in the map.

Making an action invisible to bots is like making nodes unavailable. Bots ignore all actions that don't have objectives set for their team, so to effectively remove an action just simply set both the Axis and Allied objectives to -1. For example to make action 5 completely unavailable, open the console and enter /action_axis 5 -1 then hit enter. Next enter the command /action_allies 5 -1 and hit enter. When both teams' objectives are equal -1 the action should disappear from the editor display and so action 5 appears 'deleted' (but is really disabled and invisible).

Now it is possible to truly delete all the actions in your waypoints at one go just like you can delete all the navigation nodes. This /action_clear command can be quite dangerous to preserving your work if you make the mistake of doing a node_save afterwards. For this reason never bind any key to the action_clear command, and always keep multiple backups of your work (Hobbits waypoint editor creates .nav file backups each time you use file:save)

Since there are a maximum of 256 action nodes, a better solution is to move the no longer wanted action(s) to an out of the way location. Then change the action objective for both axis and allies to 3 (aim_action) until you are ready to re-use these spare action nodes.

Moving an Action

The /action_move command works much like the command to move navigation nodes. When you know what action you are going to move, then walk, run or fly over to the intended new location. Next open the console and type /action_move X, where X if the number of the action you want to move. For example to move the fourth action that was added to the waypoints (I.e. action number 3) to your current position, open the console and type /action_move 3 then hit enter. Back up a bit and you should see action 3 in front of you.

When you use action_move you will often see a warning about the closenode. Actions must be within 500 units of a navigation node in order to work. Rarely action_move can't decide what the new closenode should be. In those rare cases the old closenode value remains and this could be a problem. So after any action is moved it is a good idea to check the hud to see if the closest node values is set to one of the closest navigation nodes.

Grouping Actions

Note: Action groups in FritzBot ET are different from FritzBot for RTCW. In order to control when actions are enabled, the aiscript can either refer to a single action or it can refer to a group of actions. This group of actions will consist of all actions that have the same action_group setting. Actions can belong to any one action group between 0 and 31, with 0 (zero) being the default action_group setting. To change or set the action group of any single action, open the console and type /action_group X n where X is the number of the action to be changed and n is the group number between 0 and 31. For example to set the first action (0) in a waypoint to group 5 you would type /action_group 0 5 and hit enter.

Action groupings are important to reduce the number of commands needed in the aiscript and to provide order to your work making it easier to implement a bot-strategy.

The Goal Tracker & Goal_numbers

The FritzBot ET game engine goaltracker is a feature inherited from FritzBot for RTCW. Basically the goaltracker counts the number of major objectives that are completed. This simple counter is incremented (and some times decremented) when a major objective changes to certain states. For example destruct actions (dynamite); the goaltracker increments when the destruction is complete. Likewise construct actions increment the goalnum when constructed, Etc...

TO DO: cover all major objectives

Please note that major objectives that are set to have action_Goal of -1 do not increment the goalnum. And in FritzBot ET you do not have to depend on using goalnum activation, indeed we recommend you avoid it except for the start of the match (goalnum 0).

Changing an Actions Active Status

The action active attribute is not to be confused with the active state of an action. This action active property determines how the goaltracker affects the active state of an action. When set true (1) the active attribute prevents the action from being disabled by the goaltracker (when a change occurs in the goaltracker's goalnum). Setting the attribute is sometimes referred to as the active forever property. Any actions that have to be active until the end of the match must be set as active forever. But the term active forever is somewhat misleading since an action can still be disabled by the aiscript. And entities that can only change once like one-time dynamite and explosive objectives will automatically disable themselves when completed.

With the improved aiscript capability of FritzBot ET over FritzBot for RTCW, it is preferable to use strict aiscript only sequencing of action activation and deactivation. Therefore unless you choose to use the goaltracker after initial goalnum 0, all actions should have their action_active attributes changed to 1 (default is zero).

To set the action as "active forever", the form of the command is

/action_active X 1

where X is replaced by the number(ID) of the action concerned.

You can also set the action as "active forever" when you use parameters with the action_add command. The fifth parameter after "/action_add" sets the active attribute.

Action Radius

To set the action radius, the form of the command is

/action_radius X r

where X is replaced by the number(ID) of the action concerned and r is the radius in units. For instance

You can also set the radius when you use parameters with the action_add command. The third parameter after "/action_add" sets the action's radius.

TO DO: Where it matters, how to change it, what is too small or too large 

The action radius if incorrectly set may have consequences. Example: in mine plants if the mine the engineer throws falls outside the Action radius, then the action is not satisfied, and a second mine plant in the same spot will be attempted. If the mineplant radius falls into areas where mines can't be planted, the engineer bot may stand in a spot where his throw will likely fall into that no-mines area. Another example is with Camp actions. A camp radius too large may allow more than one bot to be at that camp at one time, leaving other areas unprotected. Conversely a camp radius, especially a mg-nest camp's radius that is too small may make the bot waste time trying to get inside the radius, and never actually camp and aim in the time allowed. Mobile-mg actions can be a little bit smaller as the soldier moves slower as it lies down. Likewise in the case of covert-ops the sniper camp radius can be a little bit smaller too, but satchel actions with too small a radius too close to its objective increase the likelihood of the covert-op dying in his own satchel explosion. Not all action radii matter as roam, and alt-roam actions are satisfied when the bot get inside the navigation (Action_closenode) radius. The placement of the navigation closenode, the direction of approach to that node and the speed that the bot is moving may also affect how successful the bot will be doing an action.

Action types sensitive to radius Typical or suggested radius
Camping in the open 30 - 50
Window camp, straight aim outwards 30 - 40
Window camp, aim <= 45 degrees 20 - 25
Camp above looking down,

standing on ledge or wall, take care on approach

20-35
Basic MGnest and MG camps 30 - 50
Dynamite plant depends on plant-able area,

35-70

Construct or command post depends on construction area,

35-60

Satchel Depends on map entity, placement, bot back-off

40-70

Single mine plant varies depending on map,

40-80

Multiple mine plant in single action varies, 70 and larger
Air can or smoke can depends on throw angle and center

70 or larger

Actions insensitive to radius Suggested values for style
Roam or Alt-Roam 70 or default

(Navigation node determines roam point)

Aim action 70 or default
Event expire or event explode 10

(say 1 for scripted fake entities)

Setting Action Types

Each action can have one Axis objective and one Allied objective setting. However not all actions are actual map objectives. So the possible HUD values of AXIS OBJ and ALLIED OBJ we refer to as the action type.

Action Types Overview and Descriptions

Action types may be divided into;

  • Major map entity objective Actions (e.g. Primary and secondary objectives),
  • Minor map entity objectives (including secondary objectives)
  • Other bot high priority actions (e.g. special camps)
  • Other bot low priority actions
  • Hint actions (e.g. smoke can)
  • Map event and miscellaneous actions.

No Task/Type Setting

This is the default action setting of -1. Actions that are set for one team only will have this value for the other team. Generally you will only set this type when you want to remove one team from a previously 2-team action. For example say action 4 is a camp used by both teams and you want to turn it into an axis only camp position. You would then type in the console;

/action_Allies 4 -1

then enter

Note setting both teams action type to -1 (unused action) makes the action invisible to the game editor. So instead of setting unused actions to invisible we suggest you set them to aim actions (type 3) and park these unused actions in one place where they can be found for reused. If you accumulate too many unused actions you could exceed the maximum available (256).

Action Types: Camping and Patrolling

Roam/Patrol Actions

TO DO: discuss insensitity to radius or position i.e. close node. 
       images of roam at H&A, image showing how to aim a roam (rockeyes) 

This is the most basic action hint. It defines the point(s) the bot should pass while patrolling. It differs from many other actions in that the bots do not have enter the radius of the actual roam action and the bots do not stay at the action. Instead they consider the action completed as soon as they reach the roam action's closenode navigation node. Once there the bots select a new action to pursue and navigate to that other action.

TO DO: EXAMPLE IMAGE

To avoid confusion when reviewing your work it is a good idea to place roam actions at the navigation node you want the bots to pass by (but a little off to one side so the spindle numbers are readable). Here are examples (good and bad) of using roams to get bots to use health and ammo cabinets.

TO DO: EXAMPLE IMAGE

Roams are also used to get bots to go non-objective non-camp actions like mg, smoke, aircan, minehunt actions. These are action types are discussed later.

Even if you waypoint in the camping style, it is a good idea to have 1-2 roams active at any stage of the game. Because a roam action is not "owned" by any bot, it is always available when active. When using just camping actions you need to place more camps in all stages than the maximum number of bots. Otherwise some bots may complain in the console that they have "no goals" and could even be unresponsive to fighting. But when two roams are active bots almost never complain of having "no goals".

Now a roam action has no associated aim point so if you want the patrolling bot to look in a particular direction (say out a window, or through a doorway) you need to create the behavior by good navigation node placement, one way connections and setting the roam action's closenode property correctly.

TO DO: EXAMPLE IMAGE (rockeyes radars) 

Bot Camp, Aim & Linking Actions

The 3 most common action types you will populate the waypoints with are camps, aim points, and roams. Camps define the location of where a bot will go and sit, stand or lie down and wait for an enemy to appear. Unlike roam actions the bot has to enter the radius of the camp action before it starts its camping time. The average time that the bot will remain in a camp depends on how whether it is an ordinary camp, specialized camp or defend camp. Also how often the bot uses the camp depends on how many other actions the bot can choose from and how much priority those other actions are for the bot.

Now bots need to know what direction to look when camping. This direction is defined by the relative location of a separate aim point (aim action). So all camps must be associated or linked with one or more aim actions (except fixed MG42 camps which are directional by nature). Failing to link a camp with an aim action will result in a error message and as like as not a bot with its back to the battle.


TO DO: discuss stand flag, single vs multiple aims as well as permanently active aim actions, 
       class restriction camp defense, radius and pairing of camps 
       images of camps and the aim actions (et_slide exercise) 

Other Camp Actions

Defend Camp

Defend camps are like the basic camps except that the camping time is extended so the bot will stay put longer.

Panzer Camp

Panzer camps are specialty camps that only apply to soldier class bots equipped with the panzerfaust anti-tank rocket. (yes I know in reality panzerfaust was a recoilless gun fired shape charge and not a rocket). Since the panzerfaust can only be fired while standing, the action_prone setting is ignored. The action_class setting is also ignored. Care should be taken when placing panzer camps so the bot does not kill themselves or their team mates when firing (e.g when firing through doors or windows). And with the recharge delay the bot switches to its pistol, so the best positions are typically a bit back and often slightly above from the other bots. Panzer camps use 14 as objective type, so for example to add an axis panzer camp from the console type

/action_add 14 0 30 1023 1

then enter.

Sniper Camp

Sniper camps are specialty camps that only apply to covert op class bots equipped with either the FG42 or the scoped sniper rifles. Action type is 13.

Mobile MG42 Camp

Mobile MG42 camps are specialty camps that only apply to soldier class bots equipped with the bi-pod mobile MG42 heavy machine gun. Action type is 28.

Engineer Camp

Engineer camps are specialty camps that only apply to engineer class bots. Engineers are very important to game play so they are rarely encouraged to camp. And basic camps are rarely used by Engineers because typically there are higher priority actions to do. But rarely there are cases where an engineer may need to stay near to a defuse or construct action. Typically that may happen in a dual objective map where each team has concurrent attack and defend objectives (e.g. dynamite and defuse). So the engineer camp acts as a action equal in priority to a dynamite action, that can keep one of the engineers from pursuing the game objectives. Of course this can be dangerous since it may also prevent the team from destroying their objectives. So the general rule is to avoid using engineer camps unless really needed. But if you must use engineer camps limit the number and radius so that at least half the engineer bots won't be using them. Indeed if you have more than one engineer camp active at any one time you should probably re-think your waypoint strategy.

TO DO: discuss when to use or not to use, limiting the number of camps vs number of engineers 
       image example caha tavern? 

MG42 Actions

FritzBot ET provides 2 types of actions for fixed crew-served MG42 emplacements (1 more than FritzBot for RTCW). Additionally MG42 nests that are constructible can be treated as construct actions that can be destroyed. Unfortunately FritzBot engineers don't know how to fix those MG42s that are not constructible (but an advanced waypointing workaround is possible though not ideal and rarely used).

Because fixed MG42 emplacements have defined angles of operation no aim action should be linked to a fixed MG42 action. You need to use the /viewent command while looking at the MG42 to find the misc_MG42 entity number of the gun. That number is used to set the action_entnum of the action.

MG42 Camp

This is the MG42 action you mostly will use. It is a camping action where the bot mans the heavy machine gun and sweeps the gun from side to side through the defined angle of the MG42 entity. Action type is 18 and the action entnum property must match the misc_mg42 entity number of the fixed MG432 nest.

MG42 Basic

This MG42 action is best used on those MG42 emplacements that do not normally get manned continuously. This action acts more like a hint, telling the Bot to man the gun only if he sees opponents nearby. Like other hints, the key is to get the bot to pass nearby so that they might take the hint and use the gun. Typically a roam action is placed at the MG42 nest so the bot will go to the closenode of the basic MG42 hint. Once there it will use the gun emplacement if it sees an enemy. Otherwise it will leave the node to pursue a new action elsewhere in the map. Action type is 0 and the action entnum property must match the misc_mg42 entity number of the fixed MG432 nest.

TO DO: Discuss use with roam, alt roam or nearby camp 
       image of roam-mg combo trenches05? 

Action Types: Map Objectives

Constructions

TO DO: how even inactive constructs trigger code (aiscript) minor vs major and priority management, dynamite vs construct major plant actions. effect of multistage

Dynamite Objectives

TO DO: discuss byzantine notw 2 sided dynamite

Multiple Dynamite Plant Objectives

TO DO: discuss last 5 second disarm bug, proper linking of other identical dynamite objectives that must all be active at same time. 

Checkpoint Objectives

TO DO: explain difference between spawn flag, check flag and capture the flag

Spawn Flag Objectives

TO DO: importance of node and action having correct entnum, placement and radii of node+action, how to handle the permanent removal of the flag(aiscript), making connections pass through the flag node when flag is in spawn or when it is beside cp etc. image the_port..

Steal & Escape Objectives

TO DO: discuss goaltracker and bug prevention (aiscript), deliver bug and ensuring opposite team patrols the deliver, 

Command Posts

TO DO: when is satchelling not automatic, neutral vs team specific

Satchel

TO DO; byzantine notw 2 sided satchel satcheling of constructable mgnests and regular mgnests

Action Types: Other Hints

Airstrike Hints

These are rarely needed, because the Field Ops will use aircans normally while fighting. The places where these actions types are useful is when an airstrike can destroy a barrier, or where an aircan can be thrown over a wall or into a area near a spawn preemptively. Proper aircan placement is discussed in Tips on Good AirCan Action Placement.

Smoke Can Hint

Similar to the aircan hint is the smoke can hint to tell the covert op bot to toss a smoke grenade to hide passing players. Now unlike the aircan hint the covert op bot will not uses its smoke can unless told to do so by this action hint. Like the aircan action the bot must enter the action's radius with a full charge bar in order to perform the can toss towards the action's center. The placement of these hints should be chosen based on paths that the covert ops are likely to pass though normally or because of a class specific roam action.

This action should be used sparingly as it limits how much charge is left for satchel actions (and neutral CP satchelling too). It is most useful against Human players especially with hitsounds off. The effectiveness against bots is uncertain (they may "see" through the

Mine Spotting

This is an action hint telling the covert op bots to search for mines. This action is almost never used because the bots already know to look for nearby mines automatically, and do so increasingly as their experience points increase. However there can be cases where you want the bot to look for mines from a position further away than normal (say the opposite side of a river or bridge). In those cases link the action to an aim action placed in the area that the mines are expected to be in.

Actions that Monitor Events

These will be discussed again later in the tutorial on the bot AI script system. There are a couple of action types that are only used to monitor changes in the map.

The first one, Event expire is triggered when the entity associated with a trigger_objective_info entity is permantent removed (such as the tank and truck barrier construction crates dissappearing once the vehicle passes by in Goldrush). Also when a permanent barrier disappears (say the bank doors in goldrush) or when an object is removed this action may be able to detect the event.

The second action type, Event explode action monitors single use func_explosive entities.

Other actions that monitor events for the AI script system include dynamite, construct, construct_dynamite, steal, flag and command post builds.

Other Actions

TO DO alt_roam...

Action Classes

Some actions are by definition limited to a single bot class (soldier, medic, engineer, field op or covert op). But the more common actions (camps, roams, spawnflags, steals, delivers) are by default available to any class. These actions can be limited to one or more classes by setting the class flags of the action.

Note: Alt-roams action_class settings are seemingly ignored. So routing bots by class will require class limited actions in separate route start nodes. This will be discussed later in the tutorial on routes.

Action Postures

Actions involving bots are performed from a default posture or body position. Roams are performed standing up as the bot runs or walks about. Camps are by default performed crouching as are contruct, dynamite and defuse actions. Four actions by definition can only be performed in one position i.e. standing (MG, MG camp and Panzer camp) or lying down (Mobile MG42 camp). However other camp and engineer actions might be better performed lying down. For these cases setting the /action_prone attribute will tell the bot to go prone in the action's radius and maintain that posture until the action is complete. Additionally sometime a low wall, or window blocks the fire from a camp crouching position. To fix that Bots camping will remain in a standing posture if the camp action (camp, defend, snipe, engineer camp) has its action_ent equal to 1. (The latter is a re-use of the entity number as a special flag and does not target a map entity.) To recap;

/action_prone <action#> 1 

tells the bot to perform the action lying down, while;

/action_prone <action#> 0

tells the bot to perform the action as it would normally. And;

/action_ent <camp action#> 1 

tells the bot to stand while camping. But;

/action_ent <camp action#> 1023

tells the bot to camp as normally.

Note setting both prone and stand flags on a camp is indeterminant. This should not be confused with mineplant actions where /action_ent <mineplant actionID> 1 means plant one landmine only.

Setting an Actions Nearest Node

Each action is associated with one of the navigation nodes by the action_closenode property. This is important because the bot only gets to his chosen action by finding a path to that closest navigation node. Once the bot gets to the node it looks for the action, verifies that it can still perform it and then walks into the action radius (except for roams). Now when you add the action the editor just chooses the nearest node as the closenode, and that generally works fine. But serious problems can occur if the node it choose was say limited to just one team and the action had an objective set for the other team. Even minor issues can occur if the bot approaches the action from the wrong angle. Imagine a bot coming out of its spawn, passing the action, then turning around 180 degrees to return to the action it just passed, then having to turn another 180 degrees to face the enemy. It just would look silly and cost his team precious time. So in that example the closenode should be the nearest node on the opposite side of the action. Of course if the action and the closenode are on top of each other then that problem should not happen.

/action_closeNode X N

where Action number X will now be associated with node number N

Another example of where you want to verify the closenode property is deliver points. As discussed elsewhere putting 2 nodes closely spaced at the deliver point seems to eliminate a rare case of bot confusion where it stops at the second to last node and never delivers. But in order for the deliver action to work best it must be associated with the last of these 2 nodes on that path. If the editor set the second to last node on the path as the deliver action closenode then it will need to be changed, so verify the value.

Viewing Specific Actions

There are 4 console commands that are useful for viewing specific actions and their attributes.

in the console you can find all the action ID numbers that belong to the same action group with;

/action_group_info <group#>

And you can then select one of those actions by their ID and query their initial attribute values with;

/action_info <action#>

These are the values that get saved to the .nav file when you issue a /node_save

And to see all the current game-state values of all the action's attributes use;

/g_action_info <action#>

The former is very useful to check to see if the action is currently active by comparing its action_goal to the /goal_num.

And finally you can restrict which action types appear in the waypoint editor display with;

/node_drawonly <actiontype#> 

So /node_drawonly 0 will show a yellow spindle only for normal plain camp actions.

Console Command Quick Lookup

/viewent - Displays entity information for the objective or other map object seen in your cross-hairs.

/node_drawonly <actiontype#> - Displays only those actions in the map matching the indicated actiontype value (e.g. /node_drawonly 0 displays only camp actions)

/node_drawhud 2 - Displays the in-game action HUD

/g_action_info <action#> - Displays current game information about the specified action in the console. (e.g. /g_action_info 6 will display information in the console for action 6). Edits made after the match started are not current to the game and are not reflected in this command's output.

/action_info <action#> - Displays, in the console, information about the specified action that can be saved in the nav file. This includes any edits made after the match started whether saved or not. Matches the info in the action HUD.

/action_add - Adds an action at your present position (it remains invisible unless you give it a valid action task/type). Accepts additional optional parameters that can define most of the action's attributes (i.e. /action_add <axis actiontype#> <allied actiontype#> <radius> <entity#> <active#> <GroupID> <Goal#> <class#> <prone#> ).

/action_axis <action#> <actiontype#> - Sets the Axis action type for the specified action (e.g. /action_axis 4 0 sets action 4 as an Axis general camp action)

/action_allies <action#> <actiontype#> - Sets the Allied action type for the specified action (e.g. /action_allies 4 12 sets action 4 as an Allied roam/patrol action)

/action_clear - Deletes all actions on the map. (Use with caution if you must use it. Backup the nav file before using.)

/action_move <action#> - Moves the specified action to your current position (e.g. /action_move 17 moves action 17 to your current position).

/action_group <action#> <GroupID> - Sets the action group-ID number for the specified action (e.g. /action_group 5 1 makes action 5 part of action group 1).

/action_goal <action#> <Goal#> - Sets the action goal trigger number for the specified action# (e.g. /action_goal 5 0 makes action 5 activate at the start of the match or when the goal tracker is 0).

/action_radius <action#> <radius> - Sets the specified actions radius to the second parameter's value. (e.g. /action_radius 13 40 will set action 13's radius to 40)

/action_links <action#> <link1> <link2> <link3> <link4> - Links different actions logically. For dynamite-defuse actions links multiple plant spots to same objective. For camp actions it links up to 4 aim actions to direct the4 bots. (e.g. /action_links 4 17 19 23 makes aim actions 17, 19 & 23 available aim directions for camp action 4)

/action_ent <action#> <entity#> - Sets which map entity the given action is linked to (e.g. /action_ent 23 305 sets action 23 to be linked with map entity 305). ( Also reused as a special flag in mineplans and camp actions ).

/action_class <action#> <class#> - Specifies which player class (soldiers, medics, engineers, field ops etc.) can access the specified action (e.g. /action_class 7 1 indicates that only soldiers can access action 7)

/action_active <action#> 1 - Sets the specified action to ignore the goal tracker when active (1). The action remains active through the whole match, unaffected by any goal tracker goal_num changes. Action can only be deactivated by Aiscript. (e.g. /action_active 47 1 makes action 47 active "forever").

/action_prone <action#> 1 - If set to 1, sets the specified action to make the bot to go prone (lie down) inside the action radius. Does not apply to actions like panzer and mobile MG42 camps that can only be performed from a single posture. (e.g. /action_prone 13 1 makes action 13 an action that the bot should perform from a prone posture).

/action_closenode <action#> <node#> - Sets which node, close to the given action, that the bot navigates to in order to reach the action. This is the node the bot approaches the action from. (e.g. /action_closenode 8 39 sets node 39 as action 8's "closest" node)

Next Tutorial

There are a few test questions you can try for review Here (I suggest you open it in a new window or tab)

To continue the tutorial go to FritzBot ET Routes.

Further Reading

Credits

Special thanks go to Denny for his RTCW tutorial on which this article is modeled and borrows from.

Retrieved from "FritzBot_ET_Actions"