 |
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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? |
|
|
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. |
|
|
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." |
 |
Putting this back to 'assigned' because I haven't committed the code yet, nor are we done testing. |
|
|
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 |
- Anonymous
