Setting up Individual Propagated Sounds and Estimating Volume

Originally written by Ishtvan on http://forums.thedarkmod.com/topic/3271

Defining Local Sounds on the Entity

Setting up propagated sounds in the Dark Mod works very similar to setting up audible sounds in vanilla D3. Whenever D3 plays an audible sound on an entity, there must be a "local" definition of the sound in the entity def file. This take the form of "snd_<sound name>" followed by the name of a sound shader, which is defined in detail elsewhere. When TDM plays a propagated sound, it looks for a local definition on the entity "sprS_<sound name>" for suspicious sounds, and "sprE_<sound name>" for environmental sounds (not yet implemented). This is followed by a global name for the sound, which is defined in detail elsewhere (just like sound shaders).

Subject to Change: In the current build, only sounds that you can actually hear can be propagated. I.e., the "sprS_<soundname>" soundprop sounds are only propagated when D3 plays an "snd_<soundname>" audible sound of the same name. A script function is planned to propagate suspicious sounds directly without the need for an audible sound, if desired. (This could be useful in using soundprop to simulate gas diffusion, AI communication, and other things).

Defining the "Propagated Sound Shader" or global sound definition

After defining the local sound on the entity, and referencing it to a global sound definition, you must enter the data for the global definition. Currently, all propagated sounds are stored in /def/tdm_propagated_sounds.def, although like sound shaders, soundprop shaders may be distributed among many files if desired.

If you look at that file, you can see some sounds that are already ingame. The following data may be entered for a given sound:

Entitydef Name

Soundprop shaders are regular entity defs that are recognized as sounds by the prefix in the name, which must be exactly this: "sprGS_<soundname>" for suspicious sounds. For example:

entityDef sprGS_footstep_default

Inheritance

key: "inherit" value: Name of another soundprop shader

Soundprop shader defs are treated like any other entitydef in Doom3, so a soundprop shader can inherit other soundprop shaders.

Volume

Key: "vol" value: SWL [dB]

For these sounds to have any meaning to the AI, you must enter a volume. See below for an in-depth discussion on choosing an appropriate volume.

Duration

Key: "dur" value: time in milliseconds

This is not yet implemented, and may never be. Don't worry about it. (Default is 200 ms)

Team Alert Flags

For optimization reasons, suspicious sounds are not propagated to AI that would not care about that sound.

When a sound comes from an AI, the following flags describe how AI on other teams respond to this particular sound. These flags are set or unset by putting "1" or "0" in the value spot after the flag name.

"alert_same" : Alerts the same team (eg, cry or help) "alert_friend" : Alerts teams that are friends with the AI/player who made the sound "alert_neutral" : Alerts teams with a neutral relationship "alert_enemy" : Alerts teams that are enemies of the AI/player who made the sound

The default setting is "alert_enemy" only.

Other Flags

Other flags propagation flags are planned, but not yet finalized. This spot will list additional propagation flags.

AI Messages

Propagated sounds are also able to deliver a "message" to other AI. This is handled by the code and cannot be directly influenced by the mapper right now.

How the System works

This should illustrate how the AI sound propagation code in TDM works, based on a fictional example of a moveable book:

1. The moveable book collides with something. The code looks up the name of the sound shader to play.
2. The sound shader behind the spawnarg snd_bounce is taken and played. You as a player will hear the corresponding sound(s).
3. The AI sound propagation code will take the suffix "bounce" and tries to look up a spawnarg called sprS_bounce on the same entity.
4. This sprS_bounce defines the "soundprop def", i.e. the properties or characteristics of the sound as perceived by the AI. (If no such spawnarg is found, nothing will be propagated to AI.)
5. In this example, the soundprop def named bounce_default is defined. The code will add the prefix sprGS_ and tries to find the entityDef with the name sprGS_bounce_default.
6. The properties from the entityDef sprGS_bounce_default are loaded and the sound will be propagated. Any AI in range will perceive this sound and react accordingly.

Soundprop Shader Examples

In propagated_sounds.def:

\\ footstep sound
\\ note I don't need to put "alert_enemy" "1" here because that's the default.
entityDef sprGS_footstep_default
{
   "vol" "42.6"
} 

\\ this is a battle cry when entering combat.  Should alert friends
entityDef sprGS_prelate_combat
{
   "vol" "75"

   "alert_friend" "1"
}

Advanced Usage: Volume Modifier in the Local Sound Def

Suppose you want to add a bunch of sounds at slightly different volumes, but you don't want to create a whole new soundprop shader for each of these sounds. It's possible to use the same soundprop shader but modify the volume in your local sound definition (i.e., the sound on the entity def file). The syntax is:

• key: "sprS_<local sound name>"
• value: "<soundprop shader>:<volume offset in dB>"

The offset in dB gets added to the volume of the original sound. For example, I did this with the player footstep sounds at different movement speeds:

In tdm_player.def:

"sprS_footstep_walk"    "footstep_default"
"sprS_footstep_run"     "footstep_default:5.4"
"sprS_footstep_creep"   "footstep_default:-7.7"