grayman

Oh, I forgot: 5) Idle animations are turned off when an AI enters a door-opening or door-closing stage. Watching numerous arm-stretch or eating animations while a door is magically opening or closing drove me to make this change.

I agree. It's serendipity when a Noble is waiting on a door queue and a Pagan walks through the door. The Noble says "Move along, there." And the Pagan replies, "Yes, Sir." Some 'impatient' comments specific to door queues would be good to have. Especially for the upper class.

I hadn't considered auto-closing doors. I'll have to look at the code to see how they behave when there's a door queue. I might need to change something. Edit: On second thought, since the door can't be aware of who's using it, it's going to close regardless of whether anyone's walking through the doorway or not. Or perhaps the Inventors Guild sells motion detectors?

Good suggestion for 1.05. Thanks. I was considering adding a 50% chance of closure, but it would be just one more change too close to code freeze, and I opted to do it later. I'll replace it with your suggestion. There are a number of other things that came out of a discussion on another thread. Once 1.04 is released, I'll post a list and we can decide which ones we want.

The third round of movement changes is now in SVN. Source rev is 4540. The rev 11558 version of tdm_game01.pk4 has the Windows DLL. The 1.03 DLL isn't ready yet. It will be a couple hours before that's available. This round includes: 1. Fidcal's suggestion that AI walk away from a door queue if some time has passed. They'll return to their previous path_corner, then continue their patrol from there. They'll leave the queue 10-15s after joining. (Thanks for this; it helps keep them out of trouble.) 2. AI now close doors if they're the last one through, regardless of whether the door was initially found open or not. This helps with performance, though it might bother players who leave doors open on purpose to mark where they've been. 3. If an AI arriving at a door is very close to the door (perhaps he just walked around a corner and found the door), and he has to join a door queue, he will step away from the door to make more room. 4. AI who get pinned to the wall behind an opening door will now close the door to free themselves, if they're unable to find a way around the door first. Edit: 5. Idle animations are turned off when an AI enters a door-opening or door-closing stage. Watching numerous arm-stretch or eating animations while a door is magically opening or closing drove me to make this change. Please test. 1.04 is scheduled to enter code freeze Saturday. If you see any AI getting stuck and staying that way for more than 20s, please write up a detailed description of the circumstances and post it here. Thanks!

Actually, they're hot.

I have "leave a door queue and go back the way I came" working. I also made a couple other minor changes today and will release a new DLL sometime tomorrow.

Possibly. Since they are jostled about in close quarters, they're turning and stopping and taking short steps. These actions probably weren't anticipated by the animation designers.

Yes, I saw that last week when searching for AI pathfinding methods. Interesting stuff. AAS is similar to a navigation mesh, but id uses rectangular areas rather than triangular. I'm suspecting some improvements can be made, but refactoring to use a different method is something for the future when the bug list is whittled down more.

I tested this in 1.02, 1.03, and in today's SVN. The problem's there in 1.02, but fixed in 1.03 and SVN. So fixing something else in 1.03 fixed this. I've marked it "resolved".

Thanks for testing. Sometimes that happens and sometimes it doesn't. I'd be surprised if the movement changes fixed this problem.

If he's interrupted while sitting (or turning, or waiting, or whatever), and he comes down off alert later, he should look at his current path entity, and if it's not a path_corner, he should skip it and look at the next one, etc. etc. until he finds a path_corner. Then he should go there. That should work better than making him go back to his previous path entity. I haven't looked to see if the previous path entity that's saved is actually a corner, or whether it could be any of the multiple path entities. If it's not a corner, then going back to it won't give us what we want.

Mmmm. Rat-jam is good with crackers and hot soup on a cold day.

AI are currently timing out of the queue after at least 10s. It varies, depending on where they are in the queue. I can send them back the way they came; the previous path_corner is already kept. It will look like they got disgusted and walked away. Note that should the AI encounter another logjam during this reverse pathing, it will have to reverse itself again and walk forward to its original goal. Worst case, it can end up bouncing back and forth between two jammed-up doors. However, if the AI is buried in a logjam, there's no guarantee that giving them a different place to go to will let them free themselves. I'll try to release another DLL today with this change, and you can test it. There are also some other things I can try that I've been thinking about.

There are a lot of comments above, and instead of addressing them individually, I'll just make some general observations. The goal is to keep the AI from getting stuck. And especially to keep them from treadmilling while they're stuck. There will be plenty of situations where the code just can't handle what the AI have gotten themselves into. There might not be enough room to maneuver. Two doors might be so close to each other that their queues overlap. Lots of AI trying to get through the same space simultaneously might create a temporary standoff. I added timeouts to get them moving again if they stand around too long. So if two AI are touching and neither is moving, and something doesn't change in 10 or 20 seconds, then that's a bug. But it's probably a tough one to reproduce, given the randomness of how a crowd of AI jostle their way past each other. Wrt AI suddenly back-tracking, it means they've bumped into a func_static and are circling around to try again. In 1.03, that's where they would get stuck treadmilling. To prevent this, that particular f_s needs to have its monster_clip adjusted so AI won't get near it. It would be great to avoid func_statics altogether, w/o monster_clip, but that adds a lot more work to pathfinding that we probably can't afford right now. Three other factors affect AI behavior. 1) The code does what's called a trace to find out where an AI will fit, or how far along a path it can travel. A trace is very expensive, is done by the engine code, and doesn't always return correct results. So AI can use incorrect results and do something stupid. We can't fix this until the engine becomes open source. 2) The pathfinding code (95% id's) appears to do the same things over and over. Pathfinding is done every frame, for every moving AI, and many of the calculations done in frame N are unnecessarily repeated in frame N+1. This area needs to be looked at. If we can recover some cycles here, we could spend them on avoiding func_statics. 3) Pathfinding doesn't always identify the shortest route. Most times you won't notice, but some layouts will expose this problem. If you encounter a situation that is unacceptable, post it here and I'll see what can be done. Thanks again.

I have to go somewhere this afternoon. Will reply in detail later to your specific observations. I'm glad to hear it's working better. Hopefully we'll get more responses/observations from other testers. Thanks.

Every little bit helps. Thanks!

The changes originally went into SVN earlier this week, at rev 4472, and today's update is rev 4497.

The next version of the movement changes is ready. You can pick up a 1.03-based DLL here: http://www.mediafire.com/?edbz3uz3wowttnb For SVN users, the source is committed, at rev 4497. If you just want to pick up the SVN-based DLL, grab this: tdm_game01.pk4 (rev 11512) If someone can make a linux SVN version, that would be great. Today's update addresses the issues exposed by Fidcal's WIP, which has tight spaces and doors that are near each other. I now have 4 AI successfully navigating this challenging area. There are a few remaining things I want to investigate: 1) I'm not that happy with door-closing. An AI by itself using a closed door will close it behind him all the time. When other AI come into play, however, the door is closed by the last one through about 10% of the time. I think there are exits from the door-handling code that forget the door was originally closed. 2) There is still some treadmilling going on that shouldn't be. I know what the fix is, but I wanted to get today's version out there for people to test with. 3) I'm thinking about turning off idle animations when an AI is opening or closing a door. Looks strange when they stand there stretching or examining their hand instead of reaching out to the door, and the door opens/closes anyway. 4) Long-term, there is an issue with pathfinding that exists in 1.03 (before my changes) when there are multiple paths to reach a goal position. The AI appear to go out of their way to use a door even when there's a shorter path that doesn't go through a door. Since we don't have many situations like this, I'm not too worried about it, and will investigate it in the future. 95% of our pathfinding method is from Doom 3. Perhaps id didn't need to worry about it, given the layout of their missions. So please test when you have time, and give me feedback. And don't forget the ratty rats! Thanks.

I think I've got Fidcal's door arrangement working with 4 patrolling AI. I'll release a new DLL soon. Is anyone else working with this stuff? I'll need more confirmation that it's working before giving it an all-clear for 1.04, which is supposed to lock down a week from tomorrow. And if it isn't working, I need to hear what/when/where so I can fix it. Thanks.

A couple of anecdotes ... 1) You know you've spent too much time working with obstacle-avoidance and pathfinding code when ... ... you walk out of a store and imagine a path you're going to follow between two parked cars and one car opens a door, blocking the path, and your imagination re-routes the path over to the next available gap between cars. I swear I saw debugging path lines drawn on the sidewalk and pavement. 2) Gotta love AI barks and animations. I had a Noblewoman walking side-by-side with a barefoot Pagan, and the Pagan was making a move to pass her when she looks at the Pagan and says, "That is certainly dirty. Tsk-tsk. Why don't they clean that up?" (or something like that) A split second later, they get close enough to an open door for door-handling to take over, and she gets priority, so she keeps going and the Pagan stops to await his turn. No sooner does she disappear through the door than the Pagan turns his head and spits.

My guess is that the ledge isn't bordered by monsterclip, so the guard managed to walk off of it. Then he fell and landed on the top of monsterclip boxing in the wagon.

Amen.

@Fidcal, I built a test map roughly reproducing the screenshot above. First I tested it with vanilla 1.03 and two AI approaching from opposite ends, pathing through those three doors. It didn't take them long to get tangled up and stuck. There's very little room to maneuver in that area. Next I tested it with my changes, and, while the AI did better, they still exhibited some problems related to how close together the doors are, and the narrow spaces. I made a few changes and they started patrolling through the doors, back and forth, just fine. They paused in the right places, got out of blocking situations w/each other, and kept on going. I added a third AI and all three maneuvered through the area okay. I added a Noblewoman, who travels more slowly, and this exposed a couple more problems. They quite often clumped together in one narrow spot, no one able to find enough room to pass anyone else. In time, they eventually worked it out, but it doesn't look good when they spend 5+ seconds jostling each other. Door-queuing works great in open areas, where there's room for AI to pause, stand next to each other, and politely continue on when it's their turn. In narrow spaces, however, an AI can almost be on top of a door before he joins a queue. If he has to wait, he's more likely to be close to the door and more likely to be in the way as the AI ahead of him in the queue try to pass by. I'm going to think about how to better manage small areas like this. The door queue idea was implemented long ago to keep AI from piling up around doors. It needs to be modified to get everyone out of trouble when a pile-up does occur, which is inevitable with certain door arrangements.

The 1.03-based movement DLL does not include the weapons fix. It should be used with stock 1.03. The SVN-based movement DLL includes everything anyone's committed, and does include the weapons fix. The movement changes will be in 1.04 if the beta is successful. If it isn't, then the changes will be changed and considered again for 1.05.