 |
AI only rattle a locked door once. (Pathing to alternate ways will still not work in all cases) |
 |
Wanted to get feedback before deciding what to do with this issue: Here is the result of my recent tests: http://72.8.59.188/TheDarkMod/temp/doorlock.wmv He flees to the locked door, and I can confirm he tries it (apparently once). I then get some different behavior. 1. on the first try, he tried it once, then stood there. Is this okay? Should he try to flee somewhere else? 2. on the successive tries, he did what is shown in the video. He tries the lock, then after failing, tries to find a way through the doorway anyway. 3. not shown in the video, after I then unlock the door for him, he does not successfully use the door. He stands there confused (the skip pathing had stopped by now). So: do we close this and open others which cover the items listed above, or let this carry throughout the probs? |
|
|
Number 1 happens during fleeing when he can't find a reachable area that is far enough away. I'm not sure what should happen in this case, maybe he should run around like crazy or just cower and scream for help? Maybe we should open a new issue for this one. Number 2 sounds like a bug with path finding. I've been trying to make this more reliable by directly disabling/enabling areas, but this didn't work out very well so far. 3: He doesn't know that the door is not locked any more. (although the forbidden areas should be cleared after some time, so sooner or later he should try to open the door again) Does he run through the door when you open it for him? |
|
|
I'm getting very inconsistent results for 3. When I just tried it a handful of times, he generally stands in front of the door confused, so I cannot open it fully. One time it opened most of the way, but he didn't try to run through. One other time, he actually DID run through and go to his flee spot, but before I even opened it for him; he opened it himself (after I unlocked). Maybe the task hadn't timed out yet? I'll wait to hear your recommendation for 3, and will go ahead and track separate items for 1 and 2. After deciding what to do with 3 it sounds like we can probably close this one. |
|
|
Okay it looks like this is mostly addressed, except for a couple of wrinkles. Trying the same scenario shown in the video, 1. he runs up and tries the locked door once. (good) 2. he doesn't try to path through the locked door. (good) 3. when unlocked, he doesn't try the door. (not so good, but not a showstopper; 0000003 from before) 4. when opened, he also doesn't go through the door. (not so good; perhaps some shades of 0000001 from before (not far enough away?)) Do you want new entries or is this sufficient? |
|
|
That's suffcient, thanks. |
 |
I tested this with 1.04 and the guard still does 1, 2, 3, & 4 from above. I assume this is still worth fixing, so I'll see if there's something that can be done to move the guard through the door in 3 & 4. |
|
|
When an AI tries to open a locked door and can’t, that door’s AAS area number is placed in a list of forbidden areas for that AI. This keeps pathfinding from pathing through that door for that AI. Two minutes later, the area number is removed from that list, in case the door might have been unlocked or opened. 0001145’s problem is that a fleeing AI might try a locked door, fail, stand there 10 seconds, another AI unlocks the door and opens it, and the fleeing AI continues to stand there, looking stupid, until his 2-minute timer goes off. If he’s fleeing, he should run through the door the moment it’s unlocked or opened. The fix is to register an AI with a door if the door was locked and the AI tried but couldn’t open it. When that door is subsequently unlocked, the door’s area number is removed from any registered AI’s forbidden area list. Since fleeing AI are always looking for places to flee, if the current flee path runs through that door, the AI knows immediately that he can now successfully try that door. So a fleeing AI standing near the door will retry the door the moment it’s unlocked, and not wait two minutes to retry the door. When the two-minute timer goes off, if the door’s area number has already been removed from the AI’s forbidden areas list, nothing happens. rev. 4647: HandleDoorTask.cpp BinaryFrobMover.cpp BinaryFrobMover.h |
- Anonymous
