PhotonPlayer.CustomProperties

Hi,

I am thinking to use customProperties to sync the information of every player across the room, like current weapon, max_combo, ammo left in each weapon, etc.

I have a few questions, I read that the best way to set propreties is using, SetCustomProperties... which is sometimes annoying since I have to create a hashtable and populate it, and then send it to this function.

Is there a better way to update the customProperties?

Also, I'm trying to use the masterclient as an autoriative server, but if I use customProperties, the clients will have to option to overwrite the infotmation themselves, and it will overwrite the information on all players, which isn't that secure.

So is there a way to work in a safer way?

Last question, I have alot of variables stored, will it be slow to update the customProperties very frequently?

Thanks ahead,
Michael.

Comments

  • > Is there a better way to update the customProperties?
    No. Sorry. The Hashtable is the way to gather the new/updated values.
    You could potentially build your own system to store props in the format you like and on demand, make this system create a hashtable from the changed values.
    This only hides the basic principle though.

    > So is there a way to work in a safer way?
    Not really.
    Props were supposed to be editable by everyone, so the clients can cooperate. This means less restrictions and rules in all cases but a few more issues when you don't want this.

    Problem is: How should the server know who in your game can set props?
    You can either make all clients monitor prop changes and if someone is cheating you can take counter measures, or you can use the Photon Server SDK to build your own server logic for this.
    Usually, if players are able to hack the "is master client" check, they can hack a lot more and we don't see how we can check what's allowed in a general way.

    > I have alot of variables stored, will it be slow to update the customProperties very frequently?
    Quantify "a lot".
    You can update only the changed values to minimize effort. And: Maybe not every single value needs it's own key. Depending on the actual usecase, you could send bool[], byte[], etc as one value for a single key.
    Keep keys short and you should be ok.

    Also: If some value changes often, then you don't want to store it in props. You want to send a unreliable update! It's going to be sent often and doesn't need to be cached by the server, even if someone joins late. Check out the worker demo, e.g.: it does not use props for movement but new players get that info soon after joining.