How do you use PhotonNetwork.Instantiate with Interest Groups?
I have been experimenting with using PhotonNetwork.Instantiate with Interest Groups and am experiencing some behavior that I am curious about.
If I Instantiate using an interest group other than 0 (say 1) and then have another player join with that interest group, I can see that the Instantiatiation is saved in a “cache” that I can receive upon joining. This works well for my use case where I have multiple teams that create their characters for only their own team to see.
However I am curious how a player that is not in that group initially upon joining a room would receive the Instantiated cache associated with that interest group when they decide to join a new interest group while still connected to the room.
Is there a manual way for me to pull from the cache again for a player when they change interest groups?
That would then allow me to dynamically switch the team of a player and have the previously instantiated players of that new team be present upon switching while allowing them to stay connected to the same room.
Please let me know if I can help clarify this further.
I recognize events can’t be cached with interest groups other than 0, but because it seems like Instantiated events can, I am curious on how I can access that cache at a later time when switching to a group that would need it.
I am using the latest version of PUN 2 and Unity 2021.3.15f1.
Thank you for your time and support!
Answers
-
Maybe I can help with some details and background info:
There is no event cache for Interest Groups (> 1). Also, you can not cache events sent to only some of the players. Changing Interest Groups for PhotonViews will not be synced.
PUN sends
Instantiateas event but has to use group 0 which is always subscribed and has a cache. PUN sends a "group" value in the Instantiate event but instantiates the object anyways. Updates can be ignored, based on this value.So the PhotonView.Group is set on instantiate but not synchronized afterwards. You can look at the CullingHandler.cs, which syncs the Group value and hides objects you are "not interested" in. The CullArea is also needed. Sadly, there is no comprehensive demo for these utilities but there is quite some reference doc in the code.
PUN may complain about updates for ViewIDs, it doesn't know, so by default it needs to instantiate all networked objects. You can hide those you shouldn't see.
0 -
Thank you for your reply, Tobias.
The context is really helpful and I believe I understand the usage, however, that is not the behavior I am seeing in my client.
For example:
There are 2 players in the room. One of them only in interest group 0 and the other subscribed to both 0 and 1.
A second player does a PhotonNetwork.Instantiate call with the interest group parameter set to "1".
The player that is not subscribed to interest group 1 does NOT receive any instantiation event and no object or photon view shows up in their instance.
If a late joiner comes with their initial interest groups subscribed to both 0 and 1, that player WILL receive the instantiation event and the object associated with the previous call. Of my understanding it has been "cached".
If another late joiner comes without having subscribed to interest group 1, they will NOT receive the instantiation event or the object associated with it. Of my understanding, it seems like the cache of the instantiation event does not end up being sent to them because they are not listening to that group.
Because of this, I don't even have the chance to get the object to "hide" it like you have mentioned in your comment.
A funny way that I am trying to get the behavior I am looking for is actually leaving the room and immediately joining the room again with a new set of interest groups to be able to then receive what I can observe as an interest group specific cache associated with the instantiation interest group parameter. This behavior seemingly works but seems contrary to what you have mentioned about its intended behavior.
This was the only way I could think of to receive the cache again after being initially connected. Is there a manual way of attempting to receive the cache "again" that I could try implementing instead of forcing a leave and join to get this behavior?
Also, can you help provide any additional clarity on why the behavior of instantiation caching seems to be associated with interest groups?
0 -
The player that is not subscribed to interest group 1 does NOT receive any instantiation event and no object or photon view shows up in their instance.
If a late joiner comes with their initial interest groups subscribed to both 0 and 1, that player WILL receive the instantiation event and the object associated with the previous call. Of my understanding it has been "cached".
As said: We only cache in group 0, which is why "behind the scenes", Instantiate events are always sent in this group. In the event, we however tell everyone to which group this Instantiate belongs.
The fact that the other player does not do the instantiate is due to PUN ignoring it. I am sure the player gets the event as such. You could check this by adding some Debug.Log into PUN's OnEvent implementation.
Being able to add Debug.Log also means you can change the behaviour of PUN. You should be able to follow the Instantiation event and comment out the code that makes it ignored. There is no option, field or otherwise to do this.
I hope this helps.
0
