ReceiverGroup.All doesn't seem to work for RaiseEvent?

JC@Totem

I have set players in my game to be subscribed to particular groups using

PhotonNetwork.SetSendingEnabled(enabledGroups, disabledGroups);
PhotonNetwork.SetReceivingEnabled(enabledGroups, disabledGroups);

After then joining the room with a number of players I call raiseEvent on one, with some Options set.

var opts = RaiseEventOptions.Default;
opts.InterestGroup = (byte)_pv.group;
opts.CachingOption = EventCaching.AddToRoomCacheGlobal;
opts.Receivers = ReceiverGroup.All;
PhotonNetwork.RaiseEvent(b, content, true, opts);

Note that I have use the group field on the instantiated player's PhotonView to store which group they should be sending RaiseEvents to.

When I run this test, and fire off events, they successfully trigger for the right other players, and excluding those subscribed to the other group. However, the one sending the event doesnt receive the event. For a while I did not have Receivers set to all, but even after adding that, the local player will not receive the event.

Interestingly if i send an event on the global 0 Interestgroup, the event will trigger on the local player as well as others.

Is there something obviously wrong that I am missing with this setup? What I want to achieve is the player can send RaiseEvent to their allocated InterestGroup and also receive the event themselves.

Tobias

If you set a InterestGroup, the Receivers option is currently ignored. This wasn't a problem so far, so we didn't even notice. No matter how it's implemented now, we get your point.
We think we could change the behavior but it's a decision we have to think through, because it affects everyone (we don't know if anyone used groups combined with ReceiverGroup.All but doesn't expect the events the client sent).

The workaround for the local player is a good idea. Can you work with this at the moment?

Caching and groups don't go together. If something is sent to the group != 0, it's not cached. Currently, this is by design. We would have to revisit the topic to fine tune things. If we do, we probably have to send a group's cache whenever you enable it (you could disable and re-enable it later on).

JC@Totem

I read in the code documentation that using CachingOption disables most of the other options, and removed it as a test, but the results are still the same.

var opts = RaiseEventOptions.Default;
opts.InterestGroup = (byte)_pv.group;
opts.Receivers = ReceiverGroup.All;
PhotonNetwork.RaiseEvent(b, content, true, opts);

Also I am running
Unity 5.1.0f3
PUN 1.51

JC@Totem

It seems that if I remove the specific InterestGroup then the local player will trigger the group. For the case of InterestGrouped Events, I am having to workaround this oddity by manually calling the event as follows.

The following will send to the local player.

        var opts            = RaiseEventOptions.Default;
        opts.CachingOption  = EventCaching.AddToRoomCache;
        opts.Receivers      = ReceiverGroup.All;

        PhotonNetwork.RaiseEvent(0, null, true, opts);

This will not.

        var opts            = RaiseEventOptions.Default;
        opts.InterestGroup  = group;
        opts.CachingOption  = EventCaching.AddToRoomCache;
        opts.Receivers      = ReceiverGroup.All;

        PhotonNetwork.RaiseEvent(0, null, true, opts);
        // For some reason InterestGroup > 0 means the event isnt called 
        // on the local player, and must be done manually
        PhotonNetwork.OnEventCall(0, null, PhotonNetwork.player.ID); 

Tobias

If you set a InterestGroup, the Receivers option is currently ignored. This wasn't a problem so far, so we didn't even notice. No matter how it's implemented now, we get your point.
We think we could change the behavior but it's a decision we have to think through, because it affects everyone (we don't know if anyone used groups combined with ReceiverGroup.All but doesn't expect the events the client sent).

The workaround for the local player is a good idea. Can you work with this at the moment?

Caching and groups don't go together. If something is sent to the group != 0, it's not cached. Currently, this is by design. We would have to revisit the topic to fine tune things. If we do, we probably have to send a group's cache whenever you enable it (you could disable and re-enable it later on).

JC@Totem

Thanks Tobias,
The current workaround of calling the eventCallback is adequate for now, cheers!

Our project requires players to be partitioned into groups, and some events would need to be cached for late players, or returning players after a disconnect. Using the InterestGroups for this made the most sense, by reducing traffic to currently irrelevant players. If there is some other obvious method for achieving this whether with Pun-RPC's or RaiseEvents I would welcome suggestions.

With regards to the grouping / caching exclusivity, I feel that it is a little too limiting, and hope it will be considered for review.

But for now I think It would be possible to work around it by sending some group-like identifier in the content HashTable, and send the cached events to InterestGroup=0, then manually check for the right Group identifier in the content, but this is obviously a poorer solution than nicely ordered events going only to the correct players.