Been waiting years for this! I’m so glad to see it finally release.
10 Likes
Unreliable in this context means that there is no check to make sure the client/server received the event. This doesn’t mean all of your events will not be received, but it does mean that the overhead for this check is removed. This removes a ton of ping associated, because it no longer has to check if the event was received.
You should use UnreliableRemoteEvents for visual effects like the ones you specified, especially if you prefer performance and missing some particles vs losing performance and ensuring every particle is created.
21 Likes
Very strange Remote Event but very cool!
10 Likes
Reading this announcement’s title felt like Christmas morning.
23 Likes
This is also helpful for anyone making games with an Authoritative network.
Example: My Kart racing game sends a binary number that contains all of the users inputs, and only sends it when the inputs change. Sending those using a normal remote event is reliable, but it’s slow and has a lot of overhead leading to some experiences being laggy.
With Unreliable Remote Events the overhead is gone, and the inputs happen much faster. This is great for Competitive Games that want lower delays on things that need to happen server-side
16 Likes
Wait, I need an in-depth explanation between the difference between this and normal events, should I use this for visuals basically? while normal events for crucial gameplay? like damaging?
10 Likes
I’ve been waiting for this for a long time. Can’t wait to implement it in my future projects!
7 Likes
Normal Remote Events are sent in an ordered manner, so if there is a packet drop it will hold the other packets up until it gets resolved.
These are reliable, but not ideal for real-time responsiveness.
These Remote Events are unordered, so if a packet gets dropped they don’t care.
These are good for things that you don’t care if they show up in a certain order.
19 Likes
A question to the community, here: Would it be fine if I used this but also dropped the “skipped” packets that happened to be sent out of order, in some cases? There’s some things that I’d be fine with being potentially spotty, but I don’t know about out of order.
6 Likes
UnreliableRemoteEvents are pretty neat however i do have a few questions:
-
Why the 900 bytes limit? Why can’t we set the byte limit ourselves?
-
Why exactly the CPU usage limitation? I understand that this is supposed to be an unreliable remote but i can already see situations in which a player’s client is by default struggling with the cpu (due to either age or just high system load), potentially making UnreliableRemoteEvents unusable for anything that does not get past a relatively specific performance threshold.
-
This is something i had on my mind for a while and it’s not exactly something crazy but why are UnreliableRemoteEvents their own instance? Would have it not been a better idea to simply add some sort of “Unreliable” boolean property to RemoteEvents? UnreliableRemoteEvents are a very welcome addition though i do feel as like them being entirely new instances is a bit redundant.
11 Likes
YEEEEESSS! This will be so useful for custom physics and character movement systems, character aiming and anything that needs a buffer!
Can we please also get a feature where the remote event will ONLY consider or accept the most recent data package and automatically drop or choose not to fire if it receives older packages?
Currently if you would want to use this for movement systems you’d have a bit of a problem since movement might end up jumping back and forth due everything not arriving in a guaranteed order.
I’d love to have a setting that ignores older remote event fires and only accepts the newest / most recent data.
14 Likes
I’m assuming we can still use tools like Clumsy to do it, but an in-Studio tool would be appreciated
6 Likes
Depends on what you’re doing, if you only care about the most recent (ordered) data you could just pass along a timestamp or an incrementing serial and have the listener only care if the received data has a higher timestamp than the last received one
5 Likes
While useful for now you can get this functionality by using a useful little program called Clumsy which also works in roblox studio.
10 Likes
Does an event expiration exist that we can set or should that be a feature request for this new feature? Event expiration would be useful in that, say you want to create a spark fx on the client where a laser beam hits an object. Using UnreliableRemoveEvents would be ideal since that spark fx is not vital for the game. But at the same time, I don’t want the spark fx to fire like 2 or 3 seconds later when it doesn’t make sense. Any expiration setting would be a good way to prevent this, so when I create this new UnreliableRemoveEvent in Studio, I could set maybe a 500 ms expiration so if the client gets this even 500 ms past when it should have, just ignore it all together. 
Probably would be more useful on the server side at least.
5 Likes
There will always be limits size if you want to fully take advantage of unreliable remotes.
The key thing to understand is how the internet works: Information is sent over the internet in the form of packets, which are are sent between physically connected machines as short bursts of information transfer. When you chain enough of these physical links together, you can send the packet all the way across the world.
However, the machines and links along the way can only handle so much information per packet, and the bigger the packet the more chance there is of something going wrong during one of the many hops between the client and server.
Normally, something like an image you send is split up into many separate packets, and reassembled on the other end. However a bunch of extra processing is required to do that: Lost packets have to be resent, ordering information has to be tracked to reassemble the packets in the right order, and the overall transmission will be as slow as the slowest packet. All that adds up to extra latency.
If you really want to send something across the wire with as little latency as possible, it has to fit within a single packet, and the typically most effective packet size is where the 900 is coming from.
48 Likes
Curious, under the hood, is this using a udp type protocol?
3 Likes
I remember seeing the initial feature request. This should help greatly with network lag.
6 Likes
I had no idea this was coming, or even being discussed. This is like Christmas come early!
5 Likes
This can be easily handled with unreliable unordered events simply by sending a incrementing number alongside the data with the receiver then discarding any packages with a number lower than the last accepted package.
Something I would now like to see are reliable unordered remote events and functions that are guaranteed to send the data eventually but without being forced to be sent in order meaning they don’t cause or are affected by pingspikes caused by package loss like regular remote events do/are and are more of a pain to implement using unreliable events due to the Two Generals’ Problem.
16 Likes