Photon network group instantiating. Can you change group?

J_Troher

I'm wondering if you can change the group instantiation on the fly?

My scenario is this.
You can move vast distances by a background camera, but in reality, you aren't moving at all, so you're still around other players. Is there a way to change who can see you without network deleting your object and reinstantiating it?

If not. I suppose I could just delete it for everyone in that group and instantiate a new one for the player? Then when reaching said location, do the same thing, only network instantiate into a different group?

Anybody have any thoughts on this?


*Edit - Seems It's actually hard dealing with these groups. Say I'm only using maybe 6 max groups in my room. I use
PhotonNetwork.networkingPeer.SetReceivingEnabled(3, true);

Before instantiating the prefab i want into that group. Which works fine for me, yet I can still see everyone else in group 0. Though they cannot see me.

Is there any documentation on instantiation grouping? and how to separate people properly in these groups, can you send RPC's to specific groups? or do you only receive RPC's sent from who's in your group?

I have messed around with SetReceiving and SetSending and can't seem to get it right. Any help would be phenomenal.

J_Troher

Maybe I am just enabling the groups wrong?

Seems no matter what group I instantiate in, all groups can see and interact with eachother.

Does the master have to set receiving to the group (for everyone), or is it local?

In which case, if it is set for everyone, then how do I tell a photonView to only send and receive from those in it's instantiation group?

J_Troher

Okay. So setting send and receive for networkingpeer seems to be Local.
I'm very close to solving this whole situation here.

But my seemingly last issue seems to be that new people to the group, can't see clients in that group, though everyone already there can see new clients no problem.

What do I do about this? If anyone out there has any idea..

J_Troher

So my problem seems to be that when you enter a group, if there are already gameobjects instantiated for that group, they do not get picked up and instantiated for you.

So I need some kind of way to instantiate a gameobject for a client, that is supposed to already exist for them. How would I do this?

Tobias

Sorry for letting you wait for a reply. We're currently very busy and try our best.

As you found out, the groups have a considerable drawback, because they don't instantiate GameObjects of groups that a client did not subscribe to. Currently, those calls are ignored and lost for you. PUN does not keep them for you.
We've been thinking about this but couldn't implement a seamless solution yet. We have to find a workflow that will work for everyone.

This workflow is done in PUN's source code which you have. I think you could buffer "Instantiate" and "Destroy" events for groups that you ignore and "replay" those when you enter the groups. If you can leave groups, you will need to store ALL instantiate events (until there is a fitting destroy), so you can leave and re-enter the group at will.

The events are Hashtables, so they can be stored easily. Take a look at NetworkingPeer.DoInstantiate() and into OnEvent() for case PunEvent.Destroy. You should be able to find the group in the Instantiate (Destroy does not have one).

When you have a list of all GameObject instantiations, you can also destroy GameObjects locally when you leave a group. This clean up is also not done by PUN yet.

Another problem: If you set photonView.Group to some new value, this is not synchronized. The groups per view you are using locally will then differ from whatever group the other players assigned.

The implementation for that is not very elaborate. Let me know if I can help you some more about this.

J_Troher

So would it be prudent to send an RPC that changed your group and told everyone else?

I think this won't be a problem for me in particular because when leaving/entering groups I destroy and instantiate a new prefab for you.

As far as caching instantiated objects, I may have an idea forming. As I work it out ill post it here, or if I come up with a workable solution, I will post it here!

Thanks Tobias for the reply!

J_Troher

The route I was attempting was that when you joined the room, and instantiate your prefab in group 0, to buffer an RPC that adds your prefab to a gameobject list.. which then that list your prefab would interact with and set the ones inside it active or inactive based on if the photonView groups match.

As for the PunEvent's where exactly are they? I can see where they are called in switch in the networking peer,

case PunEvent.Instantiation:
                this.DoInstantiate((Hashtable)photonEvent[ParameterCode.Data], originatingPlayer, null);
                break;

I'm Looking around to where I could buffer that and have all these prefabs exist, even if it's only for one frame before I turn them off if your group's don't match thats all I'm after lol.

// load prefab, if it wasn't loaded before (calling methods might do this)
        if (resourceGameObject == null)
        {
            if (!NetworkingPeer.UsePrefabCache || !NetworkingPeer.PrefabCache.TryGetValue(prefabName, out resourceGameObject))
            {
                resourceGameObject = (GameObject)Resources.Load(prefabName, typeof(GameObject));
                if (NetworkingPeer.UsePrefabCache)
                {
                    NetworkingPeer.PrefabCache.Add(prefabName, resourceGameObject);
                }
            }

            if (resourceGameObject == null)
            {
                Debug.LogError("PhotonNetwork error: Could not Instantiate the prefab [" + prefabName + "]. Please verify you have this gameobject in a Resources folder.");
                return null;
            }
        }

So it appears theres a spot in here for a prefab cache already. ? This kinda sounds like what I need, short of actually changing their groups and enabling/disabling them.

Tobias

The UsePrefabCache is only avoiding loading of resources. It keeps the object, which should be a bit lighter CPU wise (while using more memory).