Replication for inventory, transferring items
The goal is quite common - to transfer some item from one container to another one. I can have two chests, or chest and inventory, or even transferring inside of the same container (to another slot).
I simulated with 100ms time delay for replication, it means 10 replications for a second. If for all operations we wait for an answer from the Server, it takes a time. It means that I cannot take an item before Server allows it. And I cannot put it back without permission also. It's definitely wrong.
If I don't wait for an answer from the Server and hope that next replication fixes all issues, it's wrong as well. For example, I make change 1 and send it to the Server. While I wait for replication, I do second change. Finally, I get the response from the Server with change 1, which overwrites my second change. Of course, next replication fixes this issue, however, I have wrong data for some time.
This task even more complicated if a second player wants to take the same item at the same time.
I can see just one solution: to have a revision for each change and every time check it in the client before using. If I have some data from the server with old revision, I wait for next replication to update my data. If a revision is the same or newer (if somebody else did some change also), I can update the data.
However, I feel that this method is also wrong. Because if I play with slots and don't stop, the Server never overtakes me.
The question is - how to do it correctly to avoid time delay for users?
Would it work better to only have the inventory exist on the server, not on the clients? Or at least only do inventory change operations on Server. Any time Client changes something on their end, it doesn't actually happen on their end until the server replies. That way there can be no incorrect unsynchronized changes. I know there would be a visible delay though.
answered Sep 20 '18 at 03:42 AM
Finally, I did it using just RPC from Client to Server and replication from Server to Client. The client has two sets of data: replicated and non-replicated. The client uses the non-replicated dataset. Server and Client have counters. For the client, there is two: non-replicated and replicated.
In case of some changes, non-replicated counter takes +1. The same thing Server does as well.
If the replicated counter right after replication more or equal the non-replicated counter, the non-replicated dataset takes the replicated dataset.
If there is no replication more than 1 second after the last request from the client, the non-replicated dataset takes the last replicated dataset as well.
If the non-replicated dataset does not equal the last replicated dataset, the data is not fully valid.
This method works very well for multiplayer if several players try to change one dataset.
answered Oct 13 '18 at 07:14 AM
Follow this question
Once you sign in you will be able to subscribe for any updates here