 |
Increasing the floor thickness to 16 or even 32 does not repair the issue: AI still goes to search in the lower floor. |
 |
When a goal point is outside the AAS areas, the code "pushes" the point into the nearest AAS area, making it valid. When testing the relight code, I saw pathfinding push such a goal point into an AAS area that was on the floor below where the point was. It wasn't pushed into the closest horizontal area, as it should have been. This made the AI walk down a floor to search. The pathfinding code needs to be debugged to determine why it does this. |
|
|
Running downstairs happens when the engine pushes a search spot into the wrong AAS area when the search spot is outside any AAS areas. Sometimes the spot gets pushed sideways into a neighboring AAS area (good). Sometimes it gets pushed into the AAS area below it. When that area is way below it, AI go running downstairs, away from the expected search area. Rather than tinker with the engine code, since it’s core to so many other things that rely on it, I’ve decided to tinker with what the DLL does with the engine’s response. Running upstairs is due to the search volume extending up past the ceiling and allowing hiding spots to be found on the floor above. By adjusting the search volume’s vertical size to better fit the area where the search takes place, and making sure spots generated by the hiding spot code and the random spot code are inside the adjusted search volume, we can reduce the number of times an AI runs away. It’s still possible for an AI to search neighboring rooms if the search volume extends into those rooms. This is desirable so that AI will open doors and enter rooms during their search. This isn’t desirable if the only way to get to the neighboring room is to disappear down some stairs, run across a basement, run back up some faraway stairs, and finally get to the room. Since we want the “open door” behavior, there’s nothing we can do to prevent the “run a great distance to get to the other side of the wall” problem. (Well, there is, but it involves limiting how far the AI can travel, and using the AAS system’s travel distances can be inaccurate, depending on the map architecture. So placing limits on travel distance might negatively affect existing missions.) If an alert occurs in a stairwell, it’s still possible for an AI to run to rooms on floors above or below where the alert occurred. I think this is acceptable. Fixed several things: 1 – Run toward an alert spot iff the AI is far away, AND the alert isn’t from the visual scan that tries to locate the player. 2 – Adjust the search volume vertically to not go above the ceiling or below the floor of the room where the alert occurs, then test spots received from the hiding spot list and random point generator to make sure they’re inside the adjusted volume and also inside valid AAS areas. 3 – In the random point generator, make 6 attempts to generate a valid random point and take the first one that’s valid. If none are valid, turn toward the final point and look at it, to prevent freezing in place. Wait about 3s before making the next attempt to generate a random point. 4 – When an audio alert occurs, the code was applying some fuzziness to the alert point, based on distance from the AI that hears it. Sometimes this fuzziness would push the point into the void or the next room. Made a change to bring the fuzzy point back into the same room as the original alert point. 5 – If a searching AI bumps into something (most likely another searching AI), stop immediately and turn back toward the direction he came from. This reduces AI treadmilling against each other while searching, or having one go non-solid to let the other pass, which can be nasty-looking when the passing AI stops right where the non-solid AI is standing. This also gives the impression of two AI standing back-to-back sometimes, as they might in real life. 6 – Corrected a glitch left over from the fix to 0002603, where an AI close to a search point might jerk forward slightly and stop. I missed a line of code needed to keep that from happening, and added it here. 7 – Change to non-solid less often when searching. 8 – When setting a new, higher alert level, fix a problem with not recognizing the first moment when this happens, for the purposes of barking and starting searches. Those two actions were sometimes being delayed, and possibly missed, depending on circumstances. 9 – Fix a problem where retrieving the next hiding spot would tell the AI to go to location [0,0,0]. If that’s outside the map, no harm done. But if it’s a reachable spot inside the map, the AI would run away. 10 – If an AI is supposed to be moving, and is making zero progress, recognize this more quickly and try to resolve the block. rev. 5363: ExamineRopeState.cpp FailedKnockoutState.cpp LostTrackOfEnemyState.cpp SearchingState.cpp SearchingState.h State.cpp SwitchOnLightState.cpp InvestigateSpotTask.cpp ResolveMovementBlockTask.cpp AI.cpp AI.h AI_events.cpp Memory.cpp Memory.h MovementSubsystem.cpp DarkmodAASHidingSpotFinder.cpp |
|
|
Had to retract #8 because it caused a problem with mission statistics. We’ll have to live with the search/bark delay unless I can come up with a different solution. rev. 5364: AI.cpp |
- Anonymous
