Introducing UnreliableRemoteEvents

Updates Announcements
#148

I do not understand what will be the benefits of this can someone please explain to me? sorry if im asking but i seriously have no idea

1 Like
#149

Someone already linked a blog that explains it pretty well.

3 Likes
#151

Awesome feature, but change the icon in the explorer pleease.

3 Likes
#152

Will anyone inform me the purpose of this seemingly promising new feature? How it is used? Why it is used and more ā€œreliableā€ for that usage compared to using RemoteEvents in certain cases? I really want to be able to put this to use.

This seems like a feature that allows it to be canceled whenever it thinks it should, and perhaps it ignores processing some excess information?

1 Like
#153

Itā€™s just remote event that can be used in infinite while loops or runservice events.
So far, i donā€™t think there is a use to call a unreliable network event only once, since if the packet drops youā€™d need to re-send it otherwise it doesnā€™t get achknowledged by the server.

Even then, nothing stops you from using regular remotes in runservice events or infinite while loops apart from your digniā€¦i mean causing high ping for your players and server crashes.

2 Likes
#154

Majority of Roblox Server ā†’ Client and Client ā†’ Server traffic is over UDP. TCP is mostly something people reserve for Web Technology, but itā€™s too clunky for sending real time data on a frame to frame basis.

Any time a game engine needs Reliability they implement it on top of the UDP layer.

If you send an event over RemoteEvent object and it gets dropped before delivery, the system assumes the event is critical and will halt sending/receiving other data until that event is sent, blocking all traffic. UnreliableRemoteEvent doesnā€™t care whether the send attempt succeeded or failed. Particularly useful if you are going to be sending an update about something every frame, you probably donā€™t care about every update making it over the network, only care that the latest update is always trying to be sent. This is what UREs are good for.

11 Likes
#155

Check out these two posts

2 Likes
#156

This is the best update ever, Finally we have unreliable remote events, long gone are the days of being limited by the roblox engine, I want to thank everyone who worked on this I love this update so much.

1 Like
#157

What do you mean

, from what Iā€™m reading it doesnt seem like Unreliable Remote events is something youll be wanting to use all the time or at least its more for niche things, correct me if im wrong though. I dont fully understand

1 Like
#158

If you want to use the least amount of data possible you would be serializing the entire data into a binary string for example using string.pack and string.unpack in which case you can assign numbers whatever amount of bytes you want depending on the use case and which would also get rid of most of the overhead since you would be defining your own data structure:

local packageId = 574384 --4 byte unsigned integer
local v1 = 255 --1 byte unsigned integer
local v2 = -127 --1 byte signed integer
local v3 = 128 --1 byte unsigned integer
local formatString = "I4BbB"

local binaryString = string.pack(formatString,packageId,v1,v2,v3)
print(#binaryString) --7 bytes of data

local packageIdc, v1c, v2c, v3c = string.unpack(formatString,binaryString)
print(packageId == packageIdc and v1 == v1c and v2 == v2c and v3 == v3c) --true

An unreliable ordered wouldnā€™t get rid of the overhead, it would just move it to where you wouldnā€™t see it directly.

That said I believe it should still be implemented alongside the other reliability types Raknet has to offer regardless since there are use cases for all of them.

3 Likes
#159

Wait until you find about server authoritative netcode

2 Likes
#160

What actually hilarious is that im creating a game with custom projectiles and for the past week Iā€™ve been struggling to figure out how to keep the server authoritative while also having the clients have that snappy feedback

Could UnreliableRemoteEvents be viable for my situation?

1 Like
#161

Oh this is pretty neat stuff! Can you by any chance show me where I can learn more about this stuff?

Does this actually use less data? Last time I checked I recall strings use 1 byte per character so Iā€™m curious how this would allow you to compress data further down.

1 Like
#162

just to know, why is it not a property of remoteevents?

#164

Iā€™ve been wanting this so badly, im very happy its finally here

1 Like
#165

Valid feedback on wording, we will try to fix the wording on the original post to make it more obvious which are things we want to change and which are things we will not change.

  1. Unreliable Remote Events will probably remain 900 due to hardware limitations/configuration across the platform. Itā€™s possible that as hardware slowly improves we may be able to raise this, but we donā€™t plan on lowering this as this could potentially break content.
  2. The prioritization issue is something we want to resolve, but unsure of the timeline yet because there are some invisible under the hood changes that it depends on. But UnreliableRemoteEventā€™s full potentially isnā€™t unlocked without this. For example itā€™s still possible to starve out your UnreliableRemoteEvents by flooding our Replication systems with other data (Like regular RemoteEvents and Property updates), and this is something we want to resolve.
8 Likes
#166

You can definitely make your own reliable UDP remote events, just have to code the handshake yourself.

I am unsure of any latency penalties of doing this, though, but this is basically what those other network frameworks do, its just a layer on top of UDP.

2 Likes
#167

no idea how we are going to use these lol.

1 Like
#168

Is there any point in doing this when TCP exists if itā€™s to mimick the exact same behavior ? How can this possibly be more profitable in any ways (cost, maintenance or just computing time) ?

1 Like
#169

A property was considered during the exploration phase, but ultimately considered subpar.

One factor against it is that we cannot really let you set this behavior at runtime. It opens up a large number of confusing and unintuitive edge cases. We have to have defined answers for them, because if we hand-waive it as unspecified, then whatever it is will end up being something we canā€™t change.

There are a few alternatives there but none of them are pretty. For example, we can limit setting the property until itā€™s in the data model, but as a rule we donā€™t like when property setting errors. So we couldā€™ve made it a method (:SetReliability, which errors), but itā€™s not intuitive and also isnā€™t a lovely precedent.

Furthermore, the internal code complexity of it just isnā€™t great either since it becomes trickier to know what kind of reliability weā€™re expecting.

20 Likes