Plugins cannot play sounds that are not a descendant of a DockWidgetPluginGui. When Play()
is called on a sound, it will set the Playing
property to true, but it will not play any sound. This behavior negatively impacts developers who create plugins that don’t use widgets (as widgets do not work with UserInputService) and need to play an audible sound. Developers are then forced to create a clunky workaround of creating a ghost widget to parent and play sounds from. There is no point in restricting plugin access to play audio.
Hey FartedTooHard; I feel your pain, and have run into this as well. Several years ago we made it so that Sound.TimePosition
doesn’t advance in the studio editor – so even if you set .Playing
to True
, the Sound doesn’t actually play until you enter Play-mode.
Now, many developers use workflows that depend on this – for example, setting .Playing
and .Looped
to True
in the editor to make a sound start playing and looping as soon as it spawns & loads.
If a Sound
is a descendant of a PluginGui
, we can be reasonably sure that it’s only intended for plugin use, so we added an exception to let TimePosition
advance anyway. But this is definitely not a great, general solution; it’s more like a workaround that we added to make plugin development slightly less restrictive.
Making substantial changes to Sound
without breaking someone’s workflow is really tricky; however, we announced a new AudioPlayer instance at RDC! This API is not officially released yet, but AudioPlayer
s (and many of the other new instances) are already enabled.
Unlike Sound
s, AudioPlayer
s are fully-playable in the studio editor – since it’s a brand new instance, we didn’t have to worry about unintended breakage, and their behavior should be much friendlier to plugins
I’ve played around with AudioPlayer
already by messing with some internal flags. Im curious what exactly would be the output source here that could be wired into.
AudioDeviceOutput is the final output, so stuff that’s wired to one of those will be heard. To play and hear an AudioPlayer
, you could set up something like AudioPlayer
→ Wire
→ AudioDeviceOutput
.
But, you could also wire the audio to other stuff along the way; for example:
AudioPlayer
→ Wire
→ AudioReverb
→ Wire
→ AudioDeviceOutput
Or in the case of 3d spatial audio:
AudioPlayer
→ Wire
→ AudioEmitter
& AudioListener
→ Wire
→ AudioDeviceOutput
does audio device input work yet or is that still a wip?
That one is currently disabled; you can create them, but they make no sound (yet) – we’ll update the docs (currently blank) and make a proper announcement once all of the new instances are ready to use
okay thanks and will it only be able for voice chat users to use or will everyone have access to it
The AudioDeviceInput
instances themselves can be created anywhere, but they won’t necessarily make sound, depending on factors like voice eligibility
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.