View Issue Details

IDProjectCategoryView StatusLast Update
0003104The Dark ModAIpublic21.05.2012 22:02
Reportersotha_sil Assigned Tograyman  
PrioritynormalSeveritynormalReproducibilityalways
Status resolvedResolutionfixed 
Product VersionTDM 1.07 
Target VersionTDM 1.08Fixed in VersionTDM 1.08 
Summary0003104: Two AI passing through a locked door leaves the door unlocked
DescriptionA locked door. Two AIs go through it. The first unlocks it and passes to the other side. He does not close the door as another AI approaches. The other AI passes through, closes the door but does not lock it.

Steps To ReproduceCheck the test map provided.

In the area behind the first door, two AI walk in a line through the doors. The doors should all be locked. The AI pair leaves always the doors unlocked.

There is a single AI in the last room, passing through a door alone. He locks the door always.
TagsNo tags attached.

Activities

sotha_sil

sotha_sil

01.05.2012 19:19

reporter  

door_unlock.map (25,614 bytes)
grayman

grayman

01.05.2012 21:37

viewer   ~0004512

The second AI doesn't know the first one unlocked the door, so he doesn't know he should lock it.

Shall we assume that the AI who unlocked the door somehow tells the AI following him that he did so, and that the second tells the third, who tells the fourth, etc., until the final AI goes through and knows to lock it behind him,

-or-

shall we rely on the "should_always_be_locked/1" spawnarg that's already handled in the code. This spawnarg guarantees that the door is always locked, as long as the locker has the ability to unlock that door (has a visible or invisible key).
sotha_sil

sotha_sil

13.05.2012 17:31

reporter   ~0004576

Thanks for bringing this up, I had no clue...

I'm puzzled though.

Shouldn't this "should_always_be_locked" default to 1 when the door is locked? It is easy to assume that if door is locked when a single AI goes through, the door would also also be locked if *two* AI goes through?

It would be easy for a mapper (like me, at least) to overlook such a spawnarg if it defaults to causing an non-symmetric situation when 1 or 2 AI goes through the portal.
grayman

grayman

19.05.2012 03:55

viewer   ~0004592

I'm testing a code change that allows a conga line of AI to remember if the first AI found a door locked, so that the last AI can relock it.

This will be independent of the should_always_be_locked setting.

This might look odd if the first AI unlocked the door before the last AI joined the door queue. An observer might ask, "How did the last AI know to relock the door when he didn't see the first AI unlock it?" In that case, we'll just wink-wink-nod-nod claim that each AI whispered to the AI behind him, "This door needs to be relocked."

I'll do more testing tomorrow to make sure I didn't break something.
grayman

grayman

21.05.2012 22:02

viewer   ~0004604

Fixed these problems:

1 – In a line of AI passing through a door, if the first found the door locked, the last relocks it.

2 – AI passing through a door will bump into the door less when through.

3 – Eased restrictions on deciding a friend/neutral used a door that was found open but should be closed. Candidate AIs don’t have to be friends only.

4 – When coming upon a suspicious door that someone else is already searching, continue to be stimmed by it in case the other AI leaves the door open for whatever reason. This lets you deal with the door later if you find it open again.

5 – If an AI is far from, and out of sight of, a suspicious door when his alert level comes down and it’s time to close the door, let him set up door-handling (for closing the door) even though he can’t see the door. Normally, AI don’t set up to handle a door unless they can see it.

6 – Correct a problem when encountering the same door you’re already handling. The code was terminating the current door-handling to start a new one. A small window due to timing caused termination of the current door-handling to not happen correctly. The fix is to ignore the new request to handle the door, and continue with the existing one.

7 – If the AI’s alert level dropped enough to cause closure of a suspicious door, but the AI was off handling another door (perhaps he walked into another room while searching), he would forget about closing the suspicious door. Fixed it so he would still be stimmed by the suspicious door, giving him another chance to search and close it when he sees it again.

8 – Fixed a problem when walking through a suspicious door to close it.

9 – The door queue is centered on the center of the closed door, not its origin, to make it more uniform.

10 – An AI that wanders too far from a suspicious door while searching leaves door-handling for that door. The code was checking to see if they’d arrived at a door-handling spot, but since they wandered away, the code assumed they hadn’t gotten there yet. This allows others waiting to use the door to use it when the searching AI has left the area.

rev 5455:

State.cpp
State.h
SuspiciousState.cpp
HandleDoorTask.cpp
BinaryFrobMover.cpp
BinaryFrobMover.h
FrobDoor.cpp
FrobDoor.h
FleeTask.cpp
Light.cpp

Issue History

Date Modified Username Field Change
01.05.2012 19:19 sotha_sil New Issue
01.05.2012 19:19 sotha_sil File Added: door_unlock.map
01.05.2012 21:37 grayman Note Added: 0004512
13.05.2012 17:31 sotha_sil Note Added: 0004576
19.05.2012 03:55 grayman Note Added: 0004592
19.05.2012 03:55 grayman Assigned To => grayman
19.05.2012 03:55 grayman Status new => assigned
21.05.2012 22:02 grayman Note Added: 0004604
21.05.2012 22:02 grayman Status assigned => resolved
21.05.2012 22:02 grayman Resolution open => fixed
21.05.2012 22:02 grayman Fixed in Version => TDM 1.08
21.05.2012 22:02 grayman Target Version => TDM 1.08