Sometimes, RemoteEvents which are fired are no longer be received by the server.
And honestly now remote events are a combination of some of the worse parts of UDP and TCP so I’m kind of salty.
edit:
Sometimes, RemoteEvents which are fired are no longer be received by the server.
And honestly now remote events are a combination of some of the worse parts of UDP and TCP so I’m kind of salty.
edit:
It looks like this feature is to prevent exploiters from hacking games.
However, this is a significant issue with anti-exploit systems which assume reliable delivery of remote events, including ordered events. I think a lot of games might kick players if they loose a remove event.
As far as I know ordered-reliable delivery is a contract of remote events.
This has been a major issue for me to the point that I had to find another way to get important messages across. It’d be great if we could have some Roblox engineer comment on this issue.
That is unfortunately not true
I misinterpreted the below quote based on misinformation in a different thread! See reply below
Well in that case it’s clear that they don’t want us using Remote Events how we’re using them, but they also give us no viable alternative. So I’m going to push for this: UDP RemoteEvent - #2 by GollyGreg
And then recommend that remote events are changed to guaranteed order and delivery
That comment is a little out of context. It was explaining that we don’t use TCP and that simple UDP usage could result in “most up to date” being backwards in some cases. Roblox uses a protocol on top of UDP that handles reordering/retransmission (and multiple ordering channels).
The remote events should be reliable and ordered /wrt other datamodel changes sent from the client including other remote events sent from the client.
The remote events should not be dropped when this message is displayed. the current behavior should be to queue them and process them at some rate. It is possible that the events lose relevance over time and might become invalid.
Okay good to know that they’re guaranteed in order.
Why delay reception when we can delay reception in Lua and do a better job of it by rejecting and ordering requests as we deem fit?
that is an option. It would need to make sense when included with engine remote events as well as remote events that game devs don’t have access to.
To add a bit more context to this. I was using the unofficial FPS unlocker when this happened, which I believe also increases the rate of which the client sends events to the server in general due to the task scheduler not running the typical enforced 60hz rate.