AI uses elevator up, but not down

[PranQster]

I have an AI which uses an elevator to reach his path on a second floor. I put an aas32_flood on that floor to get it to work. I made a path back to his starting point as well (I tried with fewer path_corners for his return and also with the same amount, spaced the same). He does not use the elevator to return to the first floor though. I even tried putting an aas flood on the lower floor to help him, but no luck. Elevator call buttons have enough room around them. But still, the AI just walks between it's last 2 path corners on the second floor.

What might I have done wrong, and how can I coax him to use the elevator again?

[grayman]

It sounds like you have what you need to make this work.

 

All I can think of is a problem with the elevator itself.

 

Can the player go up and down the elevator correctly?

[PranQster]

Yeah, the elevator works great. It's the 3-floor prefab one. All buttons work, including the call buttons. Could a visportal interfere if it is between floors with the nodraw side facing down (visportal texture facing up)? <<< ignore that, I had not put them there.

I have triple-checked my path targeting to make sure the path is not broken. The return path corners are sitting right next to the path corners of the initial path. The AI goes through the path, up the elevator and then to the last path corner and path wait before going to the next path corner, which is the first in the return path. But he stands at that path corner by the elevator, as though there was a path wait there. Then he turns around and walks to the previous path corner and path wait.... he just goes between 2 corners, waiting at each one (even though only one of those corners is targeted at a wait.

Edited May 19, 2011 by PranQster

[stumpy]

maybe the temporary on/off aas_32 brush is missing from the top elevator position, and the ai cant get on the elevator because the pathfinding says there's a deep shaft there.

[Fidcal]

I remember the same problem in Chalice of Kings even when I blocked off the stairs with stone (AI always currently choose to walk if it's possible which is why they don't use the elevator in Outpost too.) I recall testing the original test map and that worked OK yet I was certain I had it set up correctly in Chalice but he never would come down and I didn't have time to do more on it (we were preparing to release TDM1)

 

Sorry I've not time to experiment with this but I can only suggest you make an ultra simple test map and insert the prefab. I don't know if our test map was ever made public. I could check that again. You see what I generally do with faults like this is find a working version and gradually modify it to do what I want until it breaks. The point where it breaks should indicate the problem. If it doesn't break then I use the new version.

[grayman]

When I began testing interleaved thinking with an elevator, I found that the test elevator map has the same problem. The AI would take the elevator to the top, but not come down.

 

I never investigated this, because my own test map with an interleaved-thinking AI using the prefab elevator worked fine.

 

The reason your AI waits at both path_corners up top is because when he can't reach the next path corner, he'll still do what the "non-walking" path* entities tell him to do. So if there's a path_wait on the path_corner at the bottom, he'll see it and do what it says. This behavior can also be seen when AI decide to sit down in the middle of nowhere; they're executing the sitting instructions parked next to the chair they're supposed to be sitting on, elsewhere in the map.

[PranQster]

Cool. Thanks guys. I'll tinker with it in my 'workshop' map until I either fix it, or decide a different plan of action for the AI. I might build a new elevator from scratch and see if I get different results than with the prefab, and then apply the change to the 3-story elevator.

If I can make it work with a simple 2-story elevator but not the 3-floor, then I may just end up using 2 'lifts' side by side with the second floor being common to both of them. I may do that anyway now that I think about it.

Progress is being made, all objectives are in place (and satisfactory at the least) and the mission is very playable. Now it is down to mostly making an intro and work on aesthetics, audio, details and making it more challenging. I promise some interesting and unique things and, hopefully, generating some smiles (and more successfully than my horse poop fiasco).

 

I'll also test it with a different AI. Maybe the commoner I'm using is a bit dim. LOL

Edited May 19, 2011 by PranQster

[PranQster]

Aha!

It would seem, and it makes sense, that the AI won't make proper use of the elevators if the floors are not completely sealed from each other. Like if there was a lover floor with a loft/balcony above which is open to the lower floor, the AI can't do the proper pathfinding.

That is the problem I have in my map is a portion of the second floor which has a balcony-like area looking down upon the lower floor.

My workshop map has nothing but one platform, floating in space with a big brush room around it. I was only using it to test models and prefabs and to build things without the clutter of my main map.

I added the elevator prefab and cloned the first platform for a second floor. The AI did nothing but pace on the first floor. I slapped up a third floor, walls and a ceiling... and presto, the AI used the elevator both up and down.

I'm hoping not to have to isolate my second floor balcony area with a solid brush... I kind of want a possible rope repel option from that area, but I'll experiment with non-solid brushes... perhaps monster_clip will be enough to remove the confusion from the AI.

[PranQster]

Fixed!

It wasn't the open area to blame. I had tried closing it, even with solid wood textured brush, and the AI still didn't use the elevator going down.

What did the trick was to remove the visportals I had placed in front of each elevator level opening. Strange that the AI would use the elevator even one way since no matter which way he was going, he'd approach the nodraw side of the visportal first when entering the elevator. I figured that if he could use the elevator up that the visportals were not the problem.

[Fidcal]

Sounds like a good find although I don't see why the AI wouldn't go through a visportal in this case. However we know that sometimes they won't so maybe that applies here.

 

I can't remember in Chalice but maybe it's the same problem. I think I have at least one horizontal visportal in the shaft.

 

It seems there is no bug with the elevator but it's just one of the old pathing difficulties.

[PranQster]

Sounds like a good find although I don't see why the AI wouldn't go through a visportal in this case. However we know that sometimes they won't so maybe that applies here.

 

I can't remember in Chalice but maybe it's the same problem. I think I have at least one horizontal visportal in the shaft.

On one of my earlier attempts to fix it I had removed only the visportal on floor 2. The AI still use the elevator up but not down. Since the visportal surface was facing the elevator shaft on both visportals, I figured the AI would have no trouble with the visportal on the lower floor because he had navigated through both to get to the upper floor. Because of this I had ignored the visportals while trying to fix the problem and had not tried removing both at the same time.

 

It seems there is no bug with the elevator but it's just one of the old pathing difficulties.

It's a pretty good elevator. I'll probably make my own custom call buttons for it but the rest of it works for me with just an mild adjustment of the brick textures.

[grayman]

The orientation of the visportal face shouldn't matter. Dmap only considers the face with the vp texture on it, and discards the remaining faces. One bug we found, though, was that if any of those discarded faces use a texture other than a nodraw, the AI won't go through the vp. You need to be careful when clipping visportals, because DR paints the cut faces with caulk by default, which will cause the problem.

[PranQster]

The orientation of the visportal face shouldn't matter. Dmap only considers the face with the vp texture on it, and discards the remaining faces. One bug we found, though, was that if any of those discarded faces use a texture other than a nodraw, the AI won't go through the vp. You need to be careful when clipping visportals, because DR paints the cut faces with caulk by default, which will cause the problem.

 

Good to know about the other faces being discarded in dmap. These visportals had not been clipped either. When needed, I resize visportals by dragging their edges rather than clipping to avoid exactly that. These were brushes created to exact fit and then done with 'make visportal' from the right mouse context menu. But yes, I had experienced the clipped brush caulk texture elsewhere and am used to re-texturing the clipped faces.