That’s it. Too much workaround just to play a sound on a button that disable on click.
Move the audio source or create specific gameobjecrt with audiosource that never is destroyed or disabled
Try to avoid having too many AudioSource for performance.
Having one AudioSource which is never destroyed (not even when changing scene) is usually a good idea, especially for the UI.
voices playing count are the main culprint for audio performance no ? should be ok to have many audio source if they dont play all at the same time ?
AudioSource inherits from Behaviour, and an underlying, well, behaviour, of all Behaviour components (including MonoBehaviour) is they stop their behaviour when disabled.
And needless to say this would be a breaking change that would affect tons of existing projects that use this existing behaviour the way it is intended.
It’s not to difficult to set up an audio pooling system that lets you dispatch audio clips without needing a direct reference to an audio source.
Not sure, I have never profiled a huge number of AudioSource.
Long ago, when I saw how much having lots of GameObjects could reduce the performances, I decided to avoid using things I’m not sure about if it’s not necessary.
Having one AudioSource for all UI isn’t hard to do, you just call a method to emit a sound and that’s it.
And if you want to change the ‘click’ sound, just doing it at one place will change it everywhere.
This will play a sound that will continue to play after the button has been disabled.
1 Like
really tired of that paradigme that puts the brakes on software evolution. Just keep the same unity you started your project with. Meanwhile new projects could enjoy a light and fresh Unity.
I said “Too much workaround” yet all people came to comment about how to workaround. sick.
I just want to say unity should spend more time at refactoring basic tools rather than to make more workarounds to keep old ugly features compatibility.
There is no point to even stop the sound while playing when audiosource is disabled. This make most of the sounds clipping.
It could just be a checkbox in audiosource setting. “stop on disabled” and that’s all. No more workaround, separated source, pool, whatever. And I could just test this UI without any wasted time. I’m dreaming.
It might be evolution if it made sense. But when I disable a component or a game object I expect it to be disabled. Imagine if a rigidbody didn’t stop simulating when disabled? Having a configurable option doesn’t make sense either.
If you don’t want it to be disabled, don’t put it on an inactive game object. Put it on a sibling. Very normal day to day Unity things to do.
And Zulo solution is also about as trivial to use as it gets.
That’s quite already happening :
https://docs.unity3d.com/ScriptReference/MonoBehaviour.OnTriggerEnter2D.html
Trigger events are sent to disabled MonoBehaviours, to allow enabling Behaviours in response to collisions.
https://docs.unity3d.com/2017.4/Documentation/Manual/Coroutines.html
Note: Coroutines are not stopped when a MonoBehaviour is disabled, but only when it is definitely destroyed. You can stop a Coroutine using MonoBehaviour.StopCoroutine and MonoBehaviour.StopAllCoroutines. Coroutines are also stopped when the MonoBehaviour is destroyed.
Disabled game objects are not dead. They still exist, they can be found with an optional FindObjectOfType(bool includeInactive); , they run and check things, and they have configurable options and calls because it is better for some use cases.
Now compare the advantages and disadvantages of having audiosources running with disabled game objects. It make life only easier.
and this is a workaround, not a solution. PlayClipAtPoint() instantiate from a script (more work) a poorly configurable audiosouce with its performance overhead. ugly.
In general if if you can do more while it is simpler, it is the right way.
I agree that unitys lack of performance by default is bad. But you need to fight the right fight. In our game domain takes 0.5ms rendering takes the rest.
Both of those examples are to do with disabled components and not game objects. The documented definition of .enabled is disabled behaviours aren’t updated. So that would not preclude a monobehaviour receiving physics events.
Coroutines are managed by the game object and not the monobehaviour. Yes it will continue if the component is disabled, but when the game object is disabled they stop. You’ve linked to really old documentation on coroutines for some reason, their behaviour is better explained in newer versions of the manual: Unity - Manual: Coroutines
FindObjectOfType(bool includeInactive); was added from user feedback, which is good, and it also doesn’t change any existing API behaviour either, so it’s a bit of a no brainer addition.
AudioSource’s broadcast their audio based on being updated, and AudioListener’s recieve audio also based on being updated. Disabled behaviours aren’t updated, so this is how things end up working.
Yes bad examples I should have pick Invoke or async/await or any custom update call from scripts. Anyway these sound behaviors should not be that rigid to me it does not help for fast iteration.