Pathfinding troubleshooting

[Springheel]

I'm having some frustration with pathfinding.

 

I've got two problems cropping up:

 

1. AI acting like they can't move forward any further. I have two AI walking down a road, and at a certain point them just stop. I pop out right in front of them, and they refuse to move, instead throwing rocks at me (which tells me that it's not a path_corner problem). Yet an AI that is behind them runs right up to me without any problem at all (which suggests that there's nothing wrong with the actual terrain). Is there any kind of troubleshooting tools that can help me figure out what's wrong? I've tried binding a key to show the aas areas, but I don't really know how to interpret what I'm looking at. What can cause some AI to be unable to reach me but others can?

 

2. AI circle around pathnodes. I have two AI following each other. Sometimes when the lead AI reaches his pathnode, he walks around it in a circle before continuing. I've put a move_to_position_tolerence of 8 on them, but he still does it sometimes. Since the player is supposed to be following these AI, having them suddenly spin around in a circle is less than ideal. Is this a common problem?

[Sotha]

I got some pathing issues in KM, which were fixed by checking nearby VPs were snugly against the walls, and that no worldspawn brushes penetrated any portals. In my case I had a monsterclip brush that intersected with a VP. Removing the intersections everything worked again.

 

The symptoms were weird pathing. AI could run after me through a VP in one direction, but not in the other.

 

1. You could alert the AI and run away and around the problematic area. Try to identify some area the AI has issues with. Maybe there are some accidental monsterclipping or something in there. If there are VPs nearby, investigate thorought that the portal fits snugly and the no worldspawn brush intersects them. Func_statics have no effect.

 

2. move_to_position_tolerance may cause AI not hit the the path node. Maybe you should remove the spawnarg, so it is not so accurate how the AI hits the node?

[RJFerret]

Are they traversing irregular terrain of patches?

 

(Or are the nodes more than half the AAS width away from monsterclip? IE, 16 units away for regular people.)

Edited February 11, 2014 by RJFerret

[Springheel]

There are irregular patches, so I'm trying to coat the area underneath with monsterclip. Though it's weird that one AI was able to run at me fine, and the two AI have pathed through the area before without problem.

 

 

 

2. move_to_position_tolerance may cause AI not hit the the path node. Maybe you should remove the spawnarg, so it is not so accurate how the AI hits the node?

 

I thought the point of that spawnarg was that AI did NOT have to hit the pathnode? Am I using it wrong? I thought it made a bigger 'zone' around the pathnode so AI would consider it 'hit' from further away.

 

If there are VPs nearby, investigate thorought that the portal fits snugly and the no worldspawn brush intersects them. Func_statics have no effect.

 

There is a portal nearby, and it probably is intersected by monsterclip brushes...can that cause problems for some AI but not others? Can I fix that by just clipping the brushes in half at the visportal location?

[Sotha]

There are irregular patches, so I'm trying to coat the area underneath with monsterclip. Though it's weird that one AI was able to run at me fine, and the two AI have pathed through the area before without problem.

 

Yep, this can cause AI to make sudden loops when they feel they are getting too far away from the patch.

 

 

 

I thought the point of that spawnarg was that AI did NOT have to hit the pathnode? Am I using it wrong? I thought it made a bigger 'zone' around the pathnode so AI would consider it 'hit' from further away.

 

I think the smaller the value, the more accurately the AI gotta hit the node. At least a move_to_position_tolerance of 8 hits more accurately the position with the lean animation, where as a "-" for that spawnarg is less accurate.

 

There is a portal nearby, and it probably is intersected by monsterclip brushes...can that cause problems for some AI but not others? Can I fix that by just clipping the brushes in half at the visportal location?

 

For me, the VP that was intersected by monsterclip caused strange problems until I fixed it. It seemed like the VP was sometimes a solid wall for AI and sometimes not. I never had pathing issues around VPs once I started using snugly fitting VPs that are never intersected by worldspawn brushes, ie. monsterclip. You can easily avoid clipping a VP with monsterclip, just cut the monsterclip brushes so that no portion of it clips with the VPs. Remember to re-apply the monsterclip texture to the whole brushes, clipper tool substitutes cut areas with caulk, which prolly breaks the monsterclip brushes if you forget the caulk on them.

[RJFerret]

Yeah, all your symptoms were patch-pathing-like. It's not weird one would chase you but not path there, it's been said before those are two different processes, the chasing is more tolerant of irregularities. It also matters what exact unit you are on and they are on, it's like you are stepping inside monsterclip when the spot you are on is too high, then out of it again if you move. Meanwhile, another AI might perceive the path between you differently since it's approach is different. That was my experience obviously dealing with an excessive amount of this in my FM.

 

Closer monsterclip underneath (terraced) will completely resolve it, I use a height of 8 simply because grid height makes it quicker than using the 14 or whatever the wiki suggests works for many AI (and I want it to work for all AI without adjustment) and allows me to tweak the patch height in the future.

 

To use position tolerance for broader tolerance, you'd have to use values greater than 16 (for a 32 AAS entity). Is it DR or the wiki that says the AI bounding box is used otherwise? Values smaller than 16 are requiring the AI get closer (and prompt more circling typically), useful for sitting, sleeping and urinating setups--I typically use a value of two then to avoid sitting in chair arms, or heads in walls, or feet through bed foot boards.

 

Apologies for the animated gif, but it applies, I wish I'd put a snow texture instead of grass to highlight the contours though:

Edited February 11, 2014 by RJFerret

[Obsttorte]

Regarding "move_to_position_tolerance": Every now and than, most definetely every frame, the ai checks how far it is away from the point he wants to reach, for example a path node. If the distance is smaller then the tolerance, he continues on his way. This means that increasing the tolerance allows the ai to continue on its path without having to get too close to the last target. Therefore it has the potential of decreasing possible pathfinding issues. So Springheel interpreted that spawnarg completely right. It's one possibility to solve the circling ai issue. The more common one is to make sure that path corners are far away enough from any worldspawn or clip textures.

 

Regarding your problem: I don't know the map, but RJFerret's suggestion sounds logical to me. The two ai that are hung up already may wanna use a different way to get to you then the third guy. So it is possible that the aas data tells them, that they have to move forward, but they get hung up on the geometry. But I guess the geometry must be really bumpy to make this happening.

 

Monsterclip and Visportals intersecting with each other sounds a bit weird to me, as they have basically nothing to do with each other, but I may be wrong. I guess grayman will know this best.

 

Regarding the AAS areas: AAS are Axis-Aligned rectangulars, which normal points into the z-direction. They tell the ai where it can move on. If the ai is within one aas area and its target is in another one, it uses the aas system to find the shortest way towards its goal. The aas areas can therefore be interpreted as some sort of 2D representation of your 3D level, containing only the information needed for ai movement. The bumpiness of possible underlying patches and func_statics is not part of that information.

 

The colored rectangles you see with the specific keybind are those areas. Areas in the same leaf have the same color. As the leafs are defined via the visportals this may be the connection between both of them. I don't know.

[grayman]

When a destination point is inside the AI's bounding box (which is 32x32xheight), the AI has arrived at the point. "move_to_position_tolerance" adds its value to the xy size of the bounding box. So a value of 8 changes the default 32x32 to 40x40.

 

Monsterclip and Visportals intersecting: both set boundaries for AAS areas. I don't know whether intersection creates a different AAS pattern. I'd have to experiment with that. I wouldn't expect it to. And splitting monsterclip at the visportal plane should have no effect.

 

When you look at AAS areas in the game, the white rectangles represent visportals.

[RJFerret]

When a destination point is inside the AI's bounding box (which is 32x32xheight), the AI has arrived at the point. "move_to_position_tolerance" adds its value to the xy size of the bounding box. So a value of 8 changes the default 32x32 to 40x40.

 

Curious, this doesn't match observed in game behavior (the DR description makes it sound exclusive of bounding box). (Disable it, AI will miss their chair by half a body width, make it 1, AI hit the same spot on the chair no matter which direction they approach.)

 

This also indicates you'd need -14 to tighten an AI to a point, but the DR description indicates -1 to default to the bounding box.

[Sotha]

There is something really strange going on with move_to_position_tolerance (mtpt).

 

I made an anim where the AI leans against a wall, so the AI positioning is very important.

 

If I have mtpt of default "-" the AI hits the path_node before the path_anim inaccurately. His back does not hit the wall and the position he is in is very dependent on the direction he arrived.

 

If I have a mtpt of 8, the AI hits accurately the area. His back just touches the wall like it was designed in the animation.

 

Is the mtpt really working like it should? My experience is in contrast with grayman's explanation how it works.

[SteveL]

I did quite a few tests on some similar broken pathing in a recent thread. When you watch the odd behavior with aas boxes drawn, do you find that they're refusing to cross or enter an aas box? If so try what fixed it for me: add an extra bit of clip in the middle of the offending aas box to break it up.

 

AI seem quite tolerant of a big gap between the patch and the clip. They won't climb a step of more than 14, but they'll happily path over clip that's 20-30 units below the walkable surface.

 

All 10 of my exterior portals fully intersect the clip layer below. No issues to report there.

 

[grayman]

My experience is in contrast with grayman's explanation how it works.

 

grayman must have been sucking down some homemade mountain juice when he said that.

 

This is grayman's evil twin talking, and I'm here to tell you that if you set accuracy to 8, a bounding box of 16x16 is used. You set it to 1, you get 2x2.

 

You do run a risk when using smaller bounding boxes, though. If something gets in the way, and keeps the arrival check from being successful, you could get weird results.

 

I'm going away now to give grayman a well-deserved thrashing, and suggest he take a course in how to read code. Bloody idiot!

[Sotha]

grayman must have been sucking down some homemade mountain juice when he said that.

 

This is grayman's evil twin talking, and I'm here to tell you that if you set accuracy to 8, a bounding box of 8x8 is used. You set it to 1, you get 1x1.

 

You do run a risk when using smaller bounding boxes, though. If something gets in the way, and keeps the arrival check from being successful, you could get weird results.

 

I'm going away now to give grayman a well-deserved thrashing, and suggest he take a course in how to read code. Bloody idiot!

 

The humorous style the message is written makes me confused.

 

Is message sarcasm based on my incorrect perceptions, or a humorous validation of my observations? I can see it meaning both.

 

Was I right or not? How does the mtpt work really?

 

At any rate, evil twin, just don't be too harsh on grayman, mmkay?

[RJFerret]

Humorous confirmation that it works as observed, setting the bounding box to the stipulated size. :-)

[grayman]

Is message sarcasm based on my incorrect perceptions, or a humorous validation of my observations? I can see it meaning both.

 

Sorry, nothing to do with you, Sotha.

 

It was just my attempted humorous way of publicly flogging myself for not reading the code correctly yesterday.

[Springheel]

Ok, so what values should I use if I want to create a larger than normal box? The pathnodes are in the middle of the street and I don't much care if they hit them accurately at all...I just want them to keep going.

[grayman]

Default is 32x32.

 

A larger box of 40x40 would need the accuracy set to 20.

 

An even larger box of 64x64 would need the accuracy set to 32.

 

So whatever number N you give it, you get a bounding box check of 2Nx2N.

[Springheel]

Ah, so I've actually been making the problem worse by using a value of 8. Good to know, thanks.