Sound script changes

We’ve rewritten the character sound system for improved server-side performance.
(Actually, we just got rid of the whole server part.)


  • Avatar sounds will no longer be located in the Head. They will instead be in the HumanoidRootPart.
  • Character.Sound will no longer exist. There will be one script in PlayerScripts named RbxCharacterSounds.

The old system was turning into a server-side CPU bottleneck in games with lots of players. As the number of players grows, the server spends O(players^2) time replicating sounds between players. This was unscalable.
We fixed this by removing all server logic – instead of manually replicating sound states up from clients->server->other clients, one LocalScript just listens for humanoid state changes and triggers them locally. Network overhead is zero.
The speedups can be dramatic; In a 100 player test server, server CPU utilization dropped 40% by switching to the new system.

Finally, moving sounds from Head to the avatar’s RootPart reduces unwanted doppler effects and sound offsets caused by animations.







If you currently fork or replace the avatar sound system, this change won’t affect you.


We’ll be turning the new system on Monday, October 28.

If you anticipate any breakage in your game, respond here or DM me for a temporary opt-out.
If you have forked sound scripts, we recommend unforking to enjoy the performance benefits of the new system!


Finally this has ended, thank you so much!


Since the system is completely local, and individual to each client, it will work regardless.


WOOT! This was a much needed change, thank you again Roblox for these amazing updates!


On a lot of my projects, I usually create my own character sound script because there is no reason for the server to be involved (other than replicating humanoid state changes). Also because I like different material footstep sounds. I am so glad to see this as a default. Great work!


Sweetness!, Sound like it will be a little easier to make custom character sounds as well if i understand right, i still need to get around to increasing the volume of the “oof” for maximum meme effectiveness.


Nice, now I don’t have to make a system to remove these without 5 million warns or errors. I was waiting for this to be all local-sided!


Just when I was thinking of gutting the script too because of the way that it was being handled. Not only have I been saved a few hours of needless work to rectify the problem that was the former sound script, but it’s awesome to see the employment of zero-overhead “replication” via localising everything.

It’s very good to hear that the avatar is still moving forward with improvements, because the avatar is one of the most important aspects of the platform and sometimes there are less-than-desirable effects when working with them. A 40% server CPU use decrease is unimaginably valuable.

A question about the sound script: how scalable is this system intended to be? If a single LocalScript handles playback on its own end, then it could be possible to fork or use the current layout of the new script to be able to handle NPC sound playback as well. That would be awesome!

The change is very much appreciated. The server now has less involvement in potentially expensive operations, the complaints about remote spam can finally end and this provides an indirect good learning resource about relying less on the server.


Amazing. My game is so heavy on server performance, any little bit is greatly, greatly appreciated :slight_smile:


This is going to be so, SO useful. I’ve been using the LoadCharacter function for a system I’ve made where you can select a creature to go as, and I’ve seen a lot of the RemoteEvents exhausted.

1 Like

Will this stop you from hearing another players footsteps? That could be an issue in some games


Given the information in the thread, I assume that what the LocalScript does is log all character humanoids, listen for state changes and play the sounds according to the humanoid’s state. Essentially with that, you get the benefit of a server-driven character sound system with replication by remotes but without actually involving the server.

If this is the case, then you will be able to hear other players’ sounds.


Then wouldn’t it be really easy to exploit it?

1 Like

It shouldn’t be. In what regard to exploiting are you asking for?

Most cases of exploitation are nullified by the fact that it’s client-sided. The server is still involved in the backend when it comes to determining, setting and replicating various states. A client modifying their own character doesn’t quite mean that other clients will be affected by the change as well.

At best, most changes in attempt to leverage the sound system will only affect oneself. I don’t know if you have any specific concerns in regards to exploiting. What’s on your mind? State replication? Changing of sounds? Playback manipulation? So on.


Does this update also stop music/sound exploiters?


I don’t see how that could even happen with RespectFilteringEnabled set to true, unless you are incorrectly replicating sounds in your own scripts.


Just to confirm, this change won’t affect me if I forked the sound scripts like this?15

1 Like

Can we get access to this system early for testing purposes? Even if it’s just giving out a script. It could be handy to test backwards compatibility & prepare for this change.


And the best part: No longer will we be spammed by thousands of errors saying that the remote invocation queues for character sound events are full!


Does this mean that exploiters can no-longer spam death and water sounds for everyone to hear?