I do not see this mentioned in the original post so I’ll ask; Are there any plans to include settings in studio to simulate unreliable networks? I’m assuming that given that studio runs on your local network, you’ll realistically never see packets arriving in a different order - or being dropped.
There doesn’t seem to be a setting for this currently, but having some way to simulate this would be helpful when debugging problems.
UDP-style packet transmission!
This is awesome! This is going to be so useful for client-sided effects, amazing addition.
If anyone is unsure why the excitement or why you’d ever want something “unreliable”, here’s a simple blog post I wrote many moons ago to describe a very simple use case that was previously very unperformant until today:
I genuinely thought that the title of this post: “UnreliableRemoteEvents” was an April fools joke, but it’s actually a pretty awesome feature! I was curious if you have any further examples of when you’d use this, or practicality outside of just a fire extinguisher with pointing abilities.
I’m also not entirely sure what’s wrong with just using a normal remote event when doing something similar, my experience has loads of similar “particles” or “effects” which occur with remote events so I’m a bit confused and curious if I need to swap over.
The difference here is huge!!
(using Clumsy to simulate the packet loss)
Something I just thought to add onto this post, would “UnreliableRemoteEvents” actually work most of the time? Should I be scared that a large portion of particles and effects which occur after will just flat out be dropped, and there will not be any effect whatsoever?
Maybe I’m thinking about this “UnreliableRemoteEvent” incorrectly, maybe it’s just better on a larger-scale when you’re massively spamming the remote event for something
Been waiting years for this! I’m so glad to see it finally release.
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.
Very strange Remote Event but very cool!
Reading this announcement’s title felt like Christmas morning.
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
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?
I’ve been waiting for this for a long time. Can’t wait to implement it in my future projects!
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.
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.
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.
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.
I’m assuming we can still use tools like Clumsy to do it, but an in-Studio tool would be appreciated
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