Sound.MaxVolume

[BuilderAtWork]

Basically what the title says, a MaxVolume value for sounds!

Basically I have some scripts in my game that calculate the soundvolume based on a part’s velocity, but sometimes that part can “spazz out” and go really fast making the calculated volume go up to 2 and causing a massive ear explosion for users.

Now I know this can be done by script (If sound.volume >= 1 etc.) but wouldn’t it be nice to have a MaxVolume value for sounds, just like there’s a MaxDistance value? I would love to see this happening.

[Sharksie]

Can’t you just have an upper limit to how high you set your volume? I don’t think I’d ever use a MaxVolume property.

[Osyris]

Agreed, this just sounds like you should be using something like
sound.Volume = math.min(MAX_VOLUME, newVolume)

[BuilderAtWork]

I re-calculate the sound every (0.1) seconds for a group of sounds, while also throttling them not to go over a certain volume in the code itself, but this seems to increase the script activity

[AbstractAlex]

@SimulatorsX

this seems to increase the script activity

Can you please provide a barebones repro of this? I don’t understand how a value clamp would have any noticeable impact.

[BuilderAtWork]

Here’s an example, I don’t think I’m doing it efficient enough though

function Calculate()
Coach.Roll.Volume = 0.1 + Driver.Velocity.Magnitude/50
if Coach.Roll.Volume >= 0.5 then Coach.Roll.Volume = 0.5
end

while true do
wait(0.1)
Calculate()
end

[Polyhex]

Try this instead:

function Calculate()
Coach.Roll.Volume = math.min(0.5,0.1+Driver.Velocity.Magnitude/50)
end

while true do
wait(0.1)
Calculate()
end

[woot3 (Woot)]

I like to avoid using while loops… this will do the job quite nicely.

local p = 0
local min = math.min
local roll = Coach.Roll
game:GetService'RunService'.Stepped:connect(function ()
    local n = tick() % .1
    if n < p then
        local volume = Driver.Velocity.magnitude / 50 + .1
        roll.Volume = min(0.5, volume)
    end
    p = n
end)

[Darkmist101 (Darkmist)]

Things that slowed it down (most-least):

• Always traversing the hierarchy for the same object, instead of making it a variable (Quarter reduction when fixed).
• Constantly calling the function (you only use it in one spot, no need to make it a function).
• Checking the speed after setting it; and then reapplying possibly (Also, should be > only)

This ran twice as fast consistently (100k iterations)

-- Local var here
Sound.Volume = min(0.1 + Part.Velocity.Magnitude/50, 0.5)

[Seranok]

Why would you do that? If I’m not mistaken, connecting to an event will create a new thread every time the event fires whereas a while loop reuses the thread. Seems needlessly complicated and even hurts performance.

[Anaminus]

Events have a secret optimization: A thread is reused as long as the listener doesn’t yield.

Observe how this switches to a new thread only every 100 iterations.

local i = 0
game:GetService("RunService").Heartbeat:connect(function()
    i = i + 1
    print(i, coroutine.running())
    if i%100 == 0 then
        wait()
    end
end)