There are audios on ROBLOX which allow you to crash games, this problem existing for a long time yet somehow it isn’t fixed.
Is there a temporary method for stopping this from happening except blacklisting audios?
1 Like
Can you tell me the audio ID that crashes the server?
1 Like
Your best idea is not blacklisting but whitelisting should be considered. Whitelist if the audio is owner of Roblox. Whitelist certain owners and specific IDs. If it’s not in the whitelist, it won’t play.
Bug reported here:
If it is set soundIDs that crash the game then I think blacklisting is the best option.
I have a few questions:
Are the sounds Played through server or local?
Are the sounds entered into a playlist?
Can we see the script where you attempt to play the soundID and any error handling involved?
This is important as it could be soundIDs not loading and causing your error handling to crash the game.
The problem of attempting to find the blacklisted audio is near impossible at first glance once the server crashes. Possibility is that it was played on server. You need to find sources of where the crashing audios are.
If it is played on the server then that would make things easier.
You can have servers back each other up.
When a soundID is loaded(Before playing) you can use the messaging service to send some data to the other servers. For example the sound ID and number of players in game.
Then once the sound has played it will send another messaging confirming completion of the sound ID. Should the server go down this message will not be sent so after say 5 minutes that SoundID will then be put onto the blacklist.
There are bunch more things messaging service can offer so It is worth implementing.
E.g creating a current server list
Allowing admins to communicate across server and broadcast messages.
This is also a major issue so I would also create a bug report on this.
The audio length is extremely short and the issue is that it overloads on playback intentionally, which cause the clients to crash, not the server. Besides, your solution has a drawback when a false alarm positives of server crashing because of other reasons while an audio was just played.
well then you can check the player count at the start of a song and at the end.
once a player leaves the game you could get the number of players leaving within a sort time. If all the players suddenly disconnect then there’s a issue. Of course players might all leave at the same time so you would want to detect the difference.
I don’t count on the blacklist though. Try cutting losses by using a whitelist instead, which harshly limit the audios that are allowed. This also eliminates the issue of loud and other bypassed audio instances.
according to what @Operatik said this should fix the issue
function checkcrash(sound)
return sound.TimeLength >= 1
end
2 Likes
I will try this, I’m guessing it needs to be done before the sound is played after it loads?
before it plays, just do
if not checkcrash(sound) then
–this will crash the game do not play the song
else
–insert code that will play it
end
1 Like
Just realised this will not help because the two crash audios I have found are 30-45 seconds.
This still exists, we’ve blacklisted many but they just keep coming. Does anyone have a verified solution for it?
Can confirm that it crashes the players client not the server, and it doesn’t work straight away. I played it once, one person around me crashed but then when I played it again a few others and myself crashed.
I’m only willing to give them out to engineers or staff or something for obvious reasons, they’re pretty serious, but not as serious as crashing entire servers thankfully.