Great to see. I plan to integrate it Nexus VR Character Model later next month as a minor update, since I don’t need all 30/second movement updates to be sent.
I don’t really think the announcement covers why people should use them on Roblox. I would expect it to be similar to the discussion of TCP (reliable but more overhead) vs UDP (unreliable but less overhead), but that is not clear. Does using these lead to significantly less network overhead? Less CPU processing? A more reliable connection in general on weaker connections that may need to drop packets?
The wording of this is a bit confusing, are these “issues” that are planned to be fixed or are these limitations that will never be fixed? I ask this because the wording of the title vs the wording of the description of each issue is massively different to each-other.
I love it! Just the icon needs to change → I cannot see the difference in the explorer between the RemoteEvent and UnreliableRemoteEvents.
So quick question, I will use it for effects as well. Can it take like 0.5 second (I know this varies I am just saying because I don’t want an effect to play after 1 second or something) for the request to arrive to the client or is it “fast” like the normal events?
How often these drops happens? Could it occur all the time in games with intense use of physics?
It should logically be a lot faster as it sends faster and without waiting in a queue/order. But the drops are unpredictable and depend on the connection stability between the server and client (player). It could drop between 0 and all packets.
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.
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.
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
but i feel like this should be a property instead of another instance.
→ I cannot see the difference in the explorer between the RemoteEvent and UnreliableRemoteEvents.
