 |
A couple things to note ... 1 - Need to keep a list of noisemakers an AI is currently hearing, because the player can fire more arrows before the previous arrows have stopped being noisy. Currently, AI will be interested in whatever arrow made the last sound, so they can bounce back and forth between arrows that are still emitting. With the code change, they'll go toward the first arrow fired, then go toward the next, etc., w/o bouncing back and forth. 2 - Since entity numbers can be reused, I need to remove an arrow from the list when it stops making noise. I'll need to set some fixed duration based on how long an arrow emits noise (it emits 5 separate sounds), because I can't tell when an arrow stops making noise. |
 |
This value: "active_duration" "17" on entity: entityDef atdm:ammo_noisemaker determines how long the noise arrow plays its player-heard sound. |
|
|
Created a list of noisemakers an AI is hearing. The AI only reacts to the first of the many sounds the noisemaker emits, so the list tells the AI if he’s heard the sound before. A noisemaker is added to the list when the AI hears the first sound, and removed from the list when it’s finished making sounds. rev. 5942: AI.h AI.cpp AI_events.cpp |
|
|
I just tried this after updating SVN, and I can't confirm the fix. AI are still ramping up multiple times from a single arrow. |
|
|
I didn't build the binaries, so you're using old code. I'll do that in a couple hours (watching BBall game). |
|
|
Sure thing. |
|
|
I won't be able to do this tonight. I tried to cram it into halftime, and accidently hit a wrong button. Now I have to assess the state of the source tree, and I need to do it methodically, and that isn't going to happen tonight. Sorry. |
|
|
New tdm_game01.pk4 committed. Remember to delete the gamex86.dll from your darkmod folder. The sound changes are included in this latest pk4, so you shouldn't need the special DLL I gave you a while back. |
|
|
This is a big improvement, and noise arrows are actually quite functional now. However, I have experienced the following scenario: Player shoots a noise arrow. A guard behind a door and down a hall is far enough away that he only goes to lvl 1 alert. He continues patrolling and 12 seconds later opens the door to the room with the noise arrow. Because he has already been alerted from the arrow, his lvl 1 alert continues to ramp down, resulting in him appearing to ignore the arrow, even though he is now in the room where it continues to play for another 5 seconds. This is not likely to happen very often--the AI has to be walking towards the noise arrow; he has to only be alerted to level 1 (level 2 causes him to stop which means the arrow will likely stop making noise before he gets to it), and he has to be the only one who heard the arrow (if there is already a guard there he goes to Lvl 3 and joins the search). However, the most robust solution would probably be to have AI react to each sound of the noise-arrow, but make sure that the noise arrow's cap of "alert_max" "15" applies _cumulatively_. The AI can never go higher than 15 from the same noisearrow. |
|
|
In addition to tracking which arrows the AI has heard, have to add an extra variable to hold the accumulated psychLoud value. (psychLoud = alert increase) This will either require a second list, or the creation of a new struct that holds both the arrow pointer and the accumulated psychLoud. Remember to destroy any struct you remove from the list later. Allow the AI to react to each noise from the same arrow unless the accumulated psychLoud has reached "alert_max". Note that the "alert_max" check is done before multiplying psychLoud by the AI's audio acuity. Is this a bug? It allows the alert increase to go above "alert_max" in the cases where the audio acuity > 1.0. This can be the case for AI at higher alert levels, where all acuities are multiplied by fixed factors that are > 1.0. |
|
|
Hmm, I wasn't aware of that, but it isn't necessarily a bug. An AI who is already alert probably should have the potential to go to a higher alert level than his relaxed friend. In fact, I could use that in the noise arrow case, so that previously alerted AI go to alert 4 (they would assume the arrow is not just someone having fun if they're already on alert). What is the acuity value of AI who have hit alert level 4 in the past? 1.4? |
|
|
Acuity factors: seta tdm_ai_acuity_L5 "1.5" seta tdm_ai_acuity_L4 "1.3" seta tdm_ai_acuity_L3 "1.1" |
|
|
L3 is 1.1? What is the setting for AI at idle alert? I thought that was 1.1. |
|
|
The only other acuity factor I see is this one: seta tdm_ai_acuity_susp "1.2" ("... if the AI is suspicious due to evidence. It is in addition to the other modifiers.") But it's not implemented, which is why I didn't mention it above. Perhaps that was intended for Alert Idle? I don't see any factors applied while in Alert Idle. From the comment, I suspect it was supposed to modify the acuities at all alert levels as long as the AI has "seen evidence". It's the same "seen evidence" check that shifts an AI from Idle to Alert Idle. So if it gets applied, an AI (for example) at Level 4 (Agitated) would have its acuities multiplied by 1.2*1.3. |
|
|
Clarification: These multipliers aren't used depending on the AI's current alert level. They're used depending on the AI's maximum alert level. So an AI that has risen to Combat mode will always have the L5 multiplier applied to his acuities. One that has risen no higher than Searching will always have the L3 multiplier applied. |
|
|
Ah, that makes sense. Thanks. |
|
|
One of the nice aspects of this fix was that you can lead an AI away from you by firing noise arrows farther and farther away. The AI isn't going to walk toward arrow 1, then walk toward arrow 2, then walk back toward arrow 1 when it makes another noise. With the additional check for psychLoud reaching a maximum, and allowing AI to hear noises 2-5, make sure that the above aspect of the new behavior isn't lost. I don't want AI toggling back and forth between arrows as the arrows alternatively make noise. |
|
|
Rather than remembering a noisemaker when an AI first hears it, remember a noisemaker when it first drives the AI up into Searching mode or higher. This allows an AI to have its alert level raised a bit by the first sound, a bit more by the next sound, etc., until enough alert has accumulated to drive them up into Searching mode. Once that’s happened, the AI will ignore any more sounds from the same noisemaker. Rev. 5946: AI.cpp |
|
|
Great idea! |
- Anonymous
