Do Sound Files Have A Maximum Number of Times It Can Be Played in a Short Time?

Help and Feedback Art Design Support
#1

The Minigun in my game, Redshift Arena, has three sound files that work together to make it sound like a Minigun. Here’s the problem though:

The firing sound, which is about 0.1 seconds long, becomes muted after 5 seconds of firing the minigun, at which point the Minigun has drained about 100-150 bullets, and all you hear is the winding of the barrels.

Is there a way to fix this by any chance?

1 Like
#2

Would you mind sharing a repro?

2 Likes
#3

Sure thing. .

Have to give me a second or so. .

It could be an issue only present in studio as well. Haven’t checked yet.

Alright, so.

Have a while true do loop like this:

while true do
wait(0) --firing speed of minigun
local sound = minigun.Main.Sound --sound id is 2599874024
sound:Play()
end

It also affects in-game too. I’m thinking I’m playing the sound too many times.

1 Like
#4

That seems like it would create a lot of interesting… noise?

I don’t know how good this would be for performance but you could try making a new sound when firing instead of using one.

Also “wait(0)” is the same as “wait()”

4 Likes
#5

You could just clone the sound, set PlayOnRemove to true, then destroy the sound after parenting it to the part that the sound comes from. Playing a sound while it’s playing cuts out the sound to repeat it, which can cause the sound to mute completely.

6 Likes
#6

That sounds like a pretty ugly hack. Not sure if it is one, but that sounds like one.

Interestingly enough, I haven’t had much issue with rapid playing sounds. Probably has to do with the fact that I’m not calling it in extremely rapid succession for long periods of time. I just call Sound::Play on the Sound object itself and that’s that.

2 Likes
#7

PlayOnRemove was arguably designed as a legacy “hack” to solve some kind of problem where you needed to both destroy a sound and play it. Just a remnant from old ways of doing things using sounds. I wouldn’t advise using it either. :no_good_woman:

@TheRings0fSaturn
What you should be doing, if you want to accomplish the same thing as PlayOnRemove mentioned above, is to create a new sound instance, play it, wait for it to end, then destroy it. I modified your existing code as an example:

local soundTemplate = minigun.Main.Sound
while true do
    wait(0) -- Note: You don't actually need the 0 here. Just using wait() is enough.
    local newSound = soundTemplate:Clone()
    newSound.Parent = soundTemplate.Parent
    newSound.Ended:Connect(function()
        newSound:Destroy()
    end)
    newSound:Play()
end
6 Likes
#8

Is there a specific reason as to why PlayOnRemove is a bad idea? The sound isn’t looped, so it won’t indefinitely play forever. The property itself also isn’t deprecated to my knowledge.

Wasn’t aware of some of the sound API available however, so this helps in a few other areas as well.

EDIT
Found out why by testing both.

Your method doesn’t have the Doppler effect that I’ve been trying to solve for a while now when it comes to setting sounds to play on Remove.

1 Like
#9

When there is some kind of function or property that was made with one super specific use case in mind, and there is a more flexible alternative, I would personally not use it, deprecated or not.
For example, the debris service only does one thing, namely removing an object after some time has passed. Compare these examples of removing an object after 5 seconds:

local debris = game:GetService("Debris")
debris:AddItem(object, 5)

delay(5, function()
    if object and object.Parent then
        object:Destroy()
    end
end)

This is great! I just saved 3 lines of code by using the Debris service! Is what you might think. But the problem arises whenever you want to extend this to do something else. Let’s say you suddenly want to cancel the object from being destroyed from some reason. What do you do?

This is more of a general kind of opinion, being that, if there is a more extensible solution available, and it’s not slower, it’s not more effort to implement, then you should use it instead. It might save you time and headaches in the long run.

As for PlayOnRemove specifically, once the sound has been destroyed, you can’t change its position (parent) anymore. The sound source won’t move if the part it was played in was moved after it got destroyed. This might be what your issue was, and is the main reason why I wouldn’t use it.

2 Likes