i would read this blog A reliable case for unreliable packets - boyned's blog
Yep there is fire server on this
Scripters of ROBLOX the day has come, this will give our games such better performance while making our lives easier, great update for once, i hope they can keep the ball rolling in a good direction instead of bad.
2 Likes
Yoo mobile data update 900 bytes at most
I think I understand how it works now, and it seems really useful.
But Iâm still unsure if it should be used in an input system for a fast paced combat game, on one hand itâs faster to arrive (huge improvement) so Iâm leaning more toward using it for inputs, but the packet can also be dropped, meaning it wont register which I donât know how often packets drop but if its frequent that might get annoying. Just want to hear other peoples thoughts on if it should be used for Inputs.
Overall really happy with this update! Hope to see more optimization focused updates in the future.
1 Like
Can someone explain why these are better than normal remote events? I donât doubt they have their use, but I donât understand the point. Any meaningful use case as example? Would they improve performance, when used alongside normal RemoteEvents? Do they send data between client\server faster? I assume so since people are talking about improving fast-paced combat games.
They arenât âBetterâ than remote events, each have their use case as the name suggests, Unreliable Remotes are more useful for network performance in instances where you donât care if the recieved event actually suceeded, something the likes of a hit effect or a hit sound, while regular remotes will delay other calls until it is guaranteed that said call is recieved on the client, by not waiting for a guarantee that the client recieved the call it allows unreliable remotes to continue on to the next call without delaying others and instead dropping the failed call thereso improving ping, it will still attempt to finalize all the calls though, to clarify this is only my understanding from reading everything here, free to correct me on anything.
Iâve considered doing this, the issue is that I want to use as less data as possible.
Sending over a single integer or number through a remote event already uses about 9 bytes of data for just the number.
I think this also has to do due the fact that Roblox uses like 64-bit numbers or something.
All my remotes must operate with as least data as possible and use the smallest amount of bandwidth.
If there wonât be some kind of unreliable ordered remote event then Iâll have to think of a different approach that uses the data already available.
Iâve considered using unreliable remote events for possibly projectile or player character physics.
One thing I maybe could do is compare distances between varying positions and discard the ones that have the smallest distance or would result in the player rubberbanding.
Only thing that would make rubberband checks difficult to do is if the player were to constantly run left-right-left-right or do a wall jump, so Iâd have to compare directions as well.
By my understanding this is extremely useful, I personally picture it like this:
Remote Events
1. Combat Function Executes
2. Combat Function Fires a Hit Effect Remote [[This Remote Delays]]
3. Combat Function Fires a Hit Sound Remote -- Waiting.. what's the delay?...
4. Combat Function Fires a more Important Remote -- Waiting... what's the delay?...
Final. Hit Effect Remote failed, drop and continue others [[After]] delay
Unreliable Remote Events
1. Combat Function Executes
2. Combat Function Fires a Hit Effect Remote [[This Remote Delays]]
3. Combat Function Fires a Hit Sound Remote -- Don't care that it delays, continue...
4. Combat Function Fires a more Important Remote -- Don't care that it delays, continue...
Final. Hit Effect Remote failed, no one cares and others were sent [[without]] delay
The way I would use it is:
1. Combat Function Executes
2. Combat Function Fires an [[Unreliable Remote Event]] for a hit effect.
3. Combat Function Fires a [[Remote Event]] for a more important action.
4. Combat Function Fires an [[Unreliable Remote Event]] for a hit sound.
I have no idea if this is actually how it works, but itâs my pleasure picturing of it 
3 Likes
FInally! Itâll help players and developpers.
They arenât better or worse remote events.
Theyâre low-priority remote events that can be used for sending over data that can be dropped if it uses too much bandwidth or if server performance is degraded.
Theyâre useful for things like buffers or if your game uses itâs own physics / projectile systems.
When a player moves you donât always need to update their position accurately 60 times a second.
Sometimes you can sorta predict which way theyâre moving and drop the data that wouldnât make a big difference in how they move around.
For projectile physics (e.g. bullets, rockets, snowballs, paintball guns, etc) you donât have to send every single position update.
If you see a rocket moving forward in a straight line you can probably predict that it will still follow that same line of traversal 5 seconds later, so we donât have to constantly update itâs position.
But letâs say the rocket gets hit by some wind or itâs a heat-seeking rocket?
That would obviously affect itâs way of traversal, therefor we update the position a bunch of times so all clients get a more accurate representation of the rocket.
But a lot of that position updating data might be excessive or unnecessary so we can drop some of it.
Pretty sure Roblox internally already does this with their own physics engine.
2 Likes
I see a lot of people commenting about the name, but I personally think that other names suggested here are even more misleading then the current name. The events are âunreliableâ because they make no promises, not about order, not about receipt. They are not meant for data you need to rely on.
Calling them something like âUnorderedâ masks the fact that these events can be lost to the void completly. Sending: 1, 2, 3, 4 could result in 2, 4, 3. Thatâs not just unordered. A developer who doesnât understand UDP/TCP is probably going to be more confused that one of their messages for an âunorderedâ event didnât show up.
Realistically the problem here is that UnreliableRemoteEvents are not suited for anyone who doesnât already understand their use case. Itâs something that someone should not use unless they have a good grasp of what it does, why itâs different, and the kind of information you want to send unreliably. Unfortunetly there are a lot of things in programming that have a sharp learning curve if you want to open the possibilities to developers to optimize and make some truely amazing tech on your platform.
And this isnât to say that people shouldnât want and try to learn, but I see a lot of people asking âwhy should I use this over normal eventsâ and the answer to them is âyou shouldnât use them at all.â Instead you should work on making robust code and learning about standard data architecture and protocols over time and when you reach questions like, âRemoteEvents always promise order and receipt⌠How do I send this data that I need to send very rapidly and like⌠all the time⌠without it clogging up the bandwidth pipeline? Data that is okay if itâs lost to lag because it wonât even matter if we have inaccurate data later because weâll get new data?â You answer it with, âUnreliableRemoteEvents!â
TL:DR: Keep learning, this feature is not a beginner level feature and if the documentation/explination doesnât make sense to you right now thatâs okay. Keep pushing yourself and one day itâs gonna make sense and thatâs when youâll get use out of it.
13 Likes
i think if the packet does drop. you want to make sure that the packet isnât one that if it does drop will break the game or disrupt gameplay severely. so for combat, depending if you do damage verification on the server. itâs not the end of the world if it drops.
plus, because of the behaviour of unreliable remotes, you can keep sending the signal till the packet gets through, and it wont hinder other signals being sent because it has to send the packet before the next signal is sent.
You make a very solid point here.
I would not recommend using unreliable remote events ever unless you know what youâre doing.
I feel like theyâre slightly more niche tools that you use if youâre developing more advanced things like your own physics or animation engine from scratch.
Most of the time if youâre making a very simple Roblox game with standard physics, raycasting laser guns and whatnot, letâs say⌠99% of the time youâre not going to need unreliable remotes.
Unreliable remotes have very niche and specific usecases.
I want to experiment making my own physics engine from scratch sometime, perhaps a old school physics emulator.
But using reliable remotes might result in excessive data being send over.
Most of these physics I can likely predict ahead of time, interpolated or interpreted and probably only need to replicate if a lot of objects are letâs say⌠colliding and bouncing off each other.
In such cases, a unreliable remote might help with updating and syncing up the physics and rigid bodies.
But since theyâre unreliable, they might drop data if the server is getting laggy or if playerâs are experiencing poor performance.
Which is intended behavior, when the server has to handle too much, we want to drop some load so the server can have a bit of breathing room and catch up again.
3 Likes
i think youâre on the right lines, i find it interesting you have a separate remote for the sound and not just put the sound as part of the effect function
1 Like
Ooh, a new RemoteEvent.
Quite nice if i say so.
1 Like
Well I also need other sounds that do not need hit effects eg.
:FireAllClients("Sound",{Sound = "CastVoiceline"})
:FireAllClients("Sound",{Sound = "ChargeInitial"})
So either I would add into my hit function like so
function client.HitEffect(...)
local info =...;
if info.onlysound then
return
end
end
Which is essentiallyâŚthe same thing, overall I need more control of sounds outside of hit effects so yeah, thatâs why
2 Likes
This sounds like a case where the effect can be done locally for each client, avoiding the need for remote events altogether
1 Like
If the client is aware of said combat event, they can create particles based on that one event aswell, without requiring a seperate, unreliable effects event.
As for guns, if I fire a round and it hits for me, I expect that the server acknowledges that, instead of nothing happening and the round seemingly having vanished.
2 Likes
For one, when using unreliable remote events the sender wonât receive an acknowledgement so thatâs one less packet.
Furthermore, with unreliable remote events, the server/client wonât resend the packet if itâs dropped, since there is no acknowledgement. Thus, no extra packets will be sent, which is especially noticeable when there is high packet loss.
1 Like