How to silence "Packet Dropped" warnings for UnreliableRemoteEvents

Hello devforum!

I was wondering if there’s any way to silence these “Unreliable event” dropped notifications since they’re pretty annoying and im using a custom character controller which is why im using unreliableremoteevents - they get fired a crazy amount of times per second to replicate character changes which is completely fine, I just need a way to silence it since it doesn’t really cause any harm

AI TLDR:

  • Custom character controller spams UnreliableRemoteEvents
  • Roblox logs “Unreliable event dropped” repeatedly
  • It’s expected since unreliable events can drop packets
  • User wants to silence the notifications because they’re harmless

Listen to the warnings, your payload is too large to be sent.
This isn’t just unreliability, it could lead to bugs if your payload is constantly going over the limit (which if you’re getting so many warnings to the point where it is annoying, you likely will run into issues).

Reduce the size of your payload to fix it, you can break it up into multiple events, or look into compressing your data.

4 Likes

I’ve already looked into compressing data, I’ve compressed up-to 60-70% of the packet size
The issue isn’t the packet itself, the issue is the amount of times the packets are being sent

The warning is sort of misleading because it’s not a single packet at fault but rather a stream of packets collectively.

Don’t believe me? Open studio and have a very fast loop on the server and spam an unreliable remote event with some data under 1kb

You’ll see that even though the packet data doesn’t exceed 1kb, the RATE at which it sends it is what’s causing it.

Like I said, I’m using a server authoritative character controller and packets dropping isn’t a huge deal as long as new packets come in.

and I’ve already explicitly mentioned this:

they get fired a crazy amount of times per second to replicate character changes which is completely fine,

The warning gets sent once every 10-20 seconds

No, I don’t believe you.

Regardless, if you’re sending that much data per event, you have bigger problems to worry about.
Consider if you can decrease how often you send certain types of data (like position/velocity, etc.), the engine replicates physics at ~20Hz, which is then interpolated to smooth it out.

1 Like

Oh weird, regarldess

as i state; it doesn’t cause any actual issues, I’ve already tried compressing it with buffers, shortening keys in my table deltaTimed and already have delta compression in place

It’s just spammy and can be ignored.

Contents of each packet sent:

The warnings are telling you the issue, if you solve the issue the warnings will stop being there. The payloads you send over are too large. To solve this you have to encode and compress your data according to your game logic. For example if you want to send over a number, first remove the data you don’t want from the bytes(for example some numbers after decimal place/mantissa) and then encode it as a string(so the characters are reduced).

A way to tell the size of your payload before passing it over to the server is #game.HttpService:JSONEncode(yourPayload) this will give you the length of the payload in bytes.

2 Likes

JSONEncode is not a reliable way to determine the size of the packet sent. You can use it to gauge how many characters are stored in datastores, but Roblox does not encode remote data in JSON.

There’s currently no way to accurately determine how many bytes a remote is sending (besides estimating off of network traffic). The best thing OP can do here is pack as much data up into buffers so Roblox can compress it with zstd.

^^^

Regardless, the issue actually was that ANOTHER remote was flagging the warnings rather than the one I was focusing on and I’ve fixed the issue - though it does show that roblox should show which remotes are dropping the connections :sob:

Reason why I thought it was because of the AMOUNT of remotes you were sending before was because the server authoritative remote is spammed but has low packet sizes so that would’ve been a logical conclusion

anyways thank you all

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.