 |
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). |
 |
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. |
|
|
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. |
|
|
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 |
- Anonymous
