 |
The solution needs to accommodate other AI in the door queue. When an AI handling the door is finished, he leaves the queue, allowing the next AI to approach the door and handle it. If the first AI's handling is aborted for whatever reason, we don't want the next AI in the queue approaching the door, because we'll quickly get a traffic jam. This might need more time than what we have left in 2.02's schedule. Door and elevator handling are the most complex tasks an AI has to deal with. Even a small change can have far-reaching (and sometimes hidden) consequences. |
|
|
If an AI is opening or closing a door and it’s interrupted, he will try again. After two interruptions, he’ll push the door hard enough to push the player out of the way, if the player is blocking the door. After three interruptions, the AI will treat the door as suspicious and begin to search around it. Allow an AI to leave a door after issuing the Close() request, and before the door is fully closed. Do this as long as the AI doesn’t need to lock the door behind him, which requires that he stay with the door until it’s closed and locked. Add a new spawnarg: “canRemainOpen”. When set to “1”, AI can leave a door open after they’ve used it and they’re the last one on the door queue. The default is “0”. This is ignored if either “shouldBeClosed” or “should_always_be_locked” is “1”. It’s also ignored if the door was locked when the AI opened it, or was locked when the first AI in a line of AIs opened it. Rev. 5958: HandleDoorTask.cpp HandleDoorTask.h AI.cpp AI.h Rev. 13798: tdm_mover_doors.def |
- Anonymous
