Yeah exactly, you could use UDP to send a pseudo ACK but that would really defeat the point of UDP in the first place. And if you sent an UDP packet for an ACK, how would you know which UDP packet this ACK was for ? You’d have to associate it to a number, which really comes down to implementing TCP in a worse way increasing the processing time and latency drastically way past TCP territory.
On top of that, I don’t really see any use for Reliable Unordered either, doesn’t really make sense to me that we’d need to make SURE something is sent but we don’t care which order. If we don’t care which order, then why not ordered ?
If it is just for the effect and won’t affect other players (no collide, no touch, etc.) then the Client is the best place because that saves bandwidth from the replication the server is sending to the Client. It will also releases the server of some CPU cycles since the Client will be doing that work instead. But if Players are not suppose to walk through it or some other game breaking reason, then it probably should stay on the Server because if my Client has it raised up and your Client has it down for some reason and you can walk through it, you will appear to be walking through a solid object on my screen as an example of continuity errors in game.
Because reliable ordered can cause ping spikes when an unrelated packages get dropped or cause them themselves.
An example for this would be the server telling the client that a piece of wall got destroyed, i.e you are sending time sensitive data that you don’t want to wait in queue when unrelated data got dropped in the network and where it is important that it arrives eventually.
Without knowing the technical aspects of your game, streaming would cause an issue if the part is not available on the client (client too far away, part outside streaming radius, etc), but it would also be easy just to check if the known part exist before running any functions on it to avoid script crashes, etc.
I see, that’s a good example. However, if you’re playing a game and you’re constantly dropping packets up to the point of having something critical like a wall blowing not being replicated as soon as possible because other packets dropped, I think you have worse problems on hands. Either the game is poorly optimized or the player’s internet is of dubious quality in the first place, the Reliable Unordered would not be the correct “fix” for this. And it shows: they never made any internet protocol for this use case in the first place, meaning that truly there would be very little to gain from it.
-- there’s no real way to identify how long a single packet took to reach it’s final destination. even if something was implemented, this would absolutely add needless overhead as every single packet would need to carry extra information for this to work. wouldn’t it also make more sense to just have the spark effect tied to the laser beam itself? why does it need a separate animation?
-- on a side note, if a player with a connection so bad that you’re hitting 2000-3000 ping regularly is going to have more to worry about than desynced animations
The player’s internet being of dubious quality is the main reason why we have UnreliablyRemoteEvents in the first place, otherwise there wouldn’t be much of a need for them to exist. RakNet which roblox uses as its network engine has them implemented for a reason.
They did but it wouldn’t be relevant if they didn’t, roblox doesn’t use TCP to transmit data between the client and server either.
I think you didn’t quite get what I said.
between TCP & UDP, UDP was made first, it wasn’t made specifically for games either. It was just made to send data and whatever happens to it, happens. UDP was really just the first step to TCP and has its own advantages, primarily its speed compared to TCP. UDP doesn’t magically fixes all problems with players having poor internet connections either, UDP is meant to be used for events that are non-critical / vital. TCP should be used for the rest. My point is anything between TCP & UDP doesn’t make sense, because either your game is poorly optimized, or the player’s internet is too weak to handle a game of this size. On the wiki, RUDP is not standard and there is most likely a reason for that: because it’s not the right way to fix the issue you’ve mentionned. If a player is dropping packets so that a vital part of the game is not replicated in time, RUDP would only be a bandaid.
Also, Roblox does and only did use TCP for Client-Server communication until now. Unreliable Remotes use UDP.
What are you, a professional? This is not bad enough.
function UnreliableBindableEvent:Fire(...)
local Args = {...}
-- Remove a random number of arguments
-- (for optimization purposes)
while #Args > 0 do
if math.random() > 0.5 then
table.remove(Args, math.random(1, #Args))
else
break
end
end
-- Wait some time
-- (for optimization purposes)
task.wait(math.random())
-- Decide if it should actually send
-- (for optimization purposes)
if math.random() < 0.5 then
fireInternal(unpack(...))
end
end
That is a problem for any internet connection, every single player has to some degree packet loss as that is the nature of the internet and it is the task of the developer to minimize the impact it has on the player’s experience, using the same logic there wouldn’t be a need for a separate remote event type either.
It never did, it uses UDP packets with a reliability layer added on top.
Either way this is irrelevant when it comes to if there are use cases in roblox when there evidently are.
Hard disagree on what you’re saying and it’s getting too late for me to repeat again with other words what I just said. Again, if RUDP is not standard, it’s not because of a lobby or any obscure reasons, it’s just not necessary because you shouldn’t have to rely on that in the first place.
You’re going to have to show me some kind of source for that. Why would they use an UDP with some obscure reliability & ordered layer as well and not use TCP that is doing exactly that ? That just doesn’t make any kind of sense whatsoever, especially since it’s almost as easy as setting the socket’s data to “TCP” in a header / parameter.
Ok, I get it in a way. When you put “Unreliable”, then give an example as if it was the same as remote events. I was confused. I reread to make sure I had a stance to comment.
There are a couple of things to keep in mind when using UnreliableRemoteEvents:
UnreliableRemoteEvents may be dropped to prioritize bandwidth or CPU usage in addition to any loss that occurs over the network.
I can understand that UnreliableRemoteEvents can be used to help performance. After that, it’s a blank book.
Known Issues
UnreliableRemoteEvent payloads should be at most 900 bytes. Events with a larger payload will be dropped. When this happens in RobloxStudio, we will output a log message in the output menu indicating how many bytes the event has gone over. Unfortunately, this will require trial and error, but we are working to give you better tooling in the future in addition to increasing the bytes limit.
I recently just understood what keys and values are “local key = value”. Yet bytes are different. Is that a letter per byte?. As in “I love turtles”, is 14 bytes (Including the quotations).
Optimization Specialist 