Existing events versus custom banks
Playing an existing registered sound event is a runtime integration task. Shipping new audio is also an asset-build task: the bank, event registration, package paths, and teardown behavior must all match the target client. Prefer existing events unless the feature genuinely requires new audio.
Audio and music lifecycle
Audio integrations are split between lightweight event playback, formatter-owned notification sounds, and larger music or voiceover systems. Verify the resource path, event identifier, priority mapping, and current context before changing playback.
- Resolve VFS resources and verify they exist before installing playback hooks.
- Patch battle or hangar audio points narrowly and restore only wrappers still owned by the mod.
- Keep playlist or rotation state account-scoped when it depends on player preferences.
- Do not assume an event constant and priority mapping can be changed independently; inspect the caller that chooses both.
- Fail without breaking unrelated sound when an optional audio resource is missing.
For outgoing text and messenger channels, see Messenger & Chat.
An announcer request is not a playback receipt
IngameSoundNotifications.play() can reject a request before voice scheduling. FX submission precedes the voice category/queue gate, so FX and voice admission differ. After predelay, waiting items capture their enqueue time and priority. Higher priorities go first, equal priorities keep insertion order, and later priority overrides do not reorder existing items or interrupt the current routed event.
Queue lifetime is periodically pruned, not rechecked at selection: an item past its lifetime can still be selected before the next pruning tick. Selection instead rechecks cooldown, entity existence and, for a current Avatar, the supplied predicate. The shot-result caller supplies a predicate that rereads the target's arena isAlive; eligibility can change while waiting. Predelay is outside the queued lifetime.
onAddEvent is emitted only by the occupied-queue branch. onPlayEvent routes a selected/current event into the visual-script context; replayLastQueueEvent() can emit it again. Neither signal proves audible output or native completion. Selected-method checks with inert queues, clock, entity and event sinks corroborated ordering, captured priorities, expiry and predicate rejection. No audio, visual-script plan, native calls, installed-bytecode parity or Python 2.7 runtime was exercised.
Sound handles and shared state
SoundGroups distinguishes a retained 2D handle, a global event, a node-bound 3D handle and a positional event/emitter. Native code can explicitly play/stop retained handles and stop an emitter on leave-world. Those are owner-local operations; global states, switches and RTPCs affect shared sound context.
playSafeSound2D checks a truthy name but does not verify a bank, catch playback errors or return the playback result. Its name is not a safety contract. Replay time-warp suppression belongs to the native battle wrapper; direct SoundGroups calls do not inherit that policy automatically.
Named view sound spaces can share a manager and cached handles by event. Two owners asking for one event can receive the same handle; one owner's cleanup can stop it while another owner remains. The manager's owner map is not per-playback reference counting. Do not reset another scene's sound state during teardown.
Volume preferences and audibility
setVolume with updatePrefs=False changes the applied bus without replacing the stored preference returned by getVolume. A temporary zero can therefore coexist with a positive configured value. Preference readback, a volume-change event, a valid handle and actual audible output are separate evidence.
Muffling uses one boolean rather than a nesting counter. Repeated muffle calls do not acquire independent ownership; one restore can clear the shared state. Window visibility and replay policy also affect application. Restore only the temporary state the feature owns, and choose preference persistence deliberately.
National voice mappings validate/configure metadata before a later nation selection applies a language. Bank-file validity can be cached and does not establish loading or available events; special vehicle/crew/skin paths can override ordinary nation selection. This guidance is based on source and controlled WWISE sinks, not audible validation. For separate Gameface video-audio results, see Media and Rendering.