Don't start oneshot events outside max distance

Unity
1

FMOD: 2.02.22 Unity: 2022.3.51f1

We have the following situation: Player is in the start area and at a greater distance there are several audio sources. Some sources have looping events and some sources have repeating oneshot events. When I enable the “Stop Events Outside Max Distance” behaviour in the FMOD settings in Unity, it only affects the looping audio sources.

So, at the beginning, the looping audio sources that are far away are not started. When I move to these sources and I pass the max distance threshold, the event starts and stops again when I leave the max distance area - so far so good.

Unfortunately, this behaviour doesn’t work for the oneshot events. In the FMOD profiler I can see these events from the start. The instances are active even though the source is far away and also the voice is active and will get inactive after a few mSec. Is there a way to fix this so I have the same behaviour as the looping source?

We are using steam audio spatializer but I have already tried the FMOD spatializer plugins on the oneshot events which doesn`t work either.

For the event we use the Fmod Studio Event Emitter component in Unity and start it with sound.Play() in the code.

Calling the oneshots by code with a distance check would be an option but it requires extra calculations. But the strange thing is that it already works with the looping event.

2

Hi,

Thank you for bringing this to our attention. I have been able to reproduce the behavior. I will pass on the suggestion to update this behavior to our development team to investigate further.

A work around would be updating the following line in the StudioEventEmitter.cs:

Line 236:
if (is3D /* && !isOneshot */ && Settings.Instance.StopEventsOutsideMaxDistance)

Please note that the oneshot will trigger every time the player enters the audible range, unfortunately, this will require more changes to fix.

3

Thank you for your reply! I tried your work around (for me this code is in line 214) and did some quick testing: The thing is that this workaround only works if you stop the oneshot event again via code. Because we work with steam audio, we have an audio manager for optimisation purposes, which starts an event, calls the clip length and then stops the audio source again after the clip has finished playing. So with an extra Stop() command for the oneshot this work around works.

But for example, if I have a studio event emitter with Play Event set to Trigger Enter, this workaround causes a loop for the oneshot event after the trigger. You can also see it in the profiler: This event should only be played once.
grafik

Do you know a solution how to prevent this behaviour with the workaround or is this a compromise that you have to live with?
Thanks in advance.

4

Thank you for testing that.

This is the issue with the workaround. This will be addressed when the task in investigated further and part of a full update.

5

Alright. If possible, please let me know here if there is an update in this regard.

Thank you

1 Like
6

Will do