AI Movement Changes Beta

[Fidcal]

Screenshot below, slightly processed for clarity. I think those handle pos entities are disabled currently so ignore those. The three doors are highlighted in yellow.

 

 

 

[Aprilsister]

I've haven't played with this yet, but I've been meaning to ask (and verify) is the weapons fix thing in this? And more importantly, is it officially in the 1.04 slated? Because it is a success and ought to be. That's what I really want to say; I suppose I can see for myself if the weapons fix is in this implementation...

 

Though, maybe with the new scripts and defs I have it must be implemented in the gamex86.dll?

 

...

 

moved what was here below the ellipsis to a new thread in "TDM Tech Support", so as not to derail this thread any more than the slight bit the above shall do

Edited January 26, 2011 by Aprilsister

[grayman]

I've haven't played with this yet, but I've been meaning to ask (and verify) is the weapons fix thing in this? And more importantly, is it officially in the 1.04 slated?

 

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.

[Aprilsister]

Thanks for that; I don't believe I can get to the SVN stuff yet (though there are rumors that we outsiders will be able to dl and compile this stuff eventually/pretty-soon-ily).

 

So I and anyone else who is using the weapons-fix-patch should do the roll-back thing (delete the new scripts and defs) before plugging in the new tdm_game01.pk4.

 

I am happy to hear that the weapons-fix is a lock for 1.04, because -- I attest again -- it is working and it is nice.

 

...

 

I'm also happy to hear the forward-thinking well-if-it-isn't-ready-for-vx.xx-we-can-always-schedule-it-for-vx.xx++ philosophy is the rule of the day!

[Fidcal]

weapons fix? What's that? I can't keep up.

[Aprilsister]

You remember this hopefully (you were there during some of the discussion, but I guess missed the fix). It works great, but as mentioned above, has to be rolled-back to not conflict with this thread's experiment/purpose.

[grayman]

@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.

[Tels]

Still good work, nobody expects it to be perfect

[stgatilov]

Never seen anything like this before. I run SVN version.

 

The guard was first running somewhere in alerted state, then he walked to the ledge, looked around for a while, and then walked further. And dropped to the air. Don't know how to reproduce it, I'm afraid.

 

[grayman]

The guard was first running somewhere in alerted state, then he walked to the ledge, looked around for a while, and then walked further. And dropped to the air. Don't know how to reproduce it, I'm afraid.

 

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.

[grayman]

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.

[New Horizon]

 

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.

 

That's awesome.

[grayman]

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.

[New Horizon]

When the dll is ready, I'll take a look at things.

[Fidcal]

I'll certainly test it with Royale. If I have time also add a few AI to Heart locally and re-route paths through common doors more to see how it performs. I have a good idea how it behaved in that so any improvement I should see easily.

[Springheel]

Gotta love AI barks and animations

 

Hey, doesn't that count as "emergent intelligence"? We should add that to our marketting brochure.

 

Are the movement changes on SVN, grayman? I was looking at the log for something else last night and didn't see any commits from you recently.

[grayman]

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.

[grayman]

Are the movement changes on SVN, grayman? I was looking at the log for something else last night and didn't see any commits from you recently.

 

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

[nbohr1more]

I've installed it.

 

God knows if I'll have the time to properly test it...

[grayman]

God knows if I'll have the time to properly test it...

 

Every little bit helps. Thanks!

[Fidcal]

I will definitely try to test today.

 

My previous report about AI taking a long way round was caused by some stray monsterclip blocking the short route. Just thought I'd mention that in case my report was the main support of the theory that AI didn't take the optimum path. Another example might be that currently AI will not use an elevator if there is a normal path up some stairs etc. even if they are far away. I believe if their next target is unreachable they test for an elevator is how it works.

[Fidcal]

Only tested for 15 to 30 minutes but I'm very familiar with Royale and how the AI normally patrol. This looks pretty wonderful to me - just how I dreamt it might be. Plenty of AI flowing around and not getting stuck. Rats also OK.

 

The only case I saw untangled itself. There were three AI on the narrow stairs got stuck in a loop around each other. One was stuck facing a wall not moving. The other two were circling around. But they were not circling aimlesly. Eventually one moved sufficiently away that another could get by and then the first could continue. The guy stood facing the wall then recovered and resumed his journey. Now some might say it looked ridiculous. And probably it did in human terms. But it is vastly superior to getting permantly stuck and moonwalking against a corner. And of course, the player might not even see this often. I was flying around looking for it. IMO I doubt this can be improved on given the current technology. All I ever wanted was that the AI try different things and also kick start themselves if they get stuck. And these seemed to do fine.

 

I've been watching the AI all flow around randomly. Sometimes an area might be empty. Then you see the occasional AI pass through. Three minutes later five or six AI are passing through. One stood looking at window; One handling a door; another patrolling; a nice busy scene. Why players ever want to KO everybody I do not know.

 

The only other minor anomoly I saw was the lady was walking alone through a corridor to an open archway and suddenly whirled around at the edge of the arch and walked back a couple of paces as though she was going back. I thought wtf. I know I didn't set that up. But then she turned again and continued through the arch. I can only guess she was going to bump the edge of the doorway and turned away to avoid it. That's OK by me. People don't always go in a straight line without hesitating, turning, changing their mind.

 

Just checked back after writing this and found one woman stood in the back stair well. Clear space ahead of her and around the corner and the door open. I thought this has crashed. Then another guy came along. Uh oh! I expected him to stop. He went straight through clipping through her. Then she resumed and went on her way. Presumably before she got into a wait loop for someone else or even this guy and then it timed out. So this is great by me. I'm leaving it running and check back now and again. I've seen enough to not bother testing in Heart. This is miles better than we had and superior to Thief. Thanks grayman.

 

I might try causing an alert later in a crowded area to see how they recover after.

 

I think some players may criticise that the AI go into circles, stand around, behave oddly, when there are a lot together in one space. I don't think I'll be one of them!

 

One other thing that may or may not be relevant. While working on another big map I found after I installed this code in 1.03 that dmap was taking a very long time. It seemed to hang while doing the rat pathfinding. It did eventually complete though. Same with Royale. May be my imagination. Can anything in your code affect dmap's pathing setup time?

 

Some of you players ought to check this out and test it with any FMs where you have seen AI get stuck. See the difference. Set notarget 1 and noclip 1 so you can fly about and not interact or affect AI behaviour. Just watch.

[grayman]

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.

[Aprilsister]

That does all sound good and coming so enthusiastically from Fidcal it's even more encouraging. I gotta make time for this!

 

Only thing about your write up that has me wanting to question it, Fidcal, is the bit about the woman:

 

The only other minor anomoly I saw was the lady was walking alone through a corridor to an open archway and suddenly whirled around at the edge of the arch and walked back a couple of paces as though she was going back. I thought wtf. I know I didn't set that up. But then she turned again and continued through the arch. I can only guess she was going to bump the edge of the doorway and turned away to avoid it. That's OK by me. People don't always go in a straight line without hesitating, turning, changing their mind.

 

What worries me here is that one element of Our Beloved Thief Gameplay is that we are meant to observe patrols and act upon the regularity of them. So, if things get too random it may start to bug... of course if your guess, about her simply maneuvering to avoid and then proceeding on her shortest path, is correct then that's just a matter of tweaking the monster clip or something I'd guess (upon your guess).

Edited January 30, 2011 by Aprilsister

[Fidcal]

No she didn't change her route. She just stopped, turned around and went back a couple of paces, circled around again and proceeded forward on her original route.

 

However, I've now tested with a massive alert and got about 15 AI all converged on the back stair well. This took a few minutes before the alert started to subside and all but two of the AI eventually wandered back to their duties. Unfortunately those two seemed to have lost their patrol. When others try to patrol through this area they then couldn't because of these two. I noticed that as a new jam started these two AI got jostled into a corner and it did seem that AI were with difficulty working through. But it was taking so long that new AI were piling up at the back so there were always some AI stuck.

 

In fact now I think about it, it might simply be that they were the front door or front gate guards who do not have a patrol. Yes, that must be it. They should return to their original start positions but that failed.

 

A mapper workaround might be to always set AI on patrols. If they need to just stand then let them patrol on the spot by just turning a little between two path points. More realistic anyway. I'll try that and see if it fixes this.