View Issue Details

IDProjectCategoryView StatusLast Update
0004343The Dark ModAIpublic11.12.2018 13:30
Reporternbohr1more Assigned Tograyman  
Status resolvedResolutionfixed 
Product VersionSVN 
Target VersionTDM 2.07Fixed in VersionTDM 2.07 
Summary0004343: AI instantly lose track of the player on dark ledges
DescriptionNow that the AI have better search behavior, seeing them enter it instantly is a jarring effect. It breaks immersion to see a hot pursuit end with the player cornered on a ledge and then with a single (small) motion to the left (etc) the AI instantly forgets that they last saw them up there.
Steps To Reproduce1) Alert an AI in a brightly lit area

2) Get a chase going with a few AI

3) Mantle onto a dimly lit awning or ledge

4) The AI cannot reach you so they throw projectiles

5) Move one millimeter back

6) The AI "INSTANTLY" loses you to the shadows and starts the new 2.04 search behavior
TagsNo tags attached.


related to 0001430 new AI having trouble finding player by sound? 
related to 0001433 acknowledged AI should take cover from guessed attack position even if they can't see player 




21.07.2018 19:49

developer   ~0010717

SO I've taken a look and assume that the issue is most likey to be found in void idAI::UpdateEnemyPosition().

There is a boolean enemyDetectable which is only set to true if the player can actually be seen. So once the player is not visible anymore, this boolean is false and a lot of the code gets skipped.

For testing purposes I've added a line that sets the boolean to true if the last time the player was seen was less then two seconds ago. This does not cause the ai to continue throwing rocks (although the task is kept, but I guess the ai needs a target), but it does stand there for this period before it gets into the searching behaviour, which is at least a step into the right direction.

I'll see whether I can get the ai to throw something. :)


21.07.2018 20:13

developer   ~0010719

It seems that this behaviour is already an intented part of the code. There is a MAX_BLIND_CHASE_TIME of 3 seconds defined that should allow the ai to keep track of the player even if he is not visible anymore. For some reason this gets ignored.


21.07.2018 20:24

developer   ~0010720

Increasing the MAX_BLIND_CHASE_TIME "solves" the issue. However, the ai is doing fancy animation stuff (looks like it is looping the same anim over and over) and rocks are only thrown every few seconds, which appears odd.

So I guess some fine tuning of the respective values involved and a deeper look at the anim thing could get us get rid of the issue.


10.12.2018 17:44

viewer   ~0010858

MAX_BLIND_CHASE_TIME is not used when throwing rocks. It's intended for trying to keep track of the player's position when he's being chased. I.e. if the player rounds a corner and disappears, we need the AI to keep heading toward the place where he last saw him, and that's where MAX_BLIND_CHASE_TIME comes in.

If I'm reading this right, we have this situation:

1 - AI is throwing rocks.

2 - Player moves into deeper shadow.

3 - AI immediately quits throwing rocks and starts searching.

Are you asking that a delay be inserted between steps 2 and 3?


10.12.2018 18:52

developer   ~0010860

Yes. It is not quite natural that AI go completely into an "I lost him" mode when you make that small position change.


10.12.2018 19:39

viewer   ~0010861

Okay, I'll look at adding a random 2s-4s delay after the AI loses the player when throwing rocks. If he sees the player again before the delay runs out, he'll just seamlessly continue to throw rocks.


10.12.2018 22:16

viewer   ~0010862

Even though MAX_BLIND_CHASE_TIME isn't used by the "throw rocks" task, what can happen is that another routine which is keeping watch over whether the AI continues to be visible, and which does use MAX_BLIND_CHASE_TIME, can expire when that time expires, and the expiration kills whatever the AI is doing at the time (i.e. throwing rocks) so he can enter search mode.

So the throwing task dying is a side effect of MAX_BLIND_CHASE_TIME expiring.

I added a random delay of 2s-4s when the throwing task can no longer see the player, but it didn't seem to matter because MAX_BLIND_CHASE_TIME is 3s, so the effect was negligible; the throwing task would quit either on its own, or when it was forced to quit by the monitoring routine.

The only way to guarantee that the AI will have more time after he stops throwing rocks and before he starts searching, is to make MAX_BLIND_CHASE_TIME longer than 3s, say 6s.

I don't know how this affects other tasks, though, that normally get killed when MAX_BLIND_CHASE_TIME expires. Will it look odd that the AI continues to do those tasks much longer than they have in the past?

It might be that that's what Obs observed when he bumped up MAX_BLIND_CHASE_TIME.


10.12.2018 22:22

viewer   ~0010863

Last edited: 10.12.2018 22:22

View 2 revisions

I think I need a better definition of "immediately" as I work on this problem.

Since MAX_BLIND_CHASE_TIME is set to 3s, and it's only kicked off when the AI can't see the player, we're guaranteed a 3s delay after the player disappears into deeper shade before the AI gives up.

So I'm confused as to why you're seeing the player step into deeper shade and IMMEDIATELY having the AI start searching. There's supposed to be a 3s delay between those two events.



11.12.2018 02:31

developer (2,578,649 bytes)


11.12.2018 02:35

developer   ~0010864

I have attached a save file from "King of Diamonds".

1) Stand up and walk forward into the light
2) Note an AI bark "Ah ha! Now I've got you!"
3) Crouch and crawl back into the dark
4) While doing this the AI barks "Stand up and fight"
5) Less than a second later the same AI barks "What? Where did he go?"


11.12.2018 05:18

viewer   ~0010872

Last edited: 11.12.2018 05:24

View 2 revisions

I think this is a timing issue.

Throwing rocks depends on a separate task to keep track of player visibility. When the player becomes invisible, that task waits 3s and if the player hasn't become visible again, it kills itself, kills the throwing task, and starts a "lost player" task, which puts the AI in search mode.

So the exact moment the player becomes invisible is key. If you step back into shadow, you can't exactly tell when the AI loses sight of you. You might think he loses you immediately, but it's possible he lost you before that.

While using the provided save game, and repeatedly testing, I got what seemed like 1s to 3s delays in the AI losing me. I didn't get anything that seemed immediate.

If I change the 3s delay to 5s, just for the visibility monitoring task, we might get a better impression that the AI is taking longer to switch to search mode.

Let's try that first, and if that doesn't improve the situation, I'll try to think of something else.



11.12.2018 05:25

developer   ~0010875

Sounds good. :)


11.12.2018 05:32

viewer   ~0010876

Okay, try the latest SVN Windows binaries.

This is a simple lengthening of the delay from 3s to 5s. This makes it more likely that it will seem less "immediate" when the AI loses sight of the player.


11.12.2018 05:54

developer   ~0010877

Thanks. This is much better. I'd consider this one resolved.


11.12.2018 13:29

viewer   ~0010880

The rock-throwing task has a comment that says "don't throw a rock if the player is not visible", but it was throwing the rock anyway. Added a check for visibility.

That should do it for this problem.

Created a new delay (MAX_BLIND_UNREACHABLE_TIME) of 5s for use by UnreachableTargetTask. It was using MAX_BLIND_CHASE_TIME, which is 3s.

The rock-throwing task has a comment that says "don't throw a rock if the player is not visible", but it was throwing the rock anyway. Added a check for visibility.
These two changes should reduce the perception that the rock-throwing task aborts immediately when the player steps into darkness.

Rev 7799 & 7800:


Issue History

Date Modified Username Field Change
15.06.2016 12:46 nbohr1more New Issue
06.10.2017 02:15 nbohr1more Target Version => TDM 2.07
10.10.2017 16:29 nbohr1more Relationship added related to 0001430
28.03.2018 21:51 nbohr1more Relationship added related to 0001433
21.07.2018 19:49 Obsttorte Note Added: 0010717
21.07.2018 20:13 Obsttorte Note Added: 0010719
21.07.2018 20:24 Obsttorte Note Added: 0010720
21.07.2018 20:24 Obsttorte Status new => feedback
10.12.2018 16:32 grayman Assigned To => grayman
10.12.2018 16:32 grayman Status feedback => assigned
10.12.2018 17:44 grayman Note Added: 0010858
10.12.2018 17:45 grayman Assigned To grayman => nbohr1more
10.12.2018 17:45 grayman Status assigned => feedback
10.12.2018 18:52 nbohr1more Note Added: 0010860
10.12.2018 18:52 nbohr1more Status feedback => assigned
10.12.2018 19:39 grayman Note Added: 0010861
10.12.2018 22:16 grayman Note Added: 0010862
10.12.2018 22:22 grayman Note Added: 0010863
10.12.2018 22:22 grayman Note Edited: 0010863 View Revisions
11.12.2018 02:31 nbohr1more File Added:
11.12.2018 02:35 nbohr1more Note Added: 0010864
11.12.2018 05:18 grayman Note Added: 0010872
11.12.2018 05:24 grayman Note Edited: 0010872 View Revisions
11.12.2018 05:25 nbohr1more Note Added: 0010875
11.12.2018 05:32 grayman Note Added: 0010876
11.12.2018 05:54 nbohr1more Note Added: 0010877
11.12.2018 05:54 nbohr1more Assigned To nbohr1more => grayman
11.12.2018 05:54 nbohr1more Status assigned => feedback
11.12.2018 05:54 nbohr1more Fixed in Version => TDM 2.07
11.12.2018 13:29 grayman Note Added: 0010880
11.12.2018 13:30 grayman Status feedback => resolved
11.12.2018 13:30 grayman Resolution open => fixed