Buffered RPC

eruk

Hi fellow warriors,
Im just curious about bufferd RPC calls. Lets say i have a game session running for many hours. During gameplay someone moves Object_A at position x,y,z, calls buffered RPC and if new player joins server, he will got the message and he will modify his scene to get that Object_A to the right position. But if the Object_A is moved many times during gameplay, new joining players will get bunch of irrelevant RPC calls and will ber forced to modify their scenes many times when moving this Object_A here and there. But only last RPC call and last position of Object_A is important. This is just wasting resources. I found that there are very limited options to remove buffered RPC calls, whitch just dont allow us to wisely choose whitch RPC calls we want to remove, for example remove RPC based on timestamp or anything else, or just get acces to that buffer. So here is my question. Is there some solution for this issue, or some workaround, or am I missing something here ?

Cynikal

You could always use "PhotonNetwork.automaticallySyncScene = true;"

That will initially sync the players scenes, so all objects are...where they should be.

vadim

HI,

Do not use buffered RPC calls. They are designed for events fired quite rarely.
For position synchronization, you can setup PhotonView to observer object position or use OnPhotonSerializeView.

eruk

What im looking for is creating a small multiplayer persistent world, with 5 to 10 players online in time, with dedicated photon server, database connection for pesrsistating data and all time logged master client on same machine. But time between restarts will be about many hours, maybe days. So for updating new logged players about world state after server will be running many hours, ill have to use some notifiing system to force other clients to set their sides to right state. Probably Ill have to use some combination of player/room properties, bufferd RPC calls and maybe some own event buffer system. And that is what i was talking about.

vadim

So for updating new logged players about world state after server will be running many hours

What do 'many hours' change for state updates? It's the same for running minute or day - just send persistent state with custom event to new joined clients. Or use custom operation to request state from client

eruk

Im probably getting something wrong. If i have one hundred destroyable barrels on master client at start time, after lets say one hour, there could be twenty destroyed barrels, after many hours, there could be destroyed all of them. Clients, which are connecting later, have the same state as master client on start time, so they every time connect with one hundered barrels. So master client has to track all changes in the world and when client connect, master client has to nottify client with world changes. And i think, that i can do this with buffered RPC calls, called every time when one of barrels whas destroyed, or with some own buffered system, where ill have acces to that buffer with changes. About just sending persistent state how you wrote, for that I should have to observe all object in the scene and then send client what to create or not and this is even more work to do, or there is some built in possiblity to send actual state of the whole scene ?

Tobias

There is no built-in world state synchronization.

In case of the barrel-state, you could use Room Properties. They are set via PhotonNetwork.room.SetCustomProperties() and each key only stores the absolute, current value you set. This is better than the buffered RPCs you want to avoid.


You are using PUN client side. It is an extra layer on top of Photon's Operation/Response and Event workflow. An RPC will call the server's RaiseEvent operation and this will send events to the other players. Events can be buffered but the ways to modify this buffer are limited.
So why not roll your own?

As you use the Photon Server, it could also make sense to build something based on your game's requirements.
You only need to store 1 bool per barrel. Provided your Editor scripts assign IDs from 0..X to all barrels, you would only need to modify one bool if a specific barrel is destroyed.
You could open up the room property system to support setting values with other key types. Or better: modify SetCustomProperty to be able to set one bool in an array (by providing a key, a value AND an index in the array).

There are a lot of ways to make things work. Even more when you have the Server SDK. It's all up to modification.

omidj

hi.
in my game
people Join to room , they Send many buffered RPC like their name or their chats text and ... to others in RunTime!and
when other client with low internet speed (128) joins to room ,he Receives many buffered RPCs and room disconnect his connection from Server. they get into the room and then fail .others just get some delay.
how can i fix this problem?

i cant decrease my buffered rpcs because those are Necessary.
i tried use buffered rpc in best state.
i load a level when i get into a room.
i use RPCs and the PhotonView observe

vadim

Hi,

Probably you need to optimize buffered RPC usage.
You should not use too many buffered RPC even if connection is good. And especially if your target low speed internet clients.

omidj

i write a new code for fix it:
I Remove All Buffered Rpcs and in void OnPhotonPlayerConnect i send RPCs to new photonplayer (with delay between per rpc).
thats work nicely but is it a good solution?!?

vadim

It looks good if you really need much RPCs and can afford sending it with delays.

Tobias

Doing the buffering yourself is not a much better option. It more or less makes your system harder to test and you will have a hard time to rescue the state of a game when a new player joins but the "updating" client suddenly leaves (during the updates).

You should only use Buffered RPCs for things that should be received by players who join late.
Example: We use this for Instantiate. Anything that was created in the room should be known to new players of course.
For chat, I think you could also just skip the chat history and anyone would understand that they joined late and only see what was sent after that.

Don't use buffered RPCs when you only need to sync a value which stays "correct" and "up to date" over some time. In that case, use Custom Properties. The player.name is such a property which we even manage for you!
You can store key-values per player or in the room. This should give you some flexibility and it gives some context to the values. Let's say you store the level of a player, just so something like (pseudo code!!):

[code2=csharp]ExitGames.Client.Photon.Hashtable props = new Hashtable();
props["lvl"] = 1;
props["mood"] = (string)someMoodTheUserEntered;
PhotonNetwork.player.SetCustomProperties(props);// this gets synced with the other players.[/code2]

You can change individual key values and if you just send the new/changed ones, you keep updates low.
New players get the props before the buffered events, if I'm not confused now.


Try to keep "buffered" as low as you can, if you are already experiencing disconnects on Join. We don't limit this for you! There is no proper "this is guaranteed to work" limit, except you tested it. Photon is just offering the options to do things but it can't avoid all pitfalls (for sake of flexibility).