View Issue Details

IDProjectCategoryView StatusLast Update
0001145The Dark ModAIpublic27.10.2011 05:17
ReporterSneaksieDave Assigned Tograyman  
PrioritynormalSeveritynormalReproducibilitysometimes
Status closedResolutionfixed 
Product VersionSVN 
Target VersionTDM 1.05Fixed in VersionTDM 1.05 
Summary0001145: AI trying doors they cannot open
DescriptionSee #.4 here:
http://modetwo.net/darkmod/index.php?s=&showtopic=8269&view=findpost&p=163548

Perhaps just the flip side of a case not yet covered when the ability to use certain locked doors was granted. Poor guy doesn't have the proper key, but he really wants to get away. Feeling sorry for him, I then unlocked it, and he telekinetically opened it and ran off about his business.

http://72.8.59.188/TheDarkMod/temp/uneedtehkey.wmv
TagsNo tags attached.

Activities

angua

angua

02.10.2008 17:52

manager   ~0001711

AI only rattle a locked door once. (Pathing to alternate ways will still not work in all cases)
SneaksieDave

SneaksieDave

03.10.2008 17:14

reporter   ~0001731

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?
angua

angua

03.10.2008 20:43

manager   ~0001738

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?
SneaksieDave

SneaksieDave

03.10.2008 21:26

reporter   ~0001741

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

SneaksieDave

12.12.2008 18:01

reporter   ~0002237

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?
angua

angua

13.12.2008 08:43

manager   ~0002240

That's suffcient, thanks.
grayman

grayman

02.03.2011 05:16

viewer   ~0003684

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

grayman

03.03.2011 01:40

viewer   ~0003685

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

Issue History

Date Modified Username Field Change
18.09.2008 23:17 SneaksieDave New Issue
18.09.2008 23:21 SneaksieDave Description Updated
25.09.2008 09:34 angua Status new => assigned
25.09.2008 09:34 angua Assigned To => angua
28.09.2008 14:00 angua Project The Dark Mod => @3@
02.10.2008 17:52 angua Note Added: 0001711
02.10.2008 17:52 angua Status assigned => resolved
02.10.2008 17:52 angua Fixed in Version => Release
02.10.2008 17:52 angua Resolution open => fixed
03.10.2008 17:14 SneaksieDave Note Added: 0001731
03.10.2008 17:14 SneaksieDave Status resolved => feedback
03.10.2008 17:14 SneaksieDave Resolution fixed => reopened
03.10.2008 20:43 angua Note Added: 0001738
03.10.2008 21:26 SneaksieDave Note Added: 0001741
24.10.2008 05:17 angua Project @3@ => The Dark Mod
21.11.2008 17:51 angua Status feedback => resolved
21.11.2008 17:51 angua Fixed in Version Release =>
21.11.2008 17:51 angua Resolution reopened => fixed
12.12.2008 18:01 SneaksieDave Note Added: 0002237
12.12.2008 18:01 SneaksieDave Status resolved => feedback
12.12.2008 18:01 SneaksieDave Resolution fixed => reopened
13.12.2008 08:43 angua Note Added: 0002240
02.03.2011 05:16 grayman Note Added: 0003684
03.03.2011 01:40 grayman Note Added: 0003685
03.03.2011 01:40 grayman Assigned To angua => grayman
03.03.2011 01:40 grayman Status feedback => resolved
03.03.2011 01:40 grayman Resolution reopened => fixed
03.03.2011 01:40 grayman Fixed in Version => TDM 1.05
03.03.2011 01:40 grayman Target Version => TDM 1.05
27.10.2011 05:17 greebo Status resolved => closed