I have created a simple system that pretty efficiently, stops sounds that are caught going over a set maximum PlaybackLoudness multiple times. This is all customisable and simple to use.
To add a sound to the system after following the instructions in the model, all you need to do is have this line of code under wherever it is played. This doesn’t need to be fired more than once per sound instance.
All instructions on how to use it are in the model in the “READ ME” module. It also includes the Roblox boombox gear with this already implemented. To customise it, the settings are located at the top of the “RadioHandler” script.
The method the other thread was using was very poor and he refused to change it. Mine runs completely different and done through a single remote event, rather than iterating through every instance in the entire game. If you prefer the other method, feel free to use it.
I’m not looking for any method to do anything, just looking around. But this also has a problem, why use a remote event? It already can be done purely on the client.
It is done on the client. The server just passes the information through the remote event to the client. Otherwise the client has to search through new descendants for a possible radio, and that might not work with some peoples radio systems including mine.
No I don’t think I have. If you read my previous post you’d understand why I didn’t use that. If you have a problem with it then you don’t have to use it.
Thats unprofessional unless your using a only radio game. Sound Groups can fix this. You can also make as soundgroup for each player who joins who owns a gamepass or if the game with radios for free then you can just make it so when they join it gives them a sound group and when they leave it destroy’s.
That’s not for a radio system. That just destroys every sound in workspace that has a playbackloudness over set loudness. That will just break most peoples games.
@maumaumaumaumaumua Descendant and ChildAdded are incredibly resource intensive functions if you’re running them on the DataModel just to catch radio sounds. You’ll have an event firing for every addition which will tank performance. You might want to set aside your distaste for remotes here - remotes are a better option.
That being said, on another note, you can use CollectionService here to help out in removing loud sounds which can also be a minimal network footprint solution. Chances are that if you have a radio, it is not creating a Sound, rather only editing a SoundId and playing it. Server replicates sound playback and tags radio sounds while the client handles the rest.
Have a LocalScript manage the way a client hears a sound - probably don’t want to destroy the sound though. Keep a dictionary for cleaning up. When a new sound object is tagged, add it to the dictionary or remove it if it’s untagged. Using Heartbeat, check the PlaybackLoudness of each sound every frame - if it exceeds a certain amount, set the Volume to 0 or use a muting SoundGroup. Make sure to store the volume so it can be restored if PlaybackLoudness drops below the muting threshold in the next frame.