Looking for a good pathing tutorial

[Swanky]

Hey,

I'm looking for a good and comprehensive pathing tutorial for a friend of mine for optimizing vast networks of pathnodes. The one I used to use is unfortunatly written in german language and thus not applicable in this particular case.
Thanks in advance!

[papercoffee]

Where can I find the German one?

[Swanky]

http://www.unrealed.info/index.php?view ... e-tutorial

[papercoffee]

Dankeschön.

Edit---------------------
Maybe this helps. It's a very good tutorial and not complicated to comprehend.
http://www.birrabrothers.com/drac/index.php?dsps=107

[Swanky]

Hm that's not too bad I suppose. Would have liked some information on how to spread out pathnodes though as the maps I have seen on that particular project are cluttered with nodes.

[Wormbo]

http://www.unrealed.info/index.php?view ... e-tutorial

That tutorial besically tells you how to add actors (i.e. PathNodes) to a map and establishes a few simple guide lines on where to place them.

If you're looking for English tutorials, try the old Unreal Wiki content, e.g. http://wiki.beyondunreal.com/Legacy:Basic_Bot_Pathing

[Swanky]

Found those as well, Wormbo. I am careful with those as they seem to mix with 2k4 tutorials, which are largely the same, but not to the letter. Worse, we are using the modified Ued2.1 suited for Deus Ex, so I want to be as close as possible to the UT engine.

[sektor2111]

A copy from an document (which I don't totally respect anyway)

Spoiler

Show

The Navigation Network
Creating the Navigation Network

Unreal Tournament bots use a system of waypoints to navigate the level. Using waypoints allows UT to minimize the CPU cycles used by the AI, and gives level designers maximum control over how the AI navigates their levels.

These waypoints are defined by placing actors which are subclassed from NavigationPoint in the level. This includes actors such as PlayerStarts and Teleporters which designers will place to make their level playable. Certain NavigationPoints, such as InventorySpots and WarpZoneMarkers are automatically placed when the designer "defines" the paths (described below). Other NavigationPoints are intended for Unreal I style single player situations and are not used at all in UT. These include AlarmPoints, ButtonMarkers, PatrolPoints, QueenDests, SpawnPoints, Transporters, and TriggerMarkers.

Once the level geometry is complete, the level designer should fully map the level into the navigation network using PathNodes. Place PathNodes at intersections and turns so that there is as much clearance as possible from corners (at least 50 world units if possible). Paths need a line of sight to each other, clear to the width of the maximum width (2 * collisionradius) of creatures which will use this path. PathNodes should not be placed more than 700 units apart. Since PlayerStarts and Inventory will be placed on the navigation network, the designer can (and should) not place PathNodes where these other NavigationPoints can substitute. On stairs and ramps, the PathNodes should only be 350 units apart. The objective should be to use a minimum number of PathNodes to completely cover a level.

Version 402 of Unreal Tournament has an automatic PathNode generator which will do part of the work of placing paths automatically. It will attempt to cover the level with paths, but will not place special NavigationPoints such as playerstarts, liftcenters, etc.. To use the automatic PathNode generator, open your level in UnrealEd. Select the Window menu, and from it the log. At the prompt type 'Paths Build' (no quotes). This will take 5 to 10 minutes for a typical level.

To navigate around the level, bots will first find the nearest reachable NavigationPoint, and move to it. They will then move toward their destination, going from NavigationPoint to NavigationPoint. It is important that some NavigationPoint is reachable (there are no obstructions in the way) from any location a bot may reasonably get to in the level. If a bot can't find a valid path, either because it can't find a way to get on the network, or there is no valid way to get from the network to its destination, or the path on the network is broken, then the bot will wander (walking) around its current area.

The final step in setting up the navigation network is performing a PATHS DEFINE. This can be done by typing PATHS DEFINE into the UnrealEd console, or pressing the "Paths Define" button in the lighting section of the rebuild window. The designer can examine the network generated in any of the UnrealEd world view windows by selecting "Show Paths" from that window's "View" menu. NavigationPoints which are successfully connected will have either blue or red lines between them. Bots will use either blue or red paths, but blue paths are preferable - they indicate a cleaner, more obstruction free path. Each time geometry is changed or NavigationPoints are added or moved (including inventory, since paths are generated from inventory items), a PATHS DEFINE should be performed.

There are several common problems that result from assumptions and approximations made by the AI to minimize CPU overhead. Make sure that all NavigationPoints are separated by at least 50 world units. If two pathnodes are too close together, a bot may get stuck on them. The editor log window will display warnings during a PATHS DEFINE if paths are too close together. This problem commonly occurs with InventorySpots, which are automatically placed near all inventory items. Don't place PathNodes too near to inventory.

In some situations, bots may get stuck on the edge of a ledge where it runs into a wall. This occurs because of a threshold problem. Bots won't jump off ledges until the angle of their destination is greater than 45 degrees from the ledge direction. If they run into a wall right around this threshold, they may get confused. The solution is to adjust the NavigationPoint they were trying to reach, or add an intermediate PathNode.

Bots will have problems if the NavigationPoints are too high off the ground. Make sure that the NavigationPoint is no more than 1.5x the bot's collisionheight off the ground. This will normally be the case automatically, but in a few situations (such as very steep ramps), the level designer may need to manually adjust the Z position of the NavigationPoint.

PathNodes for the bots to use while swimming must be in the water. Placing paths above the water's surface will result in bots bobbing at that spot, attempting unsuccessfully to levitate to the PathNode's location.

WarpZones should be at least 70 units deep to allow the AI to handle them properly.

Adding Support for Lifts

There are two special NavigationPoint classes used to help bots understand how to use lifts, LiftCenters and LiftExits. Give the lift a unique tag. Place a LiftCenter on the lift, and set its LiftTag attribute to be the tag of the lift. At each exit from the lift, far enough away so that bots standing at that spot won't interfere with the lift, add a LiftExit. Each LiftExit should have its LiftTag set to the tag of the lift.

The default state for movers is BumpOpenTimed. Do not use this state for lifts! Bots misinterpret movers that are BumpOpenTimed as being doors. Instead, use the StandOpenTimed state for most lifts. Bots will also understand triggered lifts (TriggerOpenTimed, TriggerToggle, etc.). In many cases, they will use triggered lifts without any further help. However, for certain complex situations, such as when a delayed dispatcher is used to control the lift, bots may need a hint. In these cases, set the LiftCenter's LiftTrigger attribute to the tag of the trigger the bot should use to control this lift.

There are two other configurable LiftCenter attributes of interest. These should be modified only if absolutely necessary. MaxZDiffAdd, which defaults to 0, specifies an additional allowable difference in height between the bot and the LiftCenter for the bot to consider that LiftCenter reachable. This is useful if the bot must stand below the lift (down stairs or a ramp) while waiting for it. MaxDist2D is the maximum distance between the bot and the LiftCenter. It defaults to 400 world units.

NavigationPoint Attributes

The only configurable NavigationPoint attribute that should be modified is bOneWayPath. bOneWayPath can be set to true so that paths will only be valid in the direction the NavigationPoint is facing. Turn on the bDirectional attribute of the NavigationPoint to adjust the direction it faces.

Special Purpose NavigationPoints

Several special purpose NavigationPoints exist to provide tactical or game specific positions or to provide support for special movement modes such as using translocators and jumpboots. Game specific NavigationPoints will be described in the section of this document devoted to that game type.

PlayerStarts specify allowed spawning locations for players and bots. There are two relevant configurable attributes in PlayerStarts. The TeamNumber attribute specifies which team is allowed to spawn at that PlayerStart in teamgames where team specific PlayerStarts are enforced. The bEnabled attribute, which is true by default, can be toggled to enable or disable the PlayerStart by triggering the PlayerStart.

AmbushPoints are used to specify good camping spots. They are directional and should be pointed in the direction the bot should be looking while using that AmbushPoint. AmbushPoints have two configurable attributes, SightRadius and bSniping. SightRadius specifies how far out the bot should be looking for enemies when camped at the AmbushPoint. bSniping specifies that bots using this ambushpoint should stay at this point and snipe after acquiring an enemy, rather than chasing after the enemy.

DefensePoints are a subclass of AmbushPoint used in team games. DefensePoints have three additional configurable attributes, Team, Priority, and FortTag. The Team attribute specifies which team should use this defensepoint (0=Red, 1=Blue, 2=Green, 3=Gold). The Priority attribute is used in team games to determine which DefensePoints will be manned first (higher priorities are manned earlier). The FortTag attribute is used in Assault games to associate a defensepoint with a particular FortStandard.

BlockedPaths are used to keep bots from attempting to follow routes which are initially blocked (such as a bridge which must be lowered). . When triggered, the BlockedPath is unblocked. Once unblocked, a BlockedPath cannot be re-blocked. If using a BlockedPath, make sure that there aren't any path connections which bypass the BlockedPath and render it useless. AS-Mazon has some good examples of the use of BlockedPaths.

TranslocDests are a special type of LiftCenter which are not associated with a mover. TranslocDests are used to define places that bots can use a translocator to cut a route short. A lifttexit should be placed at the spot where the bot should stand a use his translocator, and a TranslocDest should be placed where the Translocator Target should be thrown. Another liftexit should be placed near the TranslocDest, as an "exit" from this "lift". The LiftExits and the TranslocDest should be given the same LiftTag.

Bots will assume that any LiftExit with the same LiftTag as a TranslocDest can be directly reached from the TranslocDest, without any special action on the bot's part. If the bot must use the translocator to get from the TranslocDest to one of the LiftExits, replace that LiftExit with a TranslocStart.

JumpSpots are similar to TranslocDests, and are also placed in conjunction with LiftExits all given the same LiftTag. Bots understand that in low gravity areas, or in JumpMatch, or if they have JumpBoots, they can also jump to reach JumpSpots. In addition, if the bImpactJump attribute of the JumpSpot is true, higher skill bots will impact jump (using the impact hammer) to reach the JumpSpot. If the bAlwaysAccel attribute is true, bots will use air control to reach the JumpSpot (try this only if they are failing without it).

Teleporters send any pawn which touches them instantly to their destination teleporter, as specified by their URL attribute. If the URL attribute is empty, the teleporter acts only as a teleporter destination. If it contains the same string as the tag of another teleporter in the level, that teleporter will be the destination. If it contains a string in the form of LevelName/TeleporterName, it will teleport to a different level on this server (single player only). If it contains a string in the form of Unreal://Server.domain.com/LevelName/TeleporterName, it will teleport to a different server on the net.

If a teleporter's bEnabled attribute is false, then it will not teleport pawns which touch it, although it can still act as a teleporter destination. The bEnabled attribute is toggled by triggering the teleporter. If the bChangesYaw attribute is true, pawns arriving at this teleporter will have their yaw changed to the teleporter's yaw. If the bChangesVelocity attribute is true, pawns arriving at this teleporter will have their velocity set to the teleporter's TargetVelocity.

Tweaking and Debugging the Navigation Network

After placing and "defining" the navigation network, the level designed should tweak and debug it by watching bots play the level. The designer should the game as a spectator, and add first one and then later several bots to the level. The designer can watch them play, advancing through the bot cameras using the fire button, and looking for problem areas. If the bot currently being viewed seems to be acting strangely, using the console command verbose will indicate what it is thinking. After the play session, reviewing the log file may also provide insight to problems.

If the bots don't seem to understand how to get to a certain destination, the designer can use the rememberspot and showpath console commands to look for breaks in the navigation network. When the rememberspot command is used, the current location is saved. Subsequent showpath commands will cause the best visible NavigationPoint on the path to the remembered location to become visible. If no NavigationPoint becomes visible, there is no valid path to the remembered location.

If a player cannot fit in the position specified by a PlayerStart, then the player cannot properly enter the game and will either wander as a spectator or the game will crash. The log file for that play session will have information on which PlayerStart caused the failure.

My Notes: Default PathNode seems a bit too tall - it's confirmed in a bunch of ramps and as doument is describing they have to be manually moved lower. We can see recommendations of 350 UU in ramps. I think this is less true. Nodes placed correctly can go up to 500 - 600 UU in Ramps with 0 problems - and good things are visible with smaller Navigation stuff.

[Higor]

FerBotz developer here, if that works at all credential...
Apply these guidelines above whatever tutorials say:
- Maximize distance between nodes if possible.
- Single route on narrow paths.
- Consider Inventory as paths.
- When rebuilding paths, open default properties of InventorySpot and slightly reduce their CollisionHeight/CollisionRadius defaults (don't save) and hit rebuild, you'll get more appropiate InventorySpot actors.
- Obtain XC_Siege_r3 and take a look at the classes (and sources), you'll find interesting stuff.

[Dr.Flay]

I will reinforce something that often slips by.
As Higor says, Inventory will become a path node, but it is important that you do not break the pathing when an item is picked up.
Bots will not navigate the gap until the item respawns. There must always be an alternative route.
This is a common reason to find bots going into a room and not being able to leave.

[Hellkeeper]

As Higor says, Inventory will become a path node, but it is important that you do not break the pathing when an item is picked up.
Bots will not navigate the gap until the item respawns. There must always be an alternative route.
This is a common reason to find bots going into a room and not being able to leave.

I'm almost 100% sure this is wrong. I could not swear it, but it's completely untrue in UT2003/2004 and none of my test has ever shown anything like this. As far as I know, InventorySpots are not removed when the item it was placed for is unavailable, and thankfully so, as many maps would then be entirely unplayable in Instagib where no item is present.

A quick test map seems to validate this:



In this situation, both bots spawn, pick up the flak, run to their only pathnode and then fight for the ripper. When one of them dies, he respawns at one end of the map, he should be stuck if the flak cannon is unavailable as its InventorySpot is the only path point in view of the PlayerStart, the pathnode being out of reach (both out of view AND too far away to link). Instead, the bot moves to the flak's location, runs up to the pathnode and then to where the ripper should be. If one bot is at one end of the map and the other bot is at the other end and none of the weapons are available, they have no trouble at all navigating the map, even though the path should then broken in three places without weapons. This happens even if the bots have no opportunity to see each other, which proves that they are not moving just because they saw an enemy.

TL;DR: I'm pretty sure bots navigate using the InventorySpots even when weapons are unavailable. If they have trouble getting out of the room, it's probably because the path network has flaws.

[Wormbo]

InventorySpots are automatically placed at pickup location when building paths and AFAIK there's nothing that marks them "blocked" or anything. InventorySpots are bStatic like about all other NavigationPoints, so they can't disappear at runtime either.

The thing about InventorySpots is that for some reason they are marked as bEndPointOnly, which apparently means the AI should only use them as a destination, not a source. The reason bots find back from pickup locations probably is that they simply pick another NavigationPoint in sight to start their route from. With that in mind, it's probably a good idea to ensure there's always a route that doesn't have to use InventorySpots.

[sektor2111]

With that in mind, it's probably a good idea to ensure there's always a route that doesn't have to use InventorySpots.

Hehe, I cannot recall how many times I was using ammo and health as routes in MH and they were working with 0 troubles, including in debugging paths they were granted at human tester properly...

I will reinforce something that often slips by.
As Higor says, Inventory will become a path node, but it is important that you do not break the pathing when an item is picked up.
Bots will not navigate the gap until the item respawns. There must always be an alternative route.
This is a common reason to find bots going into a room and not being able to leave.

UNTRUE - you (and anyone who thinks that navigation can be broken without a crash) might check CTF-BoomBoomBridge and see how paths are going through Health which even is taken up path is still there else NONE will move for Flags for a period (Don't ask me about those lifts, lol) - validated with my NsCTF where path to enemy-flag is shown for human at request (feature added for wild maps less known). Is the second time when I see the same wrong thing posted. Stop blabbering PathNodes over weapons. In DM if Bot won't get that route it's because Item is missing (until respawn) BOT IS A COLLECTOR. Try to see how works BotyMan2 - will never drive you where item is missing but you can use a RememberSpot all the time to track that route going through items as an alternate destination point. If map pathing works, ALWAYS exist routes through InventorySpots if they have more than one connections to another ANY (oops me except child of LiftCenter which are always linked only with at LEAST 2 LIFTEXITS) NavigationPoint.
And now the crash (console):
- set NavigationPoint bStatic 0;
- killall NavigationPoint;
- rememberspot - step away 2000 UU;
- showPath - BANG !!! K.O.
- Still alive ? OKAY <addbots 3> Enjoy !

I'm interested which tutorials are describing those lies about InventorySpots - I have a hammer prepared for author's head (I'm sorry but it's annoying to send bad informations for people which wants the truth). These kinda "tutorials" are good to be deleted and HDD erased bit by bit. Else, this proves you did not read previous spoiler which is a copy from a Document originally written by POLGE himself not by idiots like me.

Excuse me but now I'm busy to fix exactly these kind of "paths" stucking Bot and making game a 0 challenge mess.

Edit: Completing asumptions
Bot has came in room and won't leave, it's because of bad pathing, or this is doable purposedly as follows:
- Bot coming from a higher position falling 200 UU - for road back it needs Fly flag which doesn't exist = GOOD BYE return;
- Bot is coming from a bOneWayPath - No permission granted for return = GOOD BYE;
- Wrong Land/Water link - (oops I was almost to give a bad example properly spread by a Green dude and other pathing lulus done by the same person from here - we don't need to be very evilized after all ). Bot goes in water for some reason (Inventory instant love) but Navigation directives (physics recommended) cannot be completed due to Nodes placement at way back (swim/fly/run soup), so Good Night at bottom of sea;
- Custom evilized trap. A trigger will lock a way-back Node if Bot is in range - just because as a nasty madness - yes this is doable too by setting up that point at cost 1000000 and Good night.

The problem of this Engine (guess deduction) is that it uses a sort CPU CYCLES or whatever they might be - counted. When Engine uses too many Cycles, that is considered a way expensive process and will return NONE. As Higor said, use high distances as much as possible.

[Dr.Flay]

Being an end destination combined with crappy pathing would explain it.
I certainly started pathing by including the pickups, but I guess I have edited too many borked maps for too long (I should just delete them all and start fresh).
Thanks for putting me straight
When I find maps with bots getting stuck in rooms but the path is not red, I usually just move or add a node.
Most often it is red pathed because the door is too narrow or there is a BSP problem.

[sektor2111]

I just had to clarify this Inventory MYTH using this pathing thread, because is a myth after all - I worked more hours to fix this mess based POOR experience with Bot after all. Like I said, I wouldn't be an amnesic idiot I could remember exactly a map where you could see Bot playing well but having... only inventories and 0 Pathnodes - read again - 0 PathNodes. Can you believe then ?

Then about that EndPoint ? I think that is for engine's internal in computing the build or some precache sequence. I asure you, if an item (ammo) is exactly in the way of attack BOT / PAWN (read well - PAWN) will see the way through item. InstaGib removing items won't make Assault or CTF or DOM to not work. Like I said don't be fooled by myths written here and there.

CHECK twice Polge's words

PathNodes should not be placed more than 700 units apart. Since PlayerStarts and Inventory will be placed on the navigation network, the designer can (and should) not place PathNodes where these other NavigationPoints can substitute.

However if we want to debate real issues.
At a moment a red path... is simply red being too close from a wall, and then if Bot has 3 blue paths and 1 red path heading to an item many times will attack that red path. I'm saying "attack" because we might have problems - again a known DM with some RocketLauncher driving to a lower pathnode and path was passing very nearby a wall was making Bot to permanent avoid Wall retrying forever to pass. Issue coming from bAvoidLedges + HitWall which seems better ignored in state hunting NOT in roaming.
That map used for an 1on1 match is simply too dumb even for servers build for noobs only, Bot stucked there is an easy target - I'll try to recall the name. Of course is not for deletion, it's fixable.
So you have to avoid red paths nearby wall-corners driving a way-down.

Ramp issues: Simply occurs if Bot reaching on a ramp Node having the same X Y coordonates cannot touch the center of Pathnode by running normally - PathNode has 50 UU height which is dumb for heavy ramps given Bot's Height (a puppy trying to get milk from a Cow) - best example CTF-Command - an original <How TO NOT EVER DO>.