AudioComponents can now set volume on client side

[TGRCdev]

This PR adds an additional argument dirty to the SetVolume and SetGain methods.

I've been trying to set up a jukebox volume slider for a few days, and the only way I can get volume changes to change on client-side is by preventing the component from being marked as dirty on the client.

[ElectroJr]

This solution doesn't really work. Anytime the server or client dirties the audio component for whatever reason, it will still override your volume modifications.

A better solution would probably be to add some client-only / non-networked fields called something like VolumeModifier or VolumeOverride that either modify or override the networked volume.

Though for the actual issue you're trying to solve in space-wizards/space-station-14/pull/32391, what we really need is a proper way of categorizing audio and having per-category volume customization. This is would probably take some effort to add, but I feel like its probably better to do it properly instead of trying to hack around the problem.

[TGRCdev]

I understand that this is not the ideal refactor for client-side audio. But the changes do work, and the hack used to make it work in my related PR are small and relegated to the client-side JukeboxSystem file.

In that PR, I added a line to the AfterHandleAutoStateEvent handler, which would catch if the network actually dirtied and replicated the AudioComponent, and sets the proper volume again. Under that, I also set the volume of every active jukebox audio stream when the CVar is updated.

In the case that we later add properly categorized audio and proper client-side variable overrides, these can be replaced with the correct system easily.

[metalgearsloth]

I understand that this is not the ideal refactor for client-side audio. But the changes do work, and the hack used to make it work in my related PR are small and relegated to the client-side JukeboxSystem file.

In that PR, I added a line to the AfterHandleAutoStateEvent handler, which would catch if the network actually dirtied and replicated the AudioComponent, and sets the proper volume again. Under that, I also set the volume of every active jukebox audio stream when the CVar is updated.

In the case that we later add properly categorized audio and proper client-side variable overrides, these can be replaced with the correct system easily.

For engine audio I would prefer it done properly instead of mispredicting and relying upon specific scenarios to avoid it breaking.

[metalgearsloth]

This is would probably take some effort to add, but I feel like its probably better to do it properly instead of trying to hack around the problem.

I think you can mix audio together in OpenAL with some of the EFX stuff but I didn't look heaps into it.

[TGRCdev]

My college courses start up in two days, so I don't have time to deep dive into OpenAL and refactor the engine's client-side sound functionality. I'm afraid that you'll have to ask someone else to make the correct version of this change.