Spam of Head.FreeFalling.CharacterSoundEvent?

[xPoloBear (Polo)]

Bumping this again because it is still happening currently

[OverEngineeredCode]

Just so that I am sure, does that remote play the freefalling sound effect for that player? Or am I wrong?

It would help me if I knew what that remote does before I attempt to answer.

[GameTapped (GTGaming)]

I came across this issue last night.

What happened was - I accidentally duplicated one of my scripts. Ctrl-D must have gotten away(oof).
I only happened to notice that, because I had some logging that was being repeated - in addition to this error.

I traced it down to having CharacterAutoLoads = false, and calling player:LoadCharacter() twice at the same time.(from separate player connect functions) - but seems to be inconsistent.

HeadFreeFalling.rbxl (16.6 KB) Repro
(not always consistent, takes about 30 seconds for it to start throwing error, seems more consistent if you test multiple players) If it doesn’t error after a minute, I usually restart it. Your patience may vary.

Not sure if it could be exploited, but in this case it was just a mistake on my end. It’s a very misleading error message though, I’ll give it that.

[Dave_Here]

Had the same issue and it was resolved by removing my player:LoadCharacter() in my join script.

[ReturnedTrue (Tr_uth)]

There’s been 3 bug reports on this already:

Log spam for 'CharacterSoundEvent' error

I’ve been getting this bug on my game for months now, I think it’s to do with spawning players frequently but I’m pretty sure it causes massive lag. I can’t provide any more information apart from the fact that it is always happening in laggy servers and aside from that it’s seemingly random. [image]

New Bug With Today's Update: Remote event invocation queue exhausted ... FreeFalling.CharacterSoundEvent;

I believe this just got introduced with the update from today. When using a StarterCharacter with the default character sound files (died, swimming, etc) stored in the head, the following error occurs: 14:42:04.936 - Remote event invocation queue exhausted for Workspace.MapleMarvel.Head.FreeFalling.CharacterSoundEvent; did you forget to implement OnServerEvent? (x111) To Reproduce. See attached file which has a StarterCharacter with the character sound files already stored in the head. Hit …

Character Audio Script Exhausts Remote Event

This occurs from time to time, not specifically sure what causes this bug. Although, the error in this screenshot was caused from walking into a corner of part. [image]

[colbert2677 (ImagineerColbert)]

This is not a bug report, it’s a thread from 4 months ago that is hardly prevalent anymore which asked about the error itself. It was just upped back for a potential fix, for whatever reason, even though such solutions are already available.

I believe the mute fix was applied internally, which makes this a non-issue as it stands.

[ReturnedTrue (Tr_uth)]

Alright, thanks for the information. I’ll try to look out for solutions if for some reason it occurs again.

[Bladster94 (Bladster)]

@colbert2677

I believe the mute fix was applied internally, which makes this a non-issue as it stands.

Sadly it hasn’t: I landed on this thread looking for a solution to the Head.FreeFalling.CharacterSoundEvent spam. It happens on a place I created recently with most of the content from another, none touching this event. (I did this to have my game’s systems on a new map without having to get rid of the other.)

It appears roughly 3 times a second, and I hadn’t this issue on the place the content originates from. So I think it could be linked to something with the game/place settings, but that wouldn’t make much sense.

I’ll just use the blank function fix for now, but it unfortunately still is relevant.

[Rietria (Rie)]

I had this issue too, and I don’t know if this has been said already but how I fixed it was:

Putting a script called “Sound” inside game.StarterPlayer.StarterCharacterScripts and disabling the script. This replaces roblox’s default sound script with an empty script.

Ex.

By doing this you are removing the sound effects given off by a player (like jumping, walking) in order to prevent the remoteevent spam.

[colbert2677 (ImagineerColbert)]

It hasn’t? That’s interesting. I haven’t received any errors regarding the Sound script for a very long time now, so I guess I kind of just assumed that something was done about it. Perhaps an attempt to mitigate it was done but not a full fix.

This does raise a question though, whether the error is a source of something done by the developer or whether it’s just the script itself acting up. Do you knowingly modify the character or any game assets?

[Bladster94 (Bladster)]

I do modify the avatar, since it’s a roleplay game. I just created a dummy and set it as StarterCharacter as a temporary morph, to make the StarterGUI show up. I removed everything that is unnecessary on the dummy since it’s only supposed to be staying away in a hidden room. So there shouldn’t even be a FreeFalling sound in the head to begin with, or something is automatically adding it back in.

It was working just fine and silent for a long time. However, it started happening when I brought my game into a new place, and stopped when I disabled the auto spawning. Might be a clue around there?

Note: sorry for the big delay, I was sure I sent the message.

[Kacper]

@AbiZinho

You can detect the framerate by doing:

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

1/wait()

will not return FPS as the delay generated by wait() is in most cases longer than the actual delta time.

game:GetService("Workspace"):GetRealPhysicsFPS()

is fine or you can use delta time from RunService

local deltatime = game:GetService("RunService").RenderStepped:Wait()
print(1/deltatime)

[colbert2677 (ImagineerColbert)]

Just want to add one final remark before I stop. This whole topic of FPS is off-topic as it is.

@Kacper

the delay generated by wait() is in most cases longer than the actual delta time

To explain this behaviour: wait will never actually wait n amount of seconds. When you call wait, you’re actually asking the scheduler to sleep the thread for n amount of seconds. The additional time wait consumes is to search for an open slot in the task scheduler to resume the thread.

AFAIK if you have a badly performing game, why a wait(1) could wait up to 2 or more seconds is typically the result of the call actually only waiting 1 second but never having an available slot in the task scheduler to resume, thus pushing the time upward.

I remember there was a thread here about a wait(1) taking >3 seconds.