 |
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. :) |
|
|
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. |
|
|
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. |
 |
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? |
 |
Yes. It is not quite natural that AI go completely into an "I lost him" mode when you make that small position change. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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?" |
|
|
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. |
|
|
Sounds good. :) |
|
|
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. |
|
|
Thanks. This is much better. I'd consider this one resolved. |
|
|
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: Memory.h UnreachableTargetState.cpp ThrowObjectTask.cpp |
- Anonymous
