 |
I'll remove the surprise bark. Since the alert bark interruptions can interrupt each other at any level, I suggest putting a 3 second timer between them. If the timer hasn't expired, the second bark is skipped. How's that sound? |
 |
I think the surprise bark could sound good when the AI is going straight from a relaxed state to combat (though I still think it would be best to make a unique bark to weed out some of the inappropriate to_observant ones--I could do that). It just doesn't work as well when the AI is already alerted. I'll leave it up to you what you'd like to do there. The timer sounds fine with me, though would that affect rampdown barks? If an AI is at Alert3 and goes to Alert4 within the 3 second buffer, which rampdown will he make? He should probably still make a rampdown from agitated search bark, even if he didn't make the to_agitated_searching bark. I know that contradicts my earlier statement elsewhere that the rampdown should match the last bark the player heard...but I think it would be odd to have the AI searching and saying, "Come out you coward!" and then end the search with a "Must have been rats" line. |
|
|
The timer wouldn't affect rampdown barks because they occur well after alert barks are issued. And the timer would be specific to alert barks, anyway. Alert3->Alert4 w/in 3 seconds: he'd make snd_alert3, but not snd_alert4. Rampdown from Alert 4 would still be the appropriate bark, even w/o snd_alert4. If we add the timer, then the surprise bark could stay (and become snd_alert5, since we don't have one), and it would only be played if at least 3 seconds had elapsed since the previous alert bark, whether that was snd_alert3 or snd_alert4. We can adjust the timer length based on observations. |
|
|
I attached tdm_game01.pk4 with the alert bark timer in it, as well as more debug statements to see what's going on. If a bark is skipped, the debug statements will say so. I left the surprise bark in, with snd_alert1s as a placeholder. |
|
|
"The timer wouldn't affect rampdown barks because they occur well after alert barks are issued. And the timer would be specific to alert barks, anyway." What I meant to ask was whether players will hear a "rampdown to Alert 4" bark even though they didn't hear the snd_alert4 bark. "I left the surprise bark in, with snd_alert1s as a placeholder. " Ok, let me see how it works and then I'll come up with suitable barks. "it would only be played if at least 3 seconds had elapsed since the previous alert bark, whether that was snd_alert3 or snd_alert4." Is a surprise bark needed if they're already agitated searching? If they're looking for an intruder, they shouldn't really be surprised if they find one. |
|
|
Players will hear a "rampdown to Alert 4" bark even if they didn't hear snd_alert4. I can skip the surprise bark if the AI has spent time in Agitated Search. |
|
|
If the AI spends time in Agitated Searching and rises to Combat, the surprise bark won't be played. Also, if the AI spends time in Agitated Searching and drops down to Searching, and rises to Combat, the surprise bark won't be played. My reasoning is that when dropping from Agitated to Searching, the AI's weapon is still out and they're still barking "snd_state4*", so the player won't notice the difference. If the AI drops out of Searching, back to Suspicious, then he will no longer be considered as having been in Agitated Searching. This won't affect his "I've been in Agitated Searching" rampdown bark when he gets back to idle, but if he jumps straight to Combat, the surprised bark will be heard. |
|
|
Ok, that sounds reasonable to me. I'll have to play with it, but don't know how much time I'll have today. |
|
|
I attached a new pk4 with the latest changes. |
|
|
I tested the last one a bit, and this new one a few times, in 75% light conditions. The barks sound better, but there is still something odd about the behaviour. About a third of the time, the AI does exactly what I would expect...he spots me, makes a bark, and then charges straight at me. But 2/3s of the time, he spots me, and then runs off to the side, at his 10 o'clock. I've seen this happen under all different light conditions. He then has to circle around the stone wall there, searching for me even though I haven't moved. Shouldn't he run directly to my position every time? video: http://www.youtube.com/watch?v=QsUR8Vgl8qw |
|
|
I suspect that pathfinding is telling him the route to you is around the far end of the wall. Unfortunately, id's pathfinding thinks it's finding the shortest route, but the distances across AAS areas aren't always correct (I've verified this in the past), so the path around the far end of the wall is incorrectly determined to be the shortest route when in reality it isn't. You can prove this by closing off the route around the far end of the wall. If he runs straight to you, then I'm right about what's happening. Correcting this is a big deal. Maybe I'll look at it after 2.0. Given the simple case you've presented here, it might not be too difficult looking at the layers of math involved for such a short distance. |
|
|
It's odd, because it doesn't happen every time. Sometimes he DOES run straight at me, even when I'm loading the same saved game (so I know I haven't changed position). I'll try closing that route and see what happens. edit: btw, can I get you to describe under exactly what conditions the AI will play the snd_state5 bark? I'd like to have a clear idea of what kind of lines would work best before working on them. |
|
|
Weird. I updated the map and removed the wall entirely. But watch the vid--the AI still runs off to the side of me, running to a point to my left and behind me. He only finds me by accidently bumping into me. This doesn't _look_ like the AI taking an incorrect shortest route...it's like he intends to run to that specific spot, because when he gets there, he seems confused that I'm not there. IIRC, sound alerts generate a random search point somewhere near the player...but sight alerts shouldn't do that, should they? video: http://www.youtube.com/watch?v=40D_c9GGoyk |
|
|
There's fuzziness in sound origins, but not in sight origins. If it's not a pathfinding problem, then he's running to a search spot. For this type of alert (spotting the player), he should go to the player origin as his first search spot. Only after that will he begin to search for spots the Hidden Spot Search tells him are good places to search. What ambient level are you using? |
|
|
"can I get you to describe under exactly what conditions the AI will play the snd_state5 bark? I'd like to have a clear idea of what kind of lines would work best before working on them." He will bark this if BOTH of these are TRUE: 1 - It's been at least 3s since he last barked ANY snd_alertN bark. 2 - He rose to Combat State w/o stopping at Agitated Search first. If he stops at Agitated Search, drops back to Searching, then goes straight to Combat w/o again stopping at Agitated Search, that's FALSE as far as # 2 goes. |
|
|
"What ambient level are you using? " That test was with the light set to 35. |
|
|
Change the ‘surprise bark’ to ‘snd_alert5’. Don’t bark it if arriving in Combat State from Agitated Searching State, or after having been in Agitated Searching State, then dropping back to Searching State, then rising to Combat State. Don’t allow an alert bark if another one was emitted less than 3s earlier. This applies to all alert levels. This has no effect on rampdown barks. Rev. 5830: AgitatedSearchingState.cpp AlertIdleState.cpp CombatState.cpp IdleState.cpp ObservantState.cpp SearchingState.cpp SuspiciousState.cpp Memory.cpp Memory.h |
|
|
This seems to be fine now. I'm going to mark it resolved. |
- Anonymous
