The title explains the problem. Setup: Place an an AudioPlayer with IsPlaying & IsLooping set to true into a part within workspace and wire it into an AudioEmitter.
Expected Result: Upon loading in, the AudioPlayer will still Have IsPlaying set to true, and the audio will be audible.
Expected behavior
Actual Result: Upon loading in, IsPlaying is false, and the audio is not audible.
This is a basic functionality that was part of the old Sound instances which are now deprecated. This was a very important feature & optimization for simplifying smaller games such that developers didn’t have to manually program these audios to start via local script, or a server script which does AudioPlayer:Play() every time a new player joins such that it actually replicates.
Hey @Wayyllon – counterintuitive, but this is expected & intended behavior.
Sound.Playing serializes/saves, which is convenient for “start playing as soon as this spawns”-type behavior, but designed us into a corner when it comes to studio edit-time.
It would have been annoying if Sound.Playing started playing at edit-time just as it did at runtime, so we had to add exceptions, preventing Sounds from playing while time is stopped. But studio plugins wanted to play sounds, so we had to add exceptions that allow Sounds to be playable if they’re descendants of a PluginGui.
AudioPlayer.IsPlaying does not serialize, which means we can make AudioPlayer:Play() work identically at edit-time and runtime – edit-time playback does not tamper with runtime playback.
But it means if you want exactly the same “play on start” behavior, you’d need to write a local script like
script.Parent:Play()
and add it as a child of the AudioPlayer (or do something similar)
I recognize this is more inconvenient; we’re kicking around ideas to make this easier without imposing on plugin developers
I guess I understand the thought process behind the functionality but I also feel that needing a local script for everything is too clunky a solution to be permanent. Especially in the case of map items such as electrical boxes, fans/ventilation, lights. It’s a lot of setup that was previously very simple through use of the now deprecated sound instances. Why isnt a PlayOnRuntime property possible? In my mind most people will solve this using the Tag API if another solution isnt provided, so maybe just have a built in tag which will make audios play on runtime so that the properties menu doesnt get cluttered and developers dont have to worry about it. I’m not the developer of course, so I’ll shut up.
Also if this is going to be the case for a while/foreseeable future, is it safe to still use sounds or are you guys planning to entirely deprecate sound instances at some point in the near-ish future?
Too much content depends on Sound to feasibly deprecate or delete it any time soon – mainly we recommend using AudioPlayers because of Wires being able to support both one-to-many and many-to-one mixing (previously, we only supported many-to-one via SoundGroups)
A property like PlayOnRuntime is one solution we’ve discussed – in my own code, what I’ve done is parent a Script with RunContext = Client to an AudioPlayer, and then clone/reparent that AudioPlayer at runtime (which takes the script with it)
Thank you for the additional information, I think I’ll end up just using the tag system, but could you explain your solution in the second paragraph in further detail? I have also just learned that local script can be executed while in workspace like that using the RunContext enum, thank you for that. Anyways, I get a little tripped up near the end, why is it necessary to clone and reparent the audio player instead of doing script.Parent:Play()? (which i just tested and it does work, my wire went missing)
Thank you for the clarification & additional context. I believe the tag system will work well for my use case of ambience & avoids the extra scripts so i’ll likely go for that, but your solution does make sense too.
