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