OpSetCustomPropertiesOfActor Question

mmetcalfe

I am trying to add the player team and class to my actor via OpSetCustomPropertiesOfActor.

In the following code, there are no errors on the client side. On the server side, I see the team property, but I do not get the PlayerClass property coming across.

            Hashtable h = new Hashtable();
            h.Add("team", _team);
            h.Add(ActorProperties.PlayerClass, (byte)2);
            PhotonNetwork.networkingPeer.OpSetCustomPropertiesOfActor(PhotonNetwork.player.ID, h, true, 0);

PlayerClass is defined as follows:

public class ActorProperties
{
    public const byte PlayerName = 255; // was: 1
    public const byte DailyBonusAvailable = 254;
    public const byte PlayerClass = 253;
}

Am I overlooking something obvious here?

Thanks,
Michael

Kaiserludi

You have overlooked several points, some are obvious, some are not obvious:
1. When you use PhotonUnityNetworking (PUN) as indicated by the posted code, then please use the according subForum, as the client API of PUN differs a lot from the normal client API.
2. PUN only supports Strings as keys for customProperties. Byte-keys are reserved for internal properties and other types are not supported by the underlying Lite-Client-API, which is accessed by PUN. PUN only adds string-keys and throws away anything else in the passed Hashtable.
3. As ActorPorperties is a custom class, it of course does not belong to the group of dataTypes, which are natively supported by Photon. You can use all types, which you can think of, even your own ones, as values with Photon, but if they do not belong to the group of natively supported types, then you have to implement the customType interface for them.
4. When implementing a custom type on the client side, you have to either also implement it on the server-side (custom changes to the server code are currently not possible in case, that you are using the PhotonCloud, but only supported, when you host the server on your own!) or to only use it for operations, which do not trigger any serverside access to them, but only a routing of the non-interpreted data to other clients, which without custom serverside changes means, you can use custom types only in opRaiseEvent(), but not in any other operations including opSetCustomProperties()
5. When you wrap the PlayerName-property in some value, then it will not affet the buildIn playerName-property
6. I am not sure, but to me the buildIn PlayerName-property looks like broken in the current release of PUN
7. You should not count byte keys down from BYTE_MAX, but count them up from 0 to avoid collisions with internal keys (although PUN prevents you to use them at all at top-level, where they could collide with internal values, it is still a good idea to keep this in mind in case, that you may want switch to the normal Photon-API, which is more powerful, but only more complicated to use than PUN)
8. Seems, you have either not posted the calls, which you intended to post or your statement about the class, which you want to post, is wrong
9. It doesn't make much sense to me to try to store a list of keys as a vlue without storing any values with those keys
10. Well, there has not come anything else to my attention, just wanted to achieve a full score of 10

You can achieve, what you probably want, in the following way:

            h.Add(aValueOfASupportedType, "DailyBonusAvailable");
            h.Add(anotherValueOfASupportedType, "PlayerClass");

Another way would be like this:

public class ActorProperties
            {
                public const byte DailyBonusAvailable = 0;
                public const byte PlayerClass = 1;
            }

            hh.Add(aValueOfASupportedType, (byte)ActorPropertes.DailyBonusAvailable);
            hh.Add(anotherValueOfASupportedType, (byte)ActorPropertes.PlayerClass);
            h.Add(hh, "ActorProperties")

But with this way you would always have to update all your custom ActorProperties, even when only one of them has changed, as they would be handled by Photon as one single big property of the actor, so I would strongly recommend to use the first way.