Hello, i would ask if someone is getting this problem or how to fix.
Recently my game started logging tons of this errors, does anyone might know how to find what is causing this? as there is 0 reference for this
Unreliable Event dropped as its payload is too large. Consider reducing the total size of the arguments. Payload went over by: 350 bytes
All my FireServer Calls
As you can see most of the Call are just name or table, some time Char Object
Thanks!
UnreliableRemoteEvents have a maximum payload of 900 bytes, so check to see if you’re not sending too much data.
With that being said, a RemoteEvent may be a better fit here. I don’t see a lot of reasons to send a whole table through an UnreliableRemoteEvent unless you have some sort of complex particle/client-only VFX system.
Yeah, but actually we don’t use Unreliable Event so idk how this is happening.
Only module we import is HD Admin but actually is not using Unreliable Event
Are you sure? I’m almost certain that message is specific to UnreliableRemoteEvent, so there’s no way you’d be getting it otherwise. Can you trace the error to see if it’s really your system or something else such as a ROBLOX CoreScript?
Unfortunately I can’t trace it since the error it gives is a warn and doesn’t have a source.
I’m willing to bet it’s either a plugin or an internal script. See if it happens in a new experience.
Actually this is happening only after a bit, game is running i can’t repro this in studio, that was the strange part, may be connected the the old legacy chat roblox?
Curious. Is it causing issues for you? Since you’re sure it’s not your codebase causing the issue, I’d ignore it if it’s not harming anything. It being unreliable makes me think it’s not important data to begin with so you should be safe to ignore it.
It’s not a performance issue, it’s a console logging issue as it gets spammed all the time in the server log. And it’s like impossibile to trace real issue.
Again, I’d ignore it if it’s causing no real issues. It’s again most likely a CoreScript (which would explain why it’s untraceable) and will probably be silently fixed. If you could figure out when the warning is created, you could probably track down which specific script is causing the issue
