View Issue Details

IDProjectCategoryView StatusLast Update
0003643The Dark ModAIpublic04.01.2020 03:54
Reportergrayman Assigned Tograyman  
PrioritynormalSeveritynormalReproducibilityalways
Status resolvedResolutionfixed 
Product VersionTDM 2.01 
Target VersionTDM 2.02Fixed in VersionTDM 2.02 
Summary0003643: AI need to use switches to open and close doors
DescriptionThere might already be an issue logged for this, didn't look.

There's code in place for AI to use switches to open and close doors.

They won't use it.
TagsNo tags attached.

Relationships

related to 0003648 resolvedgrayman AI sometimes use switches through walls 
related to 0000518 resolvedgrayman AI needs to operate buttons/levers 
related to 0004968 resolvedstgatilov Lockpicking: Running away from the lock does not cancel the sequence when you press and hold the frob-button 

Activities

grayman

grayman

26.04.2014 02:23

administrator   ~0006560

When this is resolved, issue 518 can also be resolved.

518 requests that

AI understand how to use switches to light lights (DONE)

AI understand how to use buttons to fetch and ride elevators (DONE)

AI understand how to use controllers (buttons/switches/levers) to operate doors (will be done when this issue is resolved)
grayman

grayman

04.05.2014 18:45

administrator   ~0006593

Refactored parts of the door-handling task to allow for switch (controller) use.

Rather than having each AI calculate all the door-handling positions necessary to get through a door every time they encounter one, pre-calculate everything at spawn time. Now, when an AI approaches a door, he just needs to determine which side he’s on, and use the appropriate positions for that side. No point in recalculating the same data over and over and over at runtime.

The hierarchy for door-handling is this:

- controllers
- door-handling positions
- frobable

Each side of a door can be handled differently. This allows for controllers on one side, but not on the other. It allows door-handling positions to be used in conjunction with controllers, with the dhps providing info about whether the AI can use or lock or unlock a door from that side, even if the dhps aren’t used to declare where the AI needs to stand on that side when operating the door.

A list of controllers is built from the “door_controller” spawnargs on a door, as well as any switches/buttons/levers that target the door. Only one controller is allowed per door side.

Sliding doors no longer require door-handling positions. The positions are determined at spawn time.

Allow door controllers to be locked. Each door controller retrieves its locking information from the door (keys, lockpicks, lock state, etc.).

Fixed bug where an AI would raise his hand to close a door, but be interrupted by another AI who needs to use the door. The first AI would turn and walk away with his hand raised. Now he won’t turn away until his hand is lowered.

Fixed bug where an unlock() request to a door was immediately followed by an open() request. The unlock() code plays the unlocking sound, after which it opens the door. The second open() request was interrupting the door’s movement, which was started by the first open() request. The AI would see the interruption, ignore it, and immediately issue another open() request. Since the door was only stopped for 4 frames, the player couldn’t see it. Now that we’re letting AI react to interrupted doors, we can’t do things this way.

No longer allow a task’s OnFinish() method to run more than once. There were spots where this was happening, which carried the potential for creating bugs.

Fixed bug that caused the cell doors in Home Again to stop working. This bug was in SVN, not in 2.01.

Rev. 5969:

State.cpp
SwitchOnLightState.cpp
HandleDoorTask.cpp
HandleDoorTask.h
Task.h
AI.cpp
AI.h
Memory.cpp
Memory.h
Subsystem.cpp
Actor.cpp
BinaryFrobMover.cpp
BinaryFrobMover.h
Entity.cpp
Entity.h
FrobDoor.cpp
FrobDoor.h
UserManager.cpp

Issue History

Date Modified Username Field Change
02.01.2014 02:06 grayman New Issue
02.01.2014 02:06 grayman Status new => assigned
02.01.2014 02:06 grayman Assigned To => grayman
12.01.2014 05:03 grayman Relationship added related to 0003648
24.04.2014 23:04 grayman Target Version => TDM 2.02
26.04.2014 02:20 grayman Relationship added related to 0000518
26.04.2014 02:23 grayman Note Added: 0006560
04.05.2014 18:45 grayman Note Added: 0006593
04.05.2014 18:45 grayman Status assigned => resolved
04.05.2014 18:45 grayman Resolution open => fixed
04.05.2014 18:45 grayman Fixed in Version => TDM 2.02
04.01.2020 03:54 stgatilov Relationship added related to 0004968