Spam of Head.FreeFalling.CharacterSoundEvent?

I am helping a friend with a community based game that generally has a single server with a few dozen players at once. The consequence of having a single server is that, every now and again, the server is attacked. Generally, the intention is to crash the server in one way or another.

Lately, we’ve been noticing these crashes. While the crash is occurring, we see this in the developer console:

“Remote event invocation queue exhausted for Head.FreeFalling.CharacterSoundEvent; did you forget to implement OnServerEvent?”

We’re fairly certain that this is not caused by anything we’re doing, as it does not show up on its own. Servers can exist for hours, days even, without this occurring. At the same time, we can see this within minutes of a new server appearing.

Seeing a correlation between servers crashing and this error appearing, we’re naturally forced to wonder: is there any way that someone could maliciously cause this? Could this actually crash a server or otherwise increase latency or framerate lag for clients? If so, what measures can we put in place to counter it?

Edit: changed the title to reflect what the discussion on this thread has continued to become; it has been long established that the issue is not malicious.

10 Likes

I’m not sure what the issue may be, but I would like to note that this error only pops up when there is not a listener for the client or server, or in rare cases, the remote is fired in extremely large quantities within a very quick amount of time. Since this is being shown on the DevConsole many times, I would conclude that the event is being fired at a quicker rate than what it can handle.

This, in turn, causes performance issues. For now, I think the only thing you can do is detect the framerate and when it dips below a certain framerate (preferably <10-15), then you take action, whatever that may be. Hopefully, someone does find a solution to this issue.

You can detect the framerate by doing:

print(1/wait() or game:GetService("Workspace"):GetRealPhysicsFPS())
2 Likes

This isn’t malicious unless a exploiter is wrongly calling the remotes in the sounds, this is a product of the default Sound script. You can mute this error by implementing a blanked function for OnServerEvent. Don’t rely on it because it’s a band-aid solution, but it’ll solve your spam for the time being.

CharacterSoundEvent.OnServerEvent:Connect(function () end)

You can also connect a blank function for the client by changing Server to Client. It won’t have any performance impact on your game, so don’t worry about that.

2 Likes

Seeing as how this is an event created by Roblox, not us, I would have to assume that Roblox does have a listener for it. Otherwise, that’s an issue that needs to be resolved.

Based on how quickly the errors occur (refer to the timestamps on the screenshot) I’d say this is likely the issue here.

Wouldn’t the exhaustion still happen based on the amount of repeated calls in quick succession? Even with a function in place?

I feel like Roblox has to have a function already listening for this event. Why would they create it otherwise?

This can be useless if it was what I stated in my post above

So even if the OnServerEvent is listened to, when fired too many times, it will still cause the Error to show up repeatedly in the console.

No, it wouldn’t throw the error. From my own experience, this error simply means that it’s trying to call functions when there’s nothing hooked up. I’ve had this error spam happen before; hooking a blank function to the environment experiencing the “invocation exhaustion” ceased the console spam.

You can fork the Sound script to see how the events are being operated and see how Roblox is hooking the events. There may be a code oversight that’s causing the spam.

No, it wouldn’t. Remotes can be fired in quick succession without issue. Connecting a blank function would mute the error while starting quite literally a blank thread (meaning no code is really running, except for the beginning and ending of a new thread).

I’ve had this issue before with remotes that aren’t just the CharacterSoundEvent remote of the Sound script. Hooking a blank muted it; so did ensuring my remotes were listened properly without calls being done out of line (Server calling OnClient or vice versa, or whatever).

Standard remotes already are able to handle firing quickly. You can see this with, say, guns with automatic firing cycles that fire remotes every time they’re shot. You don’t get this error.

You can see this for yourself by setting up an experiment.

Removed the experiment - it’s not an accurate one.

Got a working experiment down that reproduced the issue in the OP. It’s a similar setup to the one I deleted, but seeing those results doesn’t matter. It just shows that you can fire remotes in rapid succession without any problem - I put a fire in a while true do wait() end loop and got over 3000 prints without error.

How to set up the experiment:

  • RemoteEvent > ReplicatedStorage
  • Script > ServerScriptService
  • LocalScript > StarterPlayer.StarterPlayerScripts

Contents of the Script:

local replicatedStorage = game:GetService("ReplicatedStorage")
local remoteEvent = replicatedStorage.RemoteEvent

remoteEvent.OnClientEvent:Connect(function () end)

Contents of the LocalScript:

local replicatedStorage = game:GetService("ReplicatedStorage")
local remoteEvent = replicatedStorage.RemoteEvent

while true do
   remoteEvent:FireServer()
   print("fired")
   wait()
end

Results:

Means that the issue is being fired or listened from the wrong environment. It has nothing to do with the speed of a remote being fired. A remote can be fired in quick succession faster than you think.

Simply change “OnClientEvent” in any server script to “OnServerEvent” and do it vice versa for the client. Same goes with FireEnvironment; server for client, client(player)/allclients for the server.

Hooking a blank function will also solve this.

1 Like

However, my main perception of this problem was correct.

To my knowledge the limit is 50kb/sec, correct me if I’m not mistaken.

I just can’t understand why a Roblox has such an implementation on a RemoteEvent. I know that multiple scripts can access the RemoteEvent, so could it be possible if a LocalScript has an OnClientEvent event to the RemoteEvent, while a Script has an OnServerEvent event on the same RemoteEvent?

Not entirely. The repeated spam only comes from how many times its being fired and because the event is being wrongly listened/fired. What I’m addressing is the root problem, which is why the error is appearing in the first place.

The limit is 60KB/s and this limit is only applicable to how much data can be sent. Firing a remote without data doesn’t negate this limit or take away from it. This makes my point remain unchanged. The code sample I provided listens OnEnvironmentEvent and starts a blank scope. If at minimum one event is there, the event won’t show due to improper connection. I’ve also provided other ways to mute or fix the issue being presented.

RemoteEvents are fine to be connected multiple times, because OnEnvironmentEvent is an RBXScriptSignal. It’s the same as doing something like Players.PlayerAdded:Connect multiple times or using some other RBXScriptSignal from both the client and the server.

The events of those remotes are completely separate and just signals to run whatever is connected. There is absolutely nothing wrong with using a single remote and doing both OnClientEvent and OnServerEvent on them, multiple times or once, in several scripts or just one. It’s done pretty frequently.

Another solution is to remove the RemoteEvent, so it only produces one error, as it will stop the firing and will error only because the variable or statement referencing the Remote in the assumed LocalScript is nil.

I haven’t had time to read all the replies, but it’s not possible to crash a server by firing that remote event. Using exploits and while in a controlled environment, I tested it my self. I was able to make the ping for my client around 40,000ms, but the server still held strong for the other people in the server.

If I had to guess, it’s a problem with a RemoteEvent or RemoteFunction that you guys created yourself. If you don’t check if a player is spamming an event, they can completely crash the server with ease. The best way to handle this is to add rate limiting to your Remotes. A simple ratelimit:

local SampleEvent = game.ReplicatedStorage:WaitForChild("SampleEvent")
local RateLimit = {}

SampleEvent.OnServerEvent:Connect(function(Player)
    if RateLimit[Player] == nil or tick() - RateLimit[Player] > 1 then -- The number is how many seconds between firing the player can do
         RateLimit[Player] = tick()
         -- Do stuff here
   end
end)

When testing with exploits, I never got that error message to pop up, so maybe I’m doing something incorrectly. I got another error message that said that I was spamming the event, but it wasn’t the one that you guys got.

2 Likes

I’m getting this too. Anyone know what the source is or how to fix it?

1 Like

From my personal experience, ive seen people “Shutdown” servers by spamming remotes connected to character sounds. Most of them get patched fairly quickly (~ a month) but I guess anything is possible.

Is this causing your server to crash, or is it just showing the message?

This is on the client. Every client is being spammed by this message.

3 Likes

Odd…Berezaa’s issue is occurring to me too, are there any fixes for it?

Lots of games are having these issues. If you check the developer consoles in a few games, you’ll see these errors.

I would assume that Roblox is having some issues right now, but that’s just a thought.

2 Likes

This is still an ongoing issue, I’ve seen these error messages in several games. While I haven’t experienced crashes due to this, I believe ROBLOX should fix this as soon as possible.

Since about a month ago, the console almost always shows an error originated from ROBLOX’s scripts. When one got fixed, another popped up.

Before the aforementioned issue, a warning was also being spammed at random:

And a few other issues: