Basic FritzBot Map Tools Info

Maleficus · **Basic FritzBot Map Tools Info -** 05-07-2005

This is a VERY basic and rough guide on how to use the included tools with FritzBot.

First off, by default the tools are disabled. This is to conserve memory and processor power. I know its a pain, but its VERY important for older systems to keep them disabled by default.

There are three things you have to do to enable the tools:

1. Be sure you started the map you want to waypoint in developer/cheat mode (i.e. "devmap mp_keep" if mp_keep is the map you want to waypoint).

2. Type "node_editor 1" into the console to actually activate the tools.

3. Type "vid_restart" into the console to make your changes take effect.

The FritzBot tools are all console based, though there is two different huds available to give you feedback about your path file.

Type "node_drawhud 1" and "node_vis 1" into the console to activate the node graphical hud and path drawing code, respectively.

ATM, if you haven't pathed this map yet, you'll see nothing.

Its time to add your first node.

Maleficus · *Last edited by Maleficus; 19-07-2005 at 07:49..*

--------------------------------------------------------
Available node commands and their function:
--------------------------------------------------------

"node_add" <- adds a node where you are currently standing.

Parameters (in the order they are taken - all are number values):

======
"flags"

default value: 0

tells the game what type of node this is. Valid node values and their type:

0 = Normal. Nothing special here, just a normal path node.

4 = Flag. A Capture Point or Spawn Flag is nearby. NOTE: if a flag is at all within the radius of this node, be sure to set the node's flag to this value!! It has to be inside the radius of the node for this to be set.

16 = Jump. This tells the bot a dangerous jump is up ahead. Use for steep drops (ex: jumping off the top of the base in BEACH, onto the trenches below, so they don't risk their health stupidly)

32 = Leap. This needs another leap node for the bot to target. This makes the bot aware of gaps in its path, and allows it to try to get over them safely and cheaply code-wise.

======
"radius"

default value: 70

how big an area this node takes up. A large radius is good for more open open areas. It makes the bots paths look more natural. If you need the bot to be more precise about where it walks, make it smaller (NEVER make it less than 10!!!).

======
"entity num"

default value: -1 (no entity)

tells the game what nearby entity (flag, objective, etc), this node is close to. Only used for a few special node types (like the flag one).

======
"team"

default value: 0 (any team can use)

what team is this node available to ATM. A value of "-1" means nobody can use it yet. "1" means just the axis, and "2" means the allies only. This value can be changed in the script system as the game state changes.

======
"group ID"

default value: 0

what group this node belongs to. Used as a nifty way to group nodes together for turning them on or off in the script system.

As you can see, Fritz's node system is fairly simple. It gets most of its info about the map structure from the environmental awareness system I've created for it. While this is a bit of a drain on the CPU, it allows Fritz to be very flexible and make intelligent decisions about its movement, and makes your job easier!

The max # of nodes ATM is 1024.

NOTE: you dont have to specify all of the parameters when you add a node. You can just bind a key to "node_add", and then set the specific parameters later using the cmds listed below (if you wish).

------------------------------------------------------------------------------------------------

Other node cmds:

======
"node_save" <- saves EVERYTHING path related into a .nav file based on the map's name (i.e. mp_beach is saved into mp_beach.nav).

======
"node_connect" <- Accepts 2 values: the node your creating a connection from, to the node your connecting it to. Its a one way connection.

ex:
node_connect 34 55 <-creates a one way path from 34 to 55
node_connect 55 34 <- creates a (now) two way path from 55 to 34

If you want to create a two way path by default between 2 nodes, use "node_autoconnect". It works exactly like node_connect for its parameters.

A node can have a max of 4 connections ATM. This is to keep the search space for paths down. I have found its often better to use more nodes, than more connections in A*. If it becomes a serious issue, I can up it later.

======
"node_clear" <- deletes ALL nodes on the map! Use this carefully, if you hit node_save right after, you lose any progress you've made!

======
"node_flag" <- changes a nodes "flag" to the value you set.

Ex:
node_flag 5 16 <- sets node 5 flag value to 16 (jump).
Be careful! While it WILL catch if you set a bad node value, it won't catch if you set a bad flag value.

======
"node_group" <- changes a nodes group ID to the value you set.

ex: node_group 5 2 <- changes node 5's group ID to 2

======
"node_move" <- moves the node to your current position

ex:

node_move 5 <- moves node 5 to where your standing ATM.

======
node_ent <- sets the nodes entity number

if node 67 is close to a spawn flag, set its entity number to the entity number of the flag (use the "viewent" command to get the name and entity number of an entity. Just point to an entity, and use "viewent" it will show everything you need - bind it to a key!).

ex:

node_ent 67 117 <- node 67's entity number is now 117 (a close by flag).

======
node_radius <- sets a node's radius

ex:

node_radius 67 100

======
node_team <- sets a node's team

ex:

node_team 56 -1 <- no team can use node 56 for pathing

node_team 44 0 <- any team can use 44 for pathing

node_team 34 1 <- only axis can use node 34

node_team 99 2 <- only allies can use node 99

======
node_resetlinks <- resets all of a nodes connections to other nodes

ex:

node_resetlinks 66 <- node 66 now has no outgoing connections to other nodes! Tho other nodes can still connect to 66

======
node_num <- prints closest node to your position

Maleficus · *Last edited by Maleficus; 06-07-2005 at 18:34..*

As you can see the path system is not used for anything bot goal related. They just use the nodes to get from point A to point B.

To control where/what/when a bot goal is, Fritz uses a system called "Actions". They are similiar to path nodes in many ways (they can have an org, be moved around, manipulated in the script, etc), but they are also very different and useful.

EVERYTHING bot goal related is usually controlled by some kind of "Action" somewhere on the map.

Maleficus · *Last edited by Maleficus; 06-07-2005 at 19:41..*

--------------------------------------------------------
Available action commands and their function:
--------------------------------------------------------

"action_add" <- adds an action where you are currently standing.

Parameters (in the order they are taken - all are number values):

======
"AXIS OBJ" <- the axis goal at this particular action (if one exists).

default value: -1 (NO goal)

When the axis bots scan thru the available actions, this tells them what action is available here (ex: camping, planting, roaming, mg42, etc, etc).

======
"ALLIED OBJ" <- the allied goal at this particular action (if one exists).

default value: -1 (NO goal).

This is the same for the allies as it was for the axis. You may be wondering why there are two goals for one action. Well, think about it: when you have a goal that you want the allies to plant on, you also want the axis to defuse there too, right? Or perhaps you have some place you want one team to camp on, and another to just patrol thru. The possibilities are limitless. If you have an action that you only want one team to use, set the other teams flag to -1.

Here are the possible values available for AXIS OBJ and ALLIED OBJ:

0 = CAMP. This is a camping spot for the bot.

1 = MG42. There is a mg42 nearby. This isn't used as a goal per se. Its more of a hint on where a nearby mg42 is for the bot. In combat, it will look for nearby actions that have this flag, and if the target is in firing range of the mg42, the bot may decide to use it.

2 = Capture point flag. This is only for the capture point game mode. It just marks that a flag is nearby.

3 = Aim point. You can use this in conjunction with the camp flag to have a point that bots can look at while camped (how that works will be explained later).

4 = dynamite goal. This is a place to plant. The radius you set for this will determine the area the bot may plant in.

8 = defuse goal. This is the opposite of above. EX: on beach, the wall is a dynamite goal for the allies, but a defuse goal for the axis.

16 = spawnflag. This is only for spawnflags, letting the bot know one is available as a goal.

32 = deliver. A place to run to to deliver the docs or whatever the obj is.

64 = steal. A place to steal the map's obj (docs, etc).

512 = airstrike hint. This is a place LTs can throw airstrikes. EX: on beach, there are several of these placed on top of the walls, so that bots from both teams will throw airstrikes over the wall to harass the enemy.

2048 = roam/patrol goal. This is just a place for the bot to visit.

4096 = sniper point. A good place for a sniper to hang out.

8192 = panzer camp point. A good place for a panzer to hang out.

7 = ENG camp - a place for an ENG to camp after having planted (NOT USED ATM, BUT WILL BE ADDED).

You may notice that the number values are kinda odd. Well, originally I was going to use bit math for these so that you could have multiple actions per team. I later found out that doing so caused a lot of problems, so I stopped (but I had already waypointed several maps, and was too lazy to do it over again). So if you think its odd - you're right.

======
"radius" <- works just like the one for nodes - its area of effect.

default value: 70

======
"Entity number" <- whatever ent this action may point to.

default value: -1 (NO entity).

This works just like the node one. For ex: if you had a mg42 action, you would set this to the entity number of the mg42 itself.

======
"active forever" <- once activated, is this action active forever?

default value: 0 (NO, its not active forever).

This is used to mark actions you may want to keep, no matter what changes on the map (perhaps you have a camp point that you always want the bots to use, during the course of the whole game, set this flag to 1 to make that happen).

======
"Group ID" <- this is like the one for nodes, but extended

default value: 0

OK, this can get complicated. When you play a map, you can usually break down the goals for the map into some basic, discrete linear steps. EX: on beach - the first goal is to blow the walls (for allies - defend them for axis). That is the only major goal each team has. When those walls are blown, otehr goals open up (spawn flag and docs). When the docs are grabbed, only one goal becomes open - deliever them (or return them if axis).

So, if you broke it down like that, you would get something like this:

Group ID 0 (the first goal): Bomb the walls.
Group ID 1 (the 2nd goal): Grab docs, cap spawn flag.
Group ID 2 (the 3rd goal): transmit the docs, cap spawn flag. NOTE: the spawn flag is "active forever".

When an event happens (like the walls blowing) a special counter increments, and executes actions that have the same group ID number that its at.

So, when the map starts, the Goal tracker is always set to 0 to start. For the bots, it will only see actions that are in group ID 0. When the walls blow, the tracker increments to 1, so now the bots only see actions that have a group ID of 1. etc, etc, etc.

You can't control the progress of the tracker, it works by itself in the bot's event handling code.

How it works:

only certain events can increment the goal tracker:

1. OBJ being destroyed - sets goal tracker to +1.
2. Docs/obj being stolen - sets goal tracker to +1.
3. Docs/obj being returned - sets goal tracker to -1.

Certain actions will be inherited into the next group ID, if its very important, all by itself.

EX: on beach, both the door and the wall start out as group ID 0 action goals. Say the wall blows, but noone planted on the door yet. The wall being blown would cause the goal tracker to increment (the bots would know to grab docs now), but it would also "inherit" the door action from group 0. The door action would now be group ID 1. This is set in the code, you don't need to worry about it.

Now, when the door blows, it would not have an effect on the goal tracker. Why? Because it was inherited into this goal group. Basically the tracker keeps track of your original Group ID number, and if your not in your original one when your triggered, you don't have an effect on the tracker.

Whew.

That may be a difficut concept to grasp at first, but it allows me to easily control what goals the bots consider to be available, without a lot of hacks and jumping thru hoops. And I've run this code thru every possible default map, and it works fine. If you have questions on how to number your actions goals (which I'm sure you will), I'll be here to help, because I've already planned them out in my mind for most of the maps.

======
"use angles" <- this is currently not used, but needs to be accounted for

default value: 0 (dont use angles).

This was to be used to give actions an angle the bots should look at when doing an action (like if planting, look this direction, if camping, look this direction).

It hasn't been added yet, and I'm not sure its really needed since I've managed without it fine.

======
"Acceptable Classes" <- classes that can use this action

default value: 0 (any class may use this action

This is only tested use for camp and roam actions. Most of the other actions are already class specific.

Valid values:

0 = any class
1 = soldiers only
2 = medics only
4 = engs only
8 = LTs only

This uses bit math, so you can combine these values to have more than one class use it.

EX: you only want LTs and Medics to camp here, set "classes" to 10. Or only ENGs and soldiers, set it to 5. etc, etc.

Maleficus · *Last edited by Maleficus; 19-07-2005 at 07:51..*

--------------------------------------------------------
Other available action commands and their function:
--------------------------------------------------------

======
"action_move" <- moves the action to your current location

ex:

"action_move 14" <- moves action 14 to where you are now

======
"action_radius" <-sets actions area of effect, works just like node one

======
"action_class" <- lets you set what class uses this action

ex:

action_class 3 10 <- only meds and LTs and use action 3

======
"action_active" <- sets whether or not action is "active forever" or not

0 = not active forever
1 = active forever - once activated will be "inherited" into all action Group IDs

======
"action_group" <- sets the actions Group ID

======
"action_closenode" <-sets the closest path node to this action.

This is set by the game itself when you create an action, but you may find that it sets a bad one, and may want to set it yourself.

Basically, this stores the closesest node for pathing purposes, so when the bots want to move towards this action, they know what node is close to it.

======
"action_ent" <- sets an actions entity number to a value you set.

ex:

you have a dynamite action (lets say action 0). You set its its entity number to the entity number of the trigger_objective_info (lets say its 187).

action_ent 0 187 <- sets action 0's ent num to 187.

======
"action_allies" <- set the allied action at this action

======
"action_axis" <- ditto from above, but for axis.

ex: action_axis 5 0

You just set action 5s axis goal to camping.

=====
"action_clear" <- erases all the actions (but NOT nodes) on a map

Do this if your having problems with your actions, but have nodes you want to keep. This, like the node_clear command, is permanent! Beware and save/backup often!!!!

======
"action_links" <- what actions are linked to this one

OK, there are 4 available links for each action. Currently, only camp/snipe/panzer actions use this.

This is basically to tell the bot where to look when it camps.

Say you create action 4, that is for camping. then you create actions 5, 6, 7, and 8 which are aim nodes.

By themselves aim nodes do nothing, but if you link them to action 4, the bot will know to look at these four aim actions.

ex:

action_links 4 5 6 7 8

Action 4 (the camp action) now has 4 aim actions linked to it (actions 5, 6, 7, and 8).

When the bot reaches action 4 and camps, it will randomly look at the origin of actions 5, 6, 7 and 8.

MAKE SURE YOUR LINKED ACTIONS ARE "AIM" ACTIONS! If not, they will be ignored!

In the future I may have it possible to link other actions for some interesting effects, but for now thats whats available.

Maleficus · *Last edited by Maleficus; 13-07-2005 at 09:59..*

THE "FritzScript" SYSTEM:

The script system is a very flexible, simple to use extension to the action system. With it, you are allowed to turn "on" or "off" actions at will, create new paths for the bots, etc, etc.

HOW IT WORKS:

Its based inside a ".aiscript" file based on the map name. EX: mp_beach would be mp_beach.aiscript.

Its based on events, and the actions associated with them, in the game.

For example, if action "0" is a dynamite action. When the wall blows, the bot event handling system will look for any scripts that are associated with action "0".

The events that can trigger a script:

1. Dynamite exploding on an obj
2. Spawn/CapturePoint flag being taken.
3. Docs/Obj being stolen.

Any actions linked to these event types will trigger its associated script.

The first keyword in an script file MUST be "MAPTYPE" followed by the maptype integer.

There are 3 possible values

0 = Objective Gametype
1 = Dual Objective Gametype (Depot is an example of this)
2 = Capture Point Gametype

The end of the script file MUST end if the #EOF keyword to let the system know there are no more scripts to define.

The script is VERY particular about spelling and correct syntax, but is case insensitive. I only use case in the .aiscript as a personal preference to make it more "readable". There is some fairly good error recovery, but it won't catch logic errors or do the thinking for you.

A simple example script that could be used for MP_BEACH is attached at the end of the thread. NOTE: I only added on the .txt extension so that it could be handled by the forum.

ex: here is the action script for the door on beach, which is action "0":

Code:

action 0 // The sea wall door "dynamite" action
{
  node_connect 17 129 true //create a path for the bots
  openNodeGrpToTeam 1 ALLIES // allies can use the bunker nodes now!
  bot_switchToWeap random  allies //allied soldiers will mix up weapons!
  bot_switchToWeap random_f  axis // so will axis
  deactivateAction 33 // deactivate the roam by the wall breach no matter what
}

What the different keywords mean will be explained later, but as you can see - you define a script for an action simply by using the "action" keyword, followed by the number of the action, then wrap everything in {}.

FritzScript keywords and their parameters:

node_connect <node1> <node2> <true/false>

The node connect keyword works nearly exactly like the "node_connect" console cmd, with one major difference - if you want the two nodes to automatically connect to each other, follow the last node with a true. If you want a one way connection, follow with a false.

ex:

You want to create a one way path between nodes 4 and 5, then use this:

node_connect 4 5 false

OR

You want to create a two way path between nodes 90 and 100:

node_connect 90 100 true

======
"openNodeGrpToTeam"

This is for the "group ID" that was mentioned earlier for nodes (NOT actions!!!).

EX: on beach at map start, all of the nodes that are on the other side of the wall are not available to the allies. But, when one of the walls blow, they become available. By making all of the nodes in the bunker be a part of group 1, you can quickly open them to the allied team in the script all at once, without any other work needed.

======
"bot_switchToWeap"

bot_switchToWeap <weapType> <team>

weapType is one of these values:

"panzer" = panzerfaust
"flame" = flamethrower
"sniper" = sniper rifle
"smg" = country specific smg (thompson or mp40).
"venom" = venom
"random" = either the smg or the venom, randomly chosen
"random_f" = either the smg, venom, or flame.
"random_p" = either the smg, venom, or panzer
"random_pf" -OR- "random_fp" = either the smg, venom, panzer or flame

team is either:

"axis"
OR
"allies"

NOTE: this cmd will affect ALL soldiers on that team, so be aware of that!

======
"resetNodeFlag"

resetNodeFlag <nodeNum> <flagValue>

sets nodeNum's flag to flagValue

ex:

If node 14 is a jump node, but after a wall blows, a bridge is made that make 14 no longer be a jump node, you can reset it to a normal path node.

resetNodeFlag 14 0

======
"activateAction" -OR- "deactivateAction"

These two are the mirror opposites of each other.

When called, they either turn "on" or turn "off" whatever action you want.

Only use this for special actions you want to create.

--------------------------------------------------------------------------

CONDITIONALS

You are able to make an action script conditional based on other actions being completed (or not completed).

Keywords:

"if_action_true"
"if_action_false"
"if_fda_owner_axis"
"if_fda_owner_allies"
"if_OBJ_home_true"
"if_OBJ_home_false"

You may NOT stack (or nest) these conditonal tests. If you have multiple conditonal tests, you MUST use the condtional keyword for each one.

EX:

On beach, if the wall breach blows, but not the door, you may want the bots to camp near the wall breach, to jump you as you run thru it. Once the door blows tho, that camp action would be unneeded. So, lets say the the dynamite action for the wall breach is action 1. You would create a script like so:

Code:

action 1 // The sea wall breach "dynamite" action
{
  node_connect 35 259 true
  openNodeGrpToTeam 1 ALLIES
  bot_switchToWeap random  allies
  bot_switchToWeap random_f  axis

  if_action_false 0 // if the door hasn't blown yet, activate roam by wall breach!
	activateAction 33 //have axis gun down allies coming thru the breach!
}

The other two keywords are based on who is controlling the forward spawn flag. The "if_fda_ower_allies/axis" keywords MUST have the action that is in question following it.

EX: in beach, the action for the flag is 42. If the axis control it, I want the axis bots to roam out near the beach to harass the allies when they spawn, if the allies control it, I don't want them doing this. So I define a script for 42 like so:

Code:

action 42 // The Forward Spawn Flag action
{
  if_fda_owner_axis 42 //if axis grab flag, activate the "roam" actionr
	activateAction 32 //action 32 is an axis owned action

  if_fda_owner_allies 42 //if allies grab flag, deactivate the "roam" action!
	deactivateAction 32 //action 32 is an axis owned action
}

The possibilities with this system are limitless!!

Maleficus · *Last edited by Maleficus; 11-07-2005 at 07:00..*

Some basic caveats/warnings:

Don't have the nodes too close together. Its a waste of memory and time.

Done have them too far apart (the bots have a node timeout time of 3.5 seconds to reach each new node).

When pathing for doors/doorways, put a node on either side of the door (usually with a radius of 45 or so), and put a node directly in the middle of the door with a small radius, so the bots can see where the door leads.

Don't stick nodes right inside the area bots spawn if it can be helped, better to stick them a bit outside, and use several, so that they dont all rush one node after spawning.

Dont stick actions inside the spawn area if it can be helped.

Stick MG42 actions about a body width right behind the mg42 itself (look at how they are placed on beach for an example). EX: if you were standing right in front of the MG42, touching it, the action for it would go right behind you so that it was touching your back.

Use the console cmd "goal_num" to see at what goal number the bot's goal system is.

Use the cmds "g_action_info <actionNum>" and "g_node_info <nodeNum>" to see the stats about a particular action/node as the game state changes.

NOTE: the waypoint editor is totally seperate from the nodes that the bots load up and use. The editor is client side, and the bots are server side, so they will each have a different copy of the path file. If you make changes, the bots wont see it unless you do a "map_restart".

BE sure to save your path often - if you do a map_restart without saving your changes, you will lose them!

Use "node_drawHud 2" to see a hud just for actions. Both huds will display the info of the closest action/node to you.

When you use viewent to target a dynamite objective, make sure you use the entity number of the "trigger_objective_info" NOT the "func_explosive"!

Refer to the MP_BEACH path file for an example to do a lot of the thing you'll want to do.

DON'T take MP_BEACH as gospel tho - theres a lot of stupid, lazy things I did that I need to fix/change. When in doubt, check with me.

type "\node_" into the console and see all of the other node based hud/editor cmds that are available to you. You can change the drawdist, time, etc, etc.

32 is the max number of bots you can add.

64 is the max number of action tests you can have. I can add more if its a problem.

a radius of 45 or so works good for the bottom of ladders, while 15 seems to work good for the top of them.

Backup your path work often (stick a copy in another dir, or name it something else).

Fritz at this stage is still very rough - the path editor/script system is done and stable, but the Fritz your getting is in the middle of half a dozen different changes/new features that I haven't had time to work on, so expect the unexpected.

They also suck at BEACH ATM because I never updated the nav file to reflect all the new path/script stuff I added yet.

If you add a bot with no valid actions in the map, he'll just stand around and laugh at you.

When your pathing or working on a script - check your console often. When the map loads, you will get some feedback if there was any problems.

Feedback is welcome, and I'll try to improve it as best I can if you need me to, but please don't expect me to create a wonderful GUI or awe inspiring menus - I can't code that shiznit to save my life!

node_drawRadius 1 will draw the node's radius instead of its connections. a value of 0 turns it off.

The visualization of connections start at the top of the node, and point downward to the node its connected to.

"node_vis" parameters:

1 = draw everything
2 = draw only actions
3 = draw only routes (NOT AVAILABLE YET!)
4 = draw only path nodes

These are useful as filters if you just wanna check one thing.

NOTE: node_drawDist is set low for a reason! The RTCW has a limit on how much you can draw at any one time. The default is 512. 1024 is about as high as you should go. Playing with the node_drawDist and node_drawtime cmds can seriously improve/harm your FPS.

There is NO way to delete nodes or actions ATM outright. However, if you set a nodes flag to -1, or an actions allied and axis objs to -1, they are deleted for all intends and purposes. NOTE: DON'T just set a node thats connected to other nodes to -1. You have to make sure any connnections to it are deleted first (using node_resetlinks). Better yet - what I did was just reused nodes I didn't need somewhere else using the node_move cmd. You are encouraged to use this technique as well, for now.

Remember - you can turn on/off as many actions as you feel like in the script. In my example BEACH script I only turned 1 on/off at a time, but you could easily go:

Code:

action 12 //a spawn flag the two teams fight for
{ 
  if_fda_owner_axis 12 <- lets say this is flag action
   activate_action 24 <- lets say this is a camp action
 
  if_fda_owner_axis 12 <- lets say this is flag action
   activate_action 31 <- lets say this is another camp
 
  if_fda_owner_axis 12 <- lets say this is flag action
     activate_action 13 <- lets say this is another camp
 
  if_fda_owner_axis 12 <- lets say this is flag action
     activate_action 5 <- lets say this is another camp
 
  if_fda_owner_axis 12 <- lets say this is flag action
     activate_action 61 <- lets say this is another camp
}

In this example, when the axis grab the spawn flag - 5 camp actions are activated as well. Then you could make it if the allies grabbed the flag, those 5 actions would be de activated.

NOTE: you can turn ANY action off/on with the script. Warning tho: don't touch actions that are in "the future", because when the script turns them off, they are turned off for good!
EX:
the goal tracker is set for group ID 1 actions and you activate, then deactivate a goal 3 action. When the goal tracker gets to 3, it won't use that action, because the script killed it. Theres no worry about bringing old actions back tho.

Capture Point WILL be supported this release! I won't turn my back on Fritz's roots. However - only CP only maps will be supported, I'm not going to bother with maps that play both CP and OBJ (I don't know of any that were ever popular - destruction, trenchtoast, and the custom CP maps were all I ever played on public servers).

NOTE: when you edit path files - make sure you have sv_pure set to 0! You won't be able to access them otherwise (you should probably have sv_pure to 0 anytime you run a mod anyway!).

Be SURE to read this whole guide thru and understand it. I'll edit it and add some things here and there, so always keep an eye on it. Best to print out a copy of this whole thread for reference: I wrote and designed all of this, and even I can't remember all of it.

-------------------------------------------------------------------
MORE TO COME AS I THINK OF IT!

Major thanks to Wave of the UberSoldat team for help with the clientside node drawing code! Thanks man!

Maleficus · *Last edited by Maleficus; 12-07-2005 at 13:28..*

Some additional caveats/warnings:

NEVER place 2 dynamite actions on one obj. This can be a pain where its possible to get to the obj from either side to dynamite it, but its a limitation with the event system that makes it hard to handle 2. With 2, theres a chance something will break and the engs won't see the action as being completed. I'm working on a way to add this feature in the future.

Keep the paths looking natural and human like. The bots are able to go anywhere you can - set out the paths so that they can.
EX: if a human would just jump over a pile of small boxes and keep going, let the bot do so as well. Theres no need to path around the boxes. FritzBot isn't as confused as many other bots are by varied terrain.

Anytime you have a door or a hallway, put a node in the center of that door or small hallway with a radius thats a bit smaller than the door/hallway. For a door, its best to have 2 nodes, one on either side of the node in the center of door, with smaller than normal radii (say 45 or so). This helps the bot a LOT with finding out just how large the door is and where it goes.

When you make a "_bots.cfg" file to go along with your path file, remember to use a LEAST a couple "addbot" cmds in there, with no bot names. The addbot cmd by itself, will add a random bot, on whatever team needs it. Its also smart enough to balance the classes to on whatever team it adds the bot to.
This way, you are guarenteed that the teams will be even when someone plays your map - no matter what team they join. Look at the cfg included with BEACH for an example.

Maleficus · *Last edited by Maleficus; 15-07-2005 at 12:13..*

NEW FEATURE:

There are now two new conditionals for your scripting pleasure:

if_obj_home_true

and

if_obj_home_false

Use these ONLY with actions that are ACTION_STEAL - ANY other action and the conditional statements will be ignored as well as whatever cmd you issued. The script system will display a warning then exit script compilation when the game starts.

ex: lets say that action 15 is the docs on ICE. There is a special action you want activated that you ONLY want to activate if the docs are stolen and you want it deactivated if docs are returned.

You would then do this:

Code:

action 15
{
   if_obj_home_false 15
	 activate_action 32 // special camp action!

   if_obj_home_true 15
	 deactivate_action 32
}

NOTE: DON'T just use this for everything! The goal system will automatically update itself and increment when the docs are stolen or returned. Normally you should just number actions you want done when the docs are taken to exactly 1 group ID higher than the doc action itself (look at BEACH as being the example).

ONLY use this for oddball maps like ROCKET or ICE where its possible to grab the docs before any of the walls are blown - this way you can guarentee the bots will do what you need them to do, no matter what.

Other than the limitation listed above, it works just like any of the other conditionals.

Maleficus · **Re: Basic FritzBot Map Tools Info -** 15-07-2005

NODE radius:

Keep in mind, that when the bot hits the node's radius, it thinks its clear to move to the next node.

If you have a node with a large radius in a narrow corridor, and that corridor has a corner, it will hang up on the edge of the wall if the radius of the nodes aren't correct.

Also - in narrow hallways: the radius of a node should NEVER be larger than the space it occupies. 90% of the pathfinding issues I'm seeing is because of a radius too large.

Lastly: nodes in doorways, and at the ends of long hallways: this helps the bots pathfinding SO much. They're getting hung up on doors a lot because theres no node in the center of the door to help them. Or at the start/end of a hallway, this prevents a LOT of hangups.

Use the node_drawRadius 1 cmd to see the radius of your nodes/actions.

ACTION Radius:

The radius for the actions are just as important. For actions, the radius is considered by the bot to be the "area" it can use to do whatever the action is. If you have an action with a large radius, for example a dynamite one, you can have the bots mistakenly throw the dynamite too far and miss the obj, because the action's radius was so large.

When it comes to an example of node/action radius setting - check out beach.