PhotonVew.Find(int viewID)... wait what?

donnysobonny

Hey guys,

Hopefully the stupid amount of posts on here in such a stupidly small amount of time smells like determination and money to all of us! =p

Reet, this one has me completely baffled. I've had a good hunt around thinking someone MUST have asked this or a similar question before but i've not had any luck.

So, scenario:
I've just entered a room, I want to do a "question, answer" type RPC by sending an rpc to the other players, and waiting for a response, to know that they have loaded and instantiated into the game before allowing everyone to move. Makes sense right?

Maybe I am a complete baffoon, however this is my current logical thinking on how I would go about this:

PhotonNetwork.room.playerList gives me a list of PhotonPlayers in the room, great!
So, find that player's photonView to send an RPC to it... wait... I need to know the viewID of the photonView that I don't know yet?? XD

*mind explodes*

Yeah, same thing happened to me.

So, clearly I must be doing something wrong here. Is it really the case that I would need to pass the viewID of the photonview that I am trying to find? Or is there another way to find the PhotonView of a PhotonPlayer?

If it's maybe already been implemented in a patch (that i've not yet downloaded) my apologies. However it would make a hell of alot more sense if Photon used the PhotonPlayer.ID as the default PhotonView.viewID, since we can access the PhotonPlayer.ID from almost anywhere (considering the PhotonNetworkingMessageInfo).

As always, your help would be much appreciated.

Tobias

Hmm, you are right. More or less.
We probably should provide a list of PVs per player.
On the other hand, most scripts should not search "some" PV but be setup with a specific PV to use. Or it should target a specific object which has a PV on it.

In your case, you could also use a static scene object with a PV to communicate through. Anyone could call RPCs on it, the sender is known implicitly with the RPC and you can extract the "ready" state.

In your case, I'd actually solve it with player properties. You can use PhotonNetwork.player.SetCustomProperties(). The player is the local player and when it loaded, it can set a custom property "r" (short for "ready") to true. The benefit of this is: All states are available to new players and existing players get them updated, too.

If you needed to find some PV, you could modify the NetworkingPeer.photonViewList to be accessible. You could go through the full list and extract any PV with a specific owner. In the end, this is what we would implement as well.

donnysobonny

Hey Tobias,

Thanks again for the response.

Yeah, I had virtually the exact same ideas that you had as a work-around to the problem. I have completely given up on using the custom properies of both the rooms and players simply because of the problems i've been having with them (the problem mentioned in the post made not so long ago about the values not being ready at certain points is still a recurring problem in too many situations, i'm just ending up with way too many rerunning methods etc). Instead, i've basically built a full extension to my current build of Photon, implementing an online database as a way to create rooms and store room properties, as well as player properties.

I'll maybe go back and try and put together a list of examples where I was having problems with the custom properties. I'll be honest and say that in most cases as soon as I saw that nullReferenceError, even though I knew that the information had been set and time was given for the information to be cached on the server, I gave up and started looking at making my own extension. Possibly due to the frustration and time spent on getting to that stage in the first place. XD

Again though, thanks for your suggestions.

p.s I totally agree. Being able to find a photonView for a specific PhotonPlayer, or PhotonPlayer.ID would make a lot of sense.

Tobias

Hm.
If you can, please go ahead and write the summary of issues with properties. I'd like to learn about the real-life usecases that don't work. Maybe we can improve this.
At the moment, I tend to think you don't have to re-run code (cause there are callbacks when things change) but maybe my path is not fitting your requirements.

donnysobonny

Aye, see that would be the beauty of it. The main problem roots in the fact that the callback happens when the properties haven't yet been changed. If it were the case that I could rely on the callbacks for property changes happening when the changes have been made and cached on the server, then the properties would be very efficient.

As you've said though, it's likely that changing this might cause some problems for people who have already made a work-around. With that being said, whether it is left this way is entirely up to you.

It's unlikely that i'll find the time to replicate the issues I was facing during the development of the current project, however i'll try and spare some time once the project is completed if you're unable to replicate the issues. Ultimately, if you get the chance yourself, set up an enviroment where you do something like the following:

1) Once in the lobby, look for a room with specific properties.
2) Once found a room with specific properties, change the properties when you get in the room, then display a GUI.window with the changes (just to make use of the callback)
3) Once done that, update your own player properties
4) Have another player in the room wait for the player properties callback to happen (triggered by the changes to your local player) and display your player property changes in a GUI.window on his client.
5) At first, attempt to write your code with the expectations that the callbacks will be made when the properties are available to read from the server.

That should replicate most if not all of the problems I was facing.

Thanks again.