public struct NetworkAudioSourceWhether a sound is playing, and how — not the sound.
No guide page documents this yet — the page shows what the code says about itself.
Remarks
No clip on the wire. Not a simplification: the entity carrying this was spawned from a prefab, and the prefab carries its AudioClipRef, so both peers already agree about which sound this is by the same mechanism they agree about which mesh it has. Sending a clip id would be re-stating a fact the spawn already established, and it would mean a second asset registry to keep in step with the first.
What this is not for is a one-shot at a world position — an explosion, a footstep, a UI click. Those are events, and modelling an event as replicated state means a player who joins five minutes later hears the explosion. They belong on a broadcast or an RPC, both of which happen once and reach who was there. This is for sounds with a state worth agreeing on: an engine that is running, an alarm that is sounding, a machine that is humming until somebody switches it off.
Trigger is what makes "again" visible, and it is the same trick NetworkTransform.TeleportCount uses for the same reason. Playing a one-shot twice sets Playback to the value it already had, so a receiver comparing states sees nothing and the second shot is silent. A counter that moves is a change even when the state it accompanies has not.
Fields and properties (4)
public byte PlaybackWhat it should be doing, as AudioPlayback.
public byte TriggerBumped to say "start it again". Wraps, and only inequality is ever asked of it.
public float GainIts linear gain.
public float PitchIts playback rate multiplier.
Used by (5)
- NetworkAudioApplySystemVixen.Net.Audio
- NetworkAudioCaptureSystemVixen.Net.Audio
- NetworkAudioSourceReplicatorVixen.Net.Audio
- NetworkAudioTestsVixen.Net.Audio.Tests
- Vixen_Net_Audio_NetworkAudioSourceSerializerVixen.Net.Audio