View Issue Details

IDProjectCategoryView StatusLast Update
0003681The Dark ModCodingpublic05.04.2014 20:58
ReporterSpringheel Assigned Tograyman  
PrioritynormalSeveritynormalReproducibilityhave not tried
Status resolvedResolutionfixed 
Product VersionTDM 2.01 
Target VersionTDM 2.02Fixed in VersionTDM 2.02 
Summary0003681: Noise Arrow "sounds" should be considered the same sound to AI
DescriptionRight now, the Noise Arrow fires a propagated sound to AI 5 times. The AI react to each sound as if it's a new alert, which quickly ramps them up to full alert. We want some flag that tells AI "this sound you're hearing now is from the same arrow as the noise you heard before, so don't raise your alert level any more".
TagsNo tags attached.




06.03.2014 16:20

administrator   ~0006412

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.


06.03.2014 17:51

administrator   ~0006413

Last edited: 06.03.2014 17:51

View 2 revisions

This value:
"active_duration" "17"
on entity:
entityDef atdm:ammo_noisemaker
determines how long the noise arrow plays its player-heard sound.



15.03.2014 19:06

administrator   ~0006441

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:



19.03.2014 00:51

administrator   ~0006445

Last edited: 19.03.2014 00:54

View 2 revisions

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.



19.03.2014 01:07

administrator   ~0006446

I didn't build the binaries, so you're using old code.

I'll do that in a couple hours (watching BBall game).


19.03.2014 01:10

administrator   ~0006447

Sure thing.


19.03.2014 02:10

administrator   ~0006448

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.



19.03.2014 12:20

administrator   ~0006449

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.


24.03.2014 20:19

administrator   ~0006458

Last edited: 24.03.2014 20:21

View 3 revisions

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.



24.03.2014 23:11

administrator   ~0006459

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.


24.03.2014 23:48

administrator   ~0006460

Last edited: 24.03.2014 23:50

View 2 revisions

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?



25.03.2014 03:16

administrator   ~0006461

Acuity factors:

seta tdm_ai_acuity_L5 "1.5"
seta tdm_ai_acuity_L4 "1.3"
seta tdm_ai_acuity_L3 "1.1"


25.03.2014 21:08

administrator   ~0006462

L3 is 1.1? What is the setting for AI at idle alert? I thought that was 1.1.


25.03.2014 21:26

administrator   ~0006463

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.


25.03.2014 21:30

administrator   ~0006464


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.


25.03.2014 22:18

administrator   ~0006465

Ah, that makes sense. Thanks.


05.04.2014 13:05

administrator   ~0006497

Last edited: 05.04.2014 13:05

View 2 revisions

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.



05.04.2014 20:01

administrator   ~0006500

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:



05.04.2014 20:58

administrator   ~0006501

Great idea!

Issue History

Date Modified Username Field Change
06.03.2014 14:01 Springheel New Issue
06.03.2014 14:01 Springheel Status new => assigned
06.03.2014 14:01 Springheel Assigned To => grayman
06.03.2014 16:20 grayman Note Added: 0006412
06.03.2014 17:51 Springheel Note Added: 0006413
06.03.2014 17:51 Springheel Note Edited: 0006413 View Revisions
15.03.2014 19:06 grayman Note Added: 0006441
15.03.2014 19:06 grayman Status assigned => resolved
15.03.2014 19:06 grayman Resolution open => fixed
15.03.2014 19:06 grayman Fixed in Version => TDM 2.02
15.03.2014 19:06 grayman Description Updated View Revisions
19.03.2014 00:51 Springheel Note Added: 0006445
19.03.2014 00:54 Springheel Note Edited: 0006445 View Revisions
19.03.2014 01:07 grayman Note Added: 0006446
19.03.2014 01:10 Springheel Note Added: 0006447
19.03.2014 02:10 grayman Note Added: 0006448
19.03.2014 12:20 grayman Note Added: 0006449
24.03.2014 20:19 Springheel Note Added: 0006458
24.03.2014 20:20 Springheel Note Edited: 0006458 View Revisions
24.03.2014 20:21 Springheel Note Edited: 0006458 View Revisions
24.03.2014 23:11 grayman Note Added: 0006459
24.03.2014 23:48 Springheel Note Added: 0006460
24.03.2014 23:50 Springheel Note Edited: 0006460 View Revisions
25.03.2014 03:16 grayman Note Added: 0006461
25.03.2014 21:08 Springheel Note Added: 0006462
25.03.2014 21:26 grayman Note Added: 0006463
25.03.2014 21:30 grayman Note Added: 0006464
25.03.2014 22:18 Springheel Note Added: 0006465
05.04.2014 13:05 grayman Note Added: 0006497
05.04.2014 13:05 grayman Note Edited: 0006497 View Revisions
05.04.2014 20:01 grayman Note Added: 0006500
05.04.2014 20:58 Springheel Note Added: 0006501