Just for clarification, there is no 9 byte overhead and additional 5 byte client-to-server overhead?
Should I use this when having a uncontrol event, which is client → server, which indicates that whatever object the player is holding, will be dropped. It has 0 arguements, but I just want to make sure!
Please refer to one of my earlier responses.
If it is important for the server to know that the client wants to drop said object, you shouldn’t use unreliable remote events at all.
I was not under the impression remote events were reliable to begin with, considering I had usecases where sending a fresh spawned part as an argument in a remote event lead to the argument being nil. lol
Remote events only pass references to instances. If those instances don’t exist on the client (yet) then the references won’t point to anything for the client and it will thus be nil.
2 Likes
Maybe I am missing something but looking at the comments many people were very glad for this change. However, what exactly can UnreliableRemoteEvents do that normal ones cannot do? When would you use them? Sorry if this is a silly question, I am not a network engineer.
Your question has already been answered here.
So basically, for events that them not holding future events is more important than them getting processed. So the request is dropped instead of causing issues.
1 Like
I thought UnreliableRemoteEvent should inherit from RemoteEvent
In my game, would it boost performance to remove all RemoteEvents and replace them with Unreliable ones?
That would be very, very unwise. To understand what unreliable remote events are useful for, check out this blog post: A reliable case for unreliable packets - boyned's blog
TLDR: unreliable remote events are useful for sending frequent, trivial information such as the angles of your torso and head as you look around, because you don’t get congestion if some of the fired events aren’t received. More important information should be sent using the secure, regular remote events.
3 Likes
But you can do it to kill off your game completely to promote your new next game! So there won’t be no lingerers in your old game, just claim that “NETWORKING BROKE IN THIS GAME, JOIN THE NEW GAME FOR A FIXED VERSION” I am sure kids don’t understand what “networking” means if they hear your old game is broken but your new game is working fine then they play that. Risky but highly effective!
MY NETYWORKER BROKE!!! I BLAME ROBLOX.
I put this in my description and now I have been terminated.
so can unreliableremoteevents prevent spamming and exhausing the server?
no
mininum character limit woohoo yeah 
Anybody heard of UDP? Well this is the same thing, UnreliableRemoteEvents sometimes drop signals but their only concern is to get data as fast as possible from the client to the server and vice versa. UDP does the same thing too. It may drop some packets but it’s only concern is to get data to the other side as fast as possible.
RemoteEvents are like TCP, they will not drop any packets. - Riley the IT whiz
1 Like
Does Roblox even use TCP at all (aside from HTTP requests)? I was under the impression they used a fork of RakNet which uses UDP only.
Are game events processed between an intermediary server between the user and whatever server receives the information (Like a triangle, host > server > server2 > host), or is processing and forwarding done on the same server? And is there any documentation on the infra for Roblox?
I’m not familiar with RakNet but UDP is definitely the primary road of communication to hosts.
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.
Hi Creators!
We’re releasing some improvements to UnreliableRemoteEvents that you might have glanced from the release notes recently:
- Payload limit has been increased to 1000 bytes on both Client and Server.
- Fixed a bug where the limit was inconsistent between Client and Server.
- Fixed a bug where the payload limit was reduced for long lived servers with many rotating players.
- UnreliableRemoteEvents that have no listeners connected will no longer be queued. The error message is similar as before if the queue length was exhausted.
As always we welcome any feedback. If you encounter any issues or have any concerns please do let us know!
11 Likes