View Issue Details

IDProjectCategoryView StatusLast Update
0002422The Dark ModAIpublic02.04.2012 01:15
Reportersotha_sil Assigned Tograyman  
Status resolvedResolutionfixed 
PlatformWin32OSWindowsOS VersionXP
Product VersionTDM 1.02 
Target VersionTDM 1.08Fixed in VersionTDM 1.08 
Summary0002422: AI goes to lower floor when searching
DescriptionAI searching goes to exactly the same spot on the lower floor, when the grid size is 8. Other sizes have not been tested.
Steps To ReproduceIn the testmap go to the topmost floor and shoot a noisemaker at the opposite wall. AI will briefly search the topmost floor and then lower floor at the same spot.

Testmap in svn:
Additional InformationDiscussion thread:
TagsNo tags attached.




14.11.2010 18:50

reporter   ~0003291

Increasing the floor thickness to 16 or even 32 does not repair the issue:
AI still goes to search in the lower floor.


06.07.2011 05:21

viewer   ~0003909

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.


01.04.2012 18:12

viewer   ~0004429

Last edited: 01.04.2012 18:22

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:




02.04.2012 01:15

viewer   ~0004430

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:


Issue History

Date Modified Username Field Change
14.11.2010 12:36 sotha_sil New Issue
14.11.2010 18:50 sotha_sil Note Added: 0003291
31.05.2011 18:30 grayman Assigned To => grayman
31.05.2011 18:30 grayman Status new => assigned
06.07.2011 05:21 grayman Note Added: 0003909
01.04.2012 18:12 grayman Note Added: 0004429
01.04.2012 18:12 grayman Status assigned => resolved
01.04.2012 18:12 grayman Resolution open => fixed
01.04.2012 18:12 grayman Fixed in Version => TDM 1.08
01.04.2012 18:12 grayman Target Version => TDM 1.08
01.04.2012 18:22 grayman Note Edited: 0004429
02.04.2012 01:15 grayman Note Added: 0004430