So, as it is right now, when you fire a RemoteEvent, Roblox will make sure that this event is actually fired on the other end. This is great - we can always be certain that the other end receives the information in the correct order.
However, that’s not always necessary. Say we’re continuously updating the position of a model using a RemoteEvent. In that case it doesn’t matter if a message gets lost occasionally, as long as a few of them still arrive at the other end. In fact, making sure every single message is received will eventually clog up a slower connection and thus making the game unplayable.
The reason I ask for this is because people, including myself, are often playing on slow and unstable connections. I’ve often run into the issue where the game appears to be running perfectly fine, but the server is receiving every action I take with a 2+ minute delay (or vice versa, or both), essentially making the game completely unplayable.
The ability to optimize networking in this way is kinda-sorta missing at the moment, and I’d be happy if this could be supported in the future. Thanks!
Did you happen to have Risky Strats in mind while you wrote this? Sometimes I’ll be watching a game and be literally 2-3 minutes behind what’s actually happening (the chat doesn’t lag).
I’m not sure whether this is a good request. It seems you should be using ObjectValues for data that constantly needs to be updated, at least often enough to clog the queue on slow connections.
Can you provide examples of instances where you have to continually transmit the position of a model instead, say, the start and end position as well as the time it should take to get there?
For example, in something I made a while ago, I had to continually transmit the speed at which a model was moving (and the direction due to vectors) as it could change at any moment due to being relative to the Camera’s position/rotation.
For example, in something I made a while ago, I had to continually transmit the speed at which a model was moving (and the direction due to vectors) as it could change at any moment due to being relative to the Camera’s position/rotation.[/quote]
The problem with only transmitting velocities is that you accumulate an error over time. If the position needs to be the same on all clients and the server, transferring velocities will be highly unreliable over longer periods of time.
[quote]
The problem with only transmitting velocities is that you accumulate an error over time. If the position needs to be the same on all clients and the server, transferring velocities will be highly unreliable over longer periods of time. [/quote]
That is literally how every other game does it, as far as I’m aware.
Every so often they tell other clients the velocities of other objects, and destinations of objects which have a set destination.
The clients simply interpolate between those.
[quote]
The problem with only transmitting velocities is that you accumulate an error over time. If the position needs to be the same on all clients and the server, transferring velocities will be highly unreliable over longer periods of time. [/quote]
That is literally how every other game does it, as far as I’m aware.
Every so often they tell other clients the velocities of other objects, and destinations of objects which have a set destination.
The clients simply interpolate between those.[/quote]
That might work for visual effects, but for movement of a character or vehicle that’s not nearly accurate enough.
What you’d usually do is send the position of the character to the server as frequently as you can (in intervals roughly around half your ping). The server then simply forwards this information to the clients, which will then extrapolate from that information to figure out where you are right now - up to a few hundred milliseconds after that information has been sent.
Usually you’d calculate the velocity through the difference between the last two points and the time between them. You could go even further and go back a few more points and figure out the acceleration of the character, giving you an even more accurate estimate.
This is known as dead reckoning and is frequently used to handle player positions (and even the positions of NPCs and physics objects, which are controlled by the server).
Yes, you can make this more accurate by also sending the velocity, but only the velocity by itself will accumulate massive errors very quickly.
Now of course, allowing messages to get lost will hurt the overall accuracy, but it’s kind of a question of which is the lesser evil: Do you want less accuracy on a slow connection, or do you want people on slow connections to lag behind by a few minutes? This is kind of the reason information packets containing player positions and velocities are (almost) always sent ‘unreliably’, meaning the packets are sometimes discarded along the way in order to not clog up the connection.
To clarify, you want some form of UDP communication opposed to the TCP that we currently have? There seems to be similar pros and cons of each network protocols when compared to the two types of functionality you want.
Basically, yes. UDP is actually more suitable for games generally because it’s more lightweight overall and doesn’t clog the connection like TCP does, because it allows packets to get lost and arrive in the wrong order. TCP carries a lot of overhead that wouldn’t be needed in a lot of cases.
Don’t get me wrong, the reliability offered by TCP is nice, but in some cases it’s obsolete and more trouble than it’s worth.
Basically, yes. UDP is actually more suitable for games generally because it’s more lightweight overall and doesn’t clog the connection like TCP does, because it allows packets to get lost and arrive in the wrong order. TCP carries a lot of overhead that wouldn’t be needed in a lot of cases.
Don’t get me wrong, the reliability offered by TCP is nice, but in some cases it’s obsolete and more trouble than it’s worth.[/quote]
I totally agree. I did some research on the two in the past and UDP is definately more reliable in some cases, especially with the constant data flow that ou find with games.