Hello! I have a question about the reliability of variable replication, and in general. Let’s say there’s a variable with a default value of 10, varA, and we change this variable to 15 on the server. But when our packet with the change to this variable is sent to the client, the value on the server becomes 10. The server still thinks the client has a value of 10, because the ack packet from the client hasn’t arrived yet. This means the server won’t send the value 10 again. Now let’s look at the client. The value 15 arrived. The client changed the value to 15 and sent an ack confirmation packet. So, will this ack packet be reflected on the server in any way? Will the server assume that varA on the client now has a value of 15 or not? What if this ack gets lost, and can it get lost? Because if the ack gets lost or the server becomes unresponsive, the client will forever remain at state 15, and the server at state 10, unless, of course, we change the value on the server again.
In this regard, similar situations are interesting when working with arrays, both regular and fastarray, when an element is added and then removed almost immediately. If the packet adding the element is applied on the client, but the server thinks it wasn’t applied and won’t send the deletion request, this means the element will remain stuck on the client forever.
UDP
Although I suspect that with regular variables it works roughly as I’ll describe below, I wonder how accurate my assumptions are. If there’s a variable that’s initially 10 on the server, we change it to 15. A replication tick occurs. So, a bunch of data with the change is sent to the client. Before we receive an ack from the client, our server changes the value back to 10. Therefore, the confirmed value is still 10. The new value is 10. This means the server won’t send the message that it’s 10, but on the client, the value will become 15.
But an ack from the client is also reliable, and when it reaches the server, the server will apply the value of that bunch of data to the confirmed data. Now our server sees that the client’s value is 15, and ours is 10, and will send the bunch again with the change.
It turns out that these bunches of data changes are queued (apparently, unreal indexes them), then on the client, unreal applies them exactly in the order in which they were sent (even if they arrived in a different order, it waits until the next one arrives), and then the client sends an ack for each one to the server, and on the server, they are applied in the correct order for the “confirmed state.” The bunches are not skipped on either the client or the server - if sent, it will definitely wait for confirmation and not skip them. They are executed in the same sequence, strictly according to their number.