View Issue Details

IDProjectCategoryView StatusLast Update
0003660The Dark ModAIpublic14.09.2017 03:33
ReporterSpringheel Assigned Tograyman  
PrioritynormalSeveritynormalReproducibilityhave not tried
Status resolvedResolutionfixed 
Product VersionTDM 2.01 
Target VersionTDM 2.02Fixed in VersionTDM 2.02 
Summary0003660: AI "yells" not propogating properly?
DescriptionThere was that video where a priest yelled for help and guard at the other end of the hallway didn't hear a thing. And I just did a massacre in Fauchard while testing, and I was able to engage guards in combat and kill them while friendlies strolled by unaware a short distance away.

Needs further testing. Either yells aren't propagating properly, or we should look at increasing the volume or something.
TagsNo tags attached.

Relationships

related to 0001059 closedIshtvan Melee Strike Near AI Can Lead to Soundprop Crash 

Activities

Springheel

Springheel

16.02.2014 03:13

administrator   ~0006399

Last edited: 16.02.2014 03:32

View 5 revisions

Ok, doing a simple test with a long room and 3 AI set to acuity_vis 0. I shoot one AI in the head and test the reactions of AI at varying distances.

1. When I elicit a death bark, the AI 380 units away draws his weapon and runs to the spot.

2. As above, AI at 1000 units away does not draw his weapon, but goes to Alert 3 and runs towards the general vicinity of the sound.

These results seem right but do not support what I witnessed earlier in Fauchards. Will test with visportals.

Springheel

Springheel

16.02.2014 03:50

administrator   ~0006400

Ok, we've got a potential problem.

When I added two visportals, I noticed that the further AI seemed to be alerted for less time. I added two more visportals between the two AI, and the furthest AI was only alerted to level 2.

The number of visportals should not have an impact on how much sound reaches an AI.
Springheel

Springheel

16.02.2014 04:23

administrator   ~0006401

A further test. I lowered the size of the ceiling of the hallway (which was quite high in the original tests) to right above the AI heads. The visportals still reached to the height of the original ceiling. There was no change. However, when I lowered the height of the visportals to match the new ceiling, the AI went back to level 3 alert and ran all the way to the body.

What this suggests to me is that the wiki is incorrect when it says "Sound going to the AI travels the shortest distance through a visportal, passing at any point on the visportal surface."

I remember early in development, someone (Ishtvan?) said that sound going to the AI went to through the MIDDLE of a visportal. However, I was since lead to believe this wasn't the case. But the results of my tests seem to suggest it is. When the 4 visportals are taller, less sound gets to the AI.

To confirm, I raised the height of the ceiling to 1700 units. The AI 1000 units away did not get alerted at all with that change. So it definitely has to do with the height of the visportals. For a final test, with the 1700 high ceiling, I reduced the visportals to 1. The AI went to level 3 but only briefly. So both number and height seem to play into it.
Springheel

Springheel

25.02.2014 22:14

administrator   ~0006405

Last edited: 25.02.2014 22:15

View 2 revisions

Ok, grayman has addressed the issue so that large portals don't seem to be causing problems now. However... a "yell" has a propogation volume of 58. A fire arrow has a value of 55. Yet shooting a fire arrow at the spot where the first AI is only sends the distant AI to alert1. Seems too low. Investigating.

edit: Oh wait, a "yell" has an "alert_factor" "2" spawnarg, which I think doubles the amount it alerts an AI. That might explain it.

Springheel

Springheel

25.02.2014 22:34

administrator   ~0006406

Testing in Fauchards, I had a case twice where I overtook and killed the first guard as he turned the corner. It took at least two or three hits, during which he should have had time to call out. Although three lines went from him to the nearest guard, about 740 units away, none were enough to alert the guard to Level 1.

There should have been multiple "yells" during that time. Why was the second guard not alerted?
Springheel

Springheel

25.02.2014 23:24

administrator   ~0006407

Last edited: 25.02.2014 23:26

View 2 revisions

In my testmap, range of 1000 units:

Attacking the close guard and killing him brings the far guard running at Alert3. The close guard never gets a chance to play his to_combat bark--two hits kills him.

Attacking the close guard and allowing him to play his to_combat bark brings the far guard running at Alert4.

Springheel

Springheel

06.03.2014 14:50

administrator   ~0006410

Solved. For future reference:

"At initialization, all sound areas are given a default loss multiplier of 0.015. (Think of a sound area as the space between visportals.)

After that's done, the location entities are read, including a loss multiplier for each location. This multiplier is assigned to every sound area inside the location area.

Even though the comment on the location entity's "sound_loss_mult" spawnarg says that this value is multiplied by the default 0.015, that never happens. Whoever wrote the location entity code forgot to do the multiplication.

So, when location entities are present (they are in Fauchard, and they're not in Spring's test map), the default 0.015 values are overwritten by 1.000, which is the default "sound_loss_mult" for location entities. This value is then multiplied by the sound distance traveled (in meters) to arrive at an attenuation value, which is added to the loss, reducing the volume.

So whenever a location entity is used, we're getting an attenuation value that's 1/0.015 = 66.67 times larger than it should be. This can create considerable volume loss."
grayman

grayman

06.03.2014 15:02

administrator   ~0006411

Putting this back to 'assigned' because I haven't committed the code yet, nor are we done testing.
grayman

grayman

08.03.2014 23:50

administrator   ~0006420

1 - Wave expansion shouldn’t use the portal centers.

2 - Voices originate at the head, not the feet.

3 - The minimum volume needed to continue expansion is based on the minimum thresholds of the listening AI, not on a fixed 15dB. This allows a wave to terminate sooner on a path if it ultimately isn't going to be heard by a listener, saving some time.

4 - Use the optimization pass if there are 6 or fewer portals on the path. It was 3. Spending more time here is okay because we’re spending less time later on detailed optimization.

5 - Apply a distance check when looking for potential listeners, instead of a bounding box. This can drop AI from the list of listeners, saving time.

6 - Simplify how the point where a wave touches a portal is calculated.

7 - Check whether a candidate AI is currently deaf. This can happen in the window between preprocessing an alert and processing the alert. We don’t want suspicious sounds reaching an AI inside that window. Since they’re in the process of being alerted by something else, it’s okay.

8 – Correct the missing location sound loss multiplier. This was causing attenutation through locations to be ~67x larger than it should have been, making the sound drop off considerably faster. This was the major discovery of the overall fix.

9 – Correct the way “AI Loss” was being applied across portals. It was being double-counted in the detailed optimization pass.

10 – Correct the way the “area visportal center” was being calculated. It was calculating the average portal center for every portal in the map, rather than calculating the centers of the portals bounding an area. (I don’t think this matters, though, because I couldn’t find anywhere this was being used.)

rev. 5937:

Entity.cpp
SndProp.cpp
SndProp.h
SndPropLoader.cpp
SndPropLoader.h

Issue History

Date Modified Username Field Change
25.01.2014 20:14 Springheel New Issue
16.02.2014 02:12 Springheel Assigned To => Springheel
16.02.2014 02:12 Springheel Status new => assigned
16.02.2014 03:13 Springheel Note Added: 0006399
16.02.2014 03:15 Springheel Note Edited: 0006399 View Revisions
16.02.2014 03:16 Springheel Note Edited: 0006399 View Revisions
16.02.2014 03:32 Springheel Note Edited: 0006399 View Revisions
16.02.2014 03:32 Springheel Note Edited: 0006399 View Revisions
16.02.2014 03:50 Springheel Note Added: 0006400
16.02.2014 04:23 Springheel Note Added: 0006401
25.02.2014 22:14 Springheel Note Added: 0006405
25.02.2014 22:15 Springheel Note Edited: 0006405 View Revisions
25.02.2014 22:34 Springheel Note Added: 0006406
25.02.2014 23:24 Springheel Note Added: 0006407
25.02.2014 23:26 Springheel Note Edited: 0006407 View Revisions
02.03.2014 22:53 grayman Assigned To Springheel => grayman
06.03.2014 14:50 Springheel Note Added: 0006410
06.03.2014 14:51 Springheel Status assigned => resolved
06.03.2014 14:51 Springheel Fixed in Version => TDM 2.02
06.03.2014 14:51 Springheel Resolution open => fixed
06.03.2014 15:02 grayman Note Added: 0006411
06.03.2014 15:03 grayman Status resolved => assigned
08.03.2014 23:50 grayman Note Added: 0006420
08.03.2014 23:50 grayman Status assigned => resolved
08.03.2014 23:50 grayman Target Version => TDM 2.02
14.09.2017 03:33 nbohr1more Relationship added related to 0001059