Ai Path Question

[buck28]

Can two AI's use the same Path Corners? Like when you have two patrolling guards on a long patrol route, at different time intervals?

I've been searching but can't find the answer.

[Sotha]

Yes, of course. Many AI can patrol along the same route. This is very handy in RITs for example.

 

The only limit is the corridor/route space, and it would look silly if you had too many AIs walking the same route.

[grayman]

Can two AI's use the same Path Corners? Like when you have two patrolling guards on a long patrol route, at different time intervals?

I've been searching but can't find the answer.

 

Not really. You can point the prior individual path_corners to the same path_corner (call it A), but both AI are then going to go where A points to. The only chance you have of sometimes having two AI leave A for different path_corners is to have A point to 2 path_corners. When an AI reaches A, he'll have a 50% chance of going to either p_c. This gives you a 1/3 chance that the AI will go to different p_c's, a 2/3 chance they'll both go to the same p_c (be it the first or second p_c).

[grayman]

Yes, of course. Many AI can patrol along the same route. This is very handy in RITs for example.

 

The only limit is the corridor/route space, and it would look silly if you had too many AIs walking the same route.

 

I assumed the question was whether two different routes could share the same p_c at some point where the routes crossed. My answer is based on that.

[Springheel]

Just be careful about having AI stopping on the same path node...it can result in AI standing inside each other if they both try to stand/sit in the same spot at the same time.

[RJFerret]

Just be careful about having AI stopping on the same path node...it can result in AI standing inside each other if they both try to stand/sit in the same spot at the same time.

 

I imagine sitting would be a problem, but I have two following together in Inn Business who end up standing next to each other when they wait. I didn't adjust the position tolerance either, they just happily do it naturally without problems.

 

The only chance you have of sometimes having two AI leave A for different path_corners is to have A point to 2 path_corners.

.

With a new feature in the upcoming 2.02, you could have a path_corner be "switching", constantly alternating between two different destination paths instead of having multiple random targets.

 

This would be done by having the next path node trigger a change target for the switching path node to set it the other way. And same for that other way, it would set it back.

 

This'll come in handy in the future to prevent the random aspect of pathing causing AI to do the same thing each time (or never take a certain path for that play of the map). For example, if you had an AI enter an office and randomly go to either the desk, bookshelf, sit with wine, or look at mirror/painting, you could remove whichever one is being done. Then when the final remaining behavior is used, replenish the list.

 

This would add much more variety than the completely random way typically used now.

[buck28]

Thanks guys. Appreciate the info...

[demagogue]

In my experience, the best thing to do in this situation is to just use a second path node a few feet away from the first.

[buck28]

Well. I have used the models/darkmod/architecture/stairs/mansion_stairs_01.lwo, and my Ai refuses to go near it??? It says it is a func static. Do I need to add a spawnarg to it so that the Pathcorners will work for the Ai to climb and descend the staircase? Right now they stop short and wait, then go back to were they started? Completely avoiding the staircase as if it had the pocks. Hopefully I can use this staircase as my map is built around it.

Edited June 22, 2014 by buck28

[Sotha]

AI's are completely oblivious of func_statics. They cannot walk on them. They only can walk on wordspawn brushes.

 

You must build an overlapping WORLDSPAWN geometry on your func_static stairs.

 

You have two choices.

1) Place monsterclip brushes inside the steps. That works too, but you must make the monsterclip steps smaller than the model steps. The AI must really step on the wooden step, rather than on monsterclip, because I don't think monsterclip has any material footstep sound. The monsterclip is only there to tell the AI the area is traversable.

 

or

 

2) Pick common/tdm_nodrawsolid_* with a material that matches your stairs. So if you have a wooden stairs, then use tdm_nodrawsolid_wood. Then build invisible but solid stairs onto the model stairs.

[Springheel]

With a new feature in the upcoming 2.02, you could have a path_corner be "switching", constantly alternating between two different destination paths instead of having multiple random targets.

 

Cool! I either missed this or completely forgot about it.

[SteveL]

@buck28: NB with either of Sotha's suggestions, you don't need to be precise with the monsterclip steps: You can just make a ramp roughly below the stairs if you want, say within 30-40 units vertically. It's just there to help the AI work out how to get from A to B. They'll walk on your model steps and other FSs as long as there's worldspawn not too far below so they can "see" the path.

[buck28]

@Sotha

 

Hmmmm. I see a feature when the steps are highlighted, and I right click, as if to create an entity; it says surround with Monster clip. Will that work??? Or can you turn a func static into worldspawn???

[buck28]

@SteveL

 

Thanks much. I'll give it a go and see what happens....

 

 

 

I put in 4 ramps of Monster clip, and my Ai walks his route like he's getting paid too. LOL

Thanks very much. I appreciate everyone's help.

Edited June 22, 2014 by buck28

[Sotha]

@Sotha

 

Hmmmm. I see a feature when the steps are highlighted, and I right click, as if to create an entity; it says surround with Monster clip. Will that work??? Or can you turn a func static into worldspawn???

 

Yep, if you turn the steps into worldspawn the AI can walk on it. No need to monsterclip (except the handrails.)

[RJFerret]

Cool! I either missed this or completely forgot about it.

 

It's something I realized we could readily do now by virtue of...oh wait, the wiki page list of changes doesn't include it...and the tracker issue name doesn't explain it, but I linked to the comment which does, "0003670: [Design/Coding] "Trigger" spawnarg on path nodes improper (grayman) - resolved."

 

But not to worry, I've already written a forum post, all ready to copy/paste when 2.02 is released, to more broadly bring it to the attention of mappers.