RPCs after Player reconnected
Options
Hi
I made some board games but my big problem in all of them is:
When one player is disconnected and reconnected after some second, RPCs are called and new player sees some fake moves in wrong time.
For example, I throw dice and then move . opponent disconnect and Reconnect. he sees i throwing dice and move again.how i can manage RPCs when the player is reconnected?
I made some board games but my big problem in all of them is:
When one player is disconnected and reconnected after some second, RPCs are called and new player sees some fake moves in wrong time.
For example, I throw dice and then move . opponent disconnect and Reconnect. he sees i throwing dice and move again.how i can manage RPCs when the player is reconnected?
0
Comments
-
Hi @omid_ja,
Thank you for choosing Photon!
I'm guessing you are using Buffered RPC targets, maybe you don't need that in the first place?
You can add custom logic to identify already received RPCs and cache it locally on the client then check if the received RPC is a cached one or a new/live one.
To have more control you may switch to using RaiseEvent directly (RPC use it under the hood).
Sometimes received cached events has the sender ActorNr set to 0.
I don't think the ActorNr is exposed at the RPC level.1 -
I'm having the same issue as @omid_ja. Do you have an example script that shows how to do this and share it with us? PleaseJohnTube said:
You can add custom logic to identify already received RPCs and cache it locally on the client then check if the received RPC is a cached one or a new/live one.
To have more control you may switch to using RaiseEvent directly (RPC use it under the hood).
Sometimes received cached events has the sender ActorNr set to 0.
I don't think the ActorNr is exposed at the RPC level.
0 -
Hi @AndresPL96,
Thank you for choosing Photon!
Hey guys;
I think there is a difference between:
a- Event received not from cache (new, live)
b- Event received from cache but not received before (new, cached)
c- Event received from cache but received before (duplicate, cached)
If you want to know if a client already received and processed an event:
You need to keep track of already received events by adding a sequence number or a tag to uniquely identify events and caching the latest processed one to avoid processing duplicate ones.
It's recommended to avoid caching for such cases where receiving an already received event may break things.
it's also recommended to clean up the cached events no longer needed.
You can use room or actor properties as an alternative.
The above helps identify new events vs. duplicate (already received and processed), a/b vs. c.
However, this still does not help them if they want to know events from category b or if it's a vs. b.I don't think the ActorNr is exposed at the RPC level.My colleague @Tobias rectified this:The PhotonMessageInfo contains the sender's ActorNr for RPCs.
Optional last parameter.0
