Request: Allow null property values for expectedValues in Room.SetCustomProperties

jules43 · March 2016

Today I tried this:

Hashtable propertiesToSet = new Hashtable();
Hashtable expectedValues = new Hashtable();

propertiesToSet["ex"] = 5;
expectedValues["ex"] = null;
PhotonNetwork.room.SetCustomProperties(propertiesToSet, expectedValues);

The result I wanted/expected was that if the property "ex" had already been set then don't change it, otherwise change it to (int)5. Is there any reason why this behaviour shouldn't be supported?

The result I got was:

Operation failed: OperationResponse 252: ReturnCode: -2 (CAS update failed: there is no property='ex' on server). Parameters: {} Server: GameServer
UnityEngine.Debug:LogError(Object)
NetworkingPeer:OnOperationResponse(OperationResponse) (at Assets/Photon Unity Networking/Plugins/PhotonNetwork/NetworkingPeer.cs:1151)
ExitGames.Client.Photon.PeerBase:DeserializeMessageAndCallback(Byte[])
ExitGames.Client.Photon.EnetPeer:DispatchIncomingCommands()
ExitGames.Client.Photon.PhotonPeer:DispatchIncomingCommands()
PhotonHandler:Update() (at Assets/Photon Unity Networking/Plugins/PhotonNetwork/PhotonHandler.cs:125)

Any comments / thoughts?

Thanks

Jules

jules43 · March 2016

This is useful as it means that anyone can set the initial values with no possibility of race conditions resulting in multiple OnPhotonCustomRoomPropertiesChanged being called.

It also seems consistent with the intent of the expectedValues behaviour.

Similar results can be obtained by:

1. Having only the master client set properties, but in some circumstances that isn't desirable.

2. Setting the properties on room creation to known never used/default values.

Jules

JohnTube · March 2016

Hi @jules43,

Thank you for this suggestion. I think it is a good idea.
Let's see if my colleague @chvetsov agrees. Maybe there is a hidden downside of this but I think on server side this is how this should be handled:

foreach(key in propertiesToSet.Keys){
    if (!propertiesOnServer.Contains(key)){
       if (expectedProperties.Contains(key)) {
           if (expectedProperties[key] == null) {
              // CAS success
           } else {
              // CAS error
           }
       }
      // success without CAS
    } else {
         //
    }
}

chvetsov · March 2016

>2. Setting the properties on room creation to known never used/default values.
Not sure why this way is bad. and why do you need to set it to known never used/default values?
during joining to game you will get all properties. so you know current/initial value of any property. all what you should is use this value as expected.

i do not see any downsides of your suggestion, except time to implement/test/deploy. i mean that idea is good, but we are not able to add it tomorrow.

jules43 · April 2016

Thank-you for the feedback. It is certainly something that it is possible to workaround for now.

Tobias · December 2016

When you set properties while you enter a room (Create or JoinOrCreate), you can send room properties but they are actually only applied when you create the room. The only case where properties are not set is then when a client creates the room.

With CAS, you can use different properties for the check than those you set/modify.
So you can set one default property as "key" when you create any room and then use that as CAS check to add more, later on.
Or you can simply check which values are set once you enter the room and then update on demand.

Request: Allow null property values for expectedValues in Room.SetCustomProperties

Comments