Photon Unity Networking 2: Room Class Reference

Creates a Room (representation) with given name and properties and the "listing options" as provided by parameters.

Parameters

roomName	Name of the room (can be null until it's actually created on server).
options	Room options.

Checks if the player is in the room's list already and calls StorePlayer() if not.

Parameters

player

The new player - identified by ID.

Returns

False if the player could not be added (cause it was in the list already).

Attempts to remove all current expected users from the server's Slot Reservation list.

Note that this operation can conflict with new/other users joining. They might be adding users to the list of expected users before or after this client called ClearExpectedUsers.

This room's expectedUsers value will update, when the server sends a successful update.

Internals: This methods wraps up setting the ExpectedUsers property of a room.

Tries to find the player with given actorNumber (a.k.a. ID). Only useful when in a Room, as IDs are only valid per Room.

Parameters

id	ID to look for.

Returns

The player with the ID or null.

Updates and synchronizes this Room's Custom Properties. Optionally, expectedProperties can be provided as condition.

Custom Properties are a set of string keys and arbitrary values which is synchronized for the players in a Room. They are available when the client enters the room, as they are in the response of OpJoin and OpCreate.

Custom Properties either relate to the (current) Room or a Player (in that Room).

Both classes locally cache the current key/values and make them available as property: CustomProperties. This is provided only to read them. You must use the method SetCustomProperties to set/modify them.

Any client can set any Custom Properties anytime (when in a room). It's up to the game logic to organize how they are best used.

You should call SetCustomProperties only with key/values that are new or changed. This reduces traffic and performance.

Unless you define some expectedProperties, setting key/values is always permitted. In this case, the property-setting client will not receive the new values from the server but instead update its local cache in SetCustomProperties.

If you define expectedProperties, the server will skip updates if the server property-cache does not contain all expectedProperties with the same values. In this case, the property-setting client will get an update from the server and update it's cached key/values at about the same time as everyone else.

The benefit of using expectedProperties can be only one client successfully sets a key from one known value to another. As example: Store who owns an item in a Custom Property "ownedBy". It's 0 initally. When multiple players reach the item, they all attempt to change "ownedBy" from 0 to their actorNumber. If you use expectedProperties {"ownedBy", 0} as condition, the first player to take the item will have it (and the others fail to set the ownership).

Properties get saved with the game state for Turnbased games (which use IsPersistent = true).

Parameters

propertiesToSet	Hashtable of Custom Properties that changes.
expectedProperties	Provide some keys/values to use as condition for setting the new values. Client must be in room.
webFlags	Defines if this SetCustomProperties-operation gets forwarded to your WebHooks. Client must be in room.

Asks the server to assign another player as Master Client of your current room.

RaiseEvent has the option to send messages only to the Master Client of a room. SetMasterClient affects which client gets those messages.

This method calls an operation on the server to set a new Master Client, which takes a roundtrip. In case of success, this client and the others get the new Master Client from the server.

SetMasterClient tells the server which current Master Client should be replaced with the new one. It will fail, if anything switches the Master Client moments earlier. There is no callback for this error. All clients should get the new Master Client assigned by the server anyways.

See also: MasterClientId

Parameters

masterClientPlayer

The player to become the next Master Client.

Returns

False when this operation couldn't be done currently. Requires a v4 Photon Server.

Enables you to define the properties available in the lobby if not all properties are needed to pick a room.

Limit the amount of properties sent to users in the lobby to improve speed and stability.

Parameters

propertiesListedInLobby

An array of custom room property names to forward to the lobby.

Updates a player reference in the Players dictionary (no matter if it existed before or not).

Parameters

player

The Player instance to insert into the room.

Returns a summary of this Room instance as string.

Returns

Summary of this Room instance.

Returns a summary of this Room instance as longer string, including Custom Properties.

Returns

Summary of this Room instance.

Gets if this room uses autoCleanUp to remove all (buffered) RPCs and instantiated GameObjects when a player leaves.

Room Time To Live. How long a room stays available (and in server-memory), after the last player becomes inactive. After this time, the room gets persisted or destroyed.

List of users who are expected to join this room. In matchmaking, Photon blocks a slot for each of these UserIDs out of the MaxPlayers.

The corresponding feature in Photon is called "Slot Reservation" and can be found in the doc pages. Define expected players in the PhotonNetwork methods: CreateRoom, JoinRoom and JoinOrCreateRoom.

Defines if the room can be joined.

This does not affect listing in a lobby but joining the room will fail if not open. If not open, the room is excluded from random matchmaking. Due to racing conditions, found matches might become closed while users are trying to join. Simply re-connect to master and find another. Use property "IsVisible" to not list the room.

As part of RoomInfo this can't be set. As part of a Room (which the player joined), the setter will update the server and all clients.

Defines if the room is listed in its lobby.

Rooms can be created invisible, or changed to invisible. To change if a room can be joined, use property: open.

As part of RoomInfo this can't be set. As part of a Room (which the player joined), the setter will update the server and all clients.

A reference to the LoadBalancingClient which is currently keeping the connection and state.

The ID (actorNumber, actorNumber) of the player who's the master of this Room. Note: This changes when the current master leaves the room.

Sets a limit of players to this room. This property is synced and shown in lobby, too. If the room is full (players count == maxplayers), joining this room will fail.

As part of RoomInfo this can't be set. As part of a Room (which the player joined), the setter will update the server and all clients.

The name of a room. Unique identifier (per region and virtual appid) for a room/match.

The name can't be changed once it's set by the server.

The count of players in this Room (using this.Players.Count).

While inside a Room, this is the list of players who are also in that room.

Player Time To Live. How long any player can be inactive (due to disconnect or leave) before the user gets removed from the playerlist (freeing a slot).

Gets a list of custom properties that are in the RoomInfo of the Lobby. This list is defined when creating the room and can't be changed afterwards. Compare: LoadBalancingClient.OpCreateRoom()

You could name properties that are not set from the beginning. Those will be synced with the lobby when added later on.