Dynamic Sound

[Git-Nivrak]

About the pull request

Makes sounds react to your and its source moving around and become louder\quieter and change direction

Splits sounds into sounds the originate from a location and sounds that originate from a source - sounds that originate from a location will stay put at the location while sounds from a source will move around with the source (For example a Queen screech is a source and being slammed into a wall is a location). Due to this some things will probably not sound right because they should be a source while being a location or vice versa and this will have to be tweaked along when\if this is tested.

You still can't hear sounds if you were completely out of range when they started.

Explain why it's good for the game

It's really cool if it doesn't lag the game to hell and back

Testing Photographs and Procedure

Screenshots & Videos

Put screenshots and videos here with an empty line between the screenshots and the `

` tags.

Changelog

:cl: add: Sounds will now change as you move around their source and become quieter \ louder and change direction code: Added support for sounds having a movable source, simply put the atom as the source /:cl:

[Git-Nivrak]

OD linter should be fixed as soon as it is updated (https://github.com/OpenDreamProject/OpenDream/pull/1870)

[Doubleumc]

I was looking in to a system similar to this. Some observations that may be helpful:

• When you send a SOUND_UPDATE to a sound channel, it applies (almost) ALL of its variables to the playing sound, such as volume which defaults to 100. It is important that the updating sound have the same settings as the playing sound to maintain volume/pitch/etc consistency. Your current system handles this, just noting that it is important that it keeps doing it.
• If performance is a concern the vast majority of sounds don't need the extra handling, they're short enough or soft enough that people won't notice any positional offset. For example, the M41 firing sound is less than a second and people probably won't notice it being off by less than a second's worth of movement. There's no good way to test this in code (getting a sound's duration is very inconvenient) so it would be up to the playsound caller to indicate whether it needs positional updates or not.