SendMonoMessage borked?

dreamora

Problem: SendMonoMessage accepts object[] parameters which is what one would expect, but unhappily SendMonoMessage then goes around and totally breaks it by checking if parameters is of length 1 and otherwise it just drops the parameters. Instead it should just forward the parameter because Unity SendMessage / BroadcastMessage accept object[] as well, not just a single object actually (its how you commonly pass around larger sets of data through messages if you don't want / need to send around Dictionary or Hashtable)

Solution: Remove the whole checking code for length and just let it pass what it got or not pass anything if the params are null


PS: A note on the todo in there: I personally would favor it if there a "notification manager" alike system basing on the observer pattern were introduced, the bruteforce "bomb all game objects" approach basically only says one thing and thats "PUN will never run on mobiles at reasonable performance at all if constant callback calling happens" because it does not cache and has no fixed list to fire to (ie event). At least unless you want to reflect all MonoBehavior extending classes to find registered event handler functions that are meant to be called.

As a first step please limit the search to
((PhotonNetworkView[])FindObjectsOfType(typeof(PhotonNetworkView)) and then .gameObject on them combined with SendMessage instead of Broadcast instead of all GOs, so only the photon network linked objects get events and only they need to handle the hit from the message spreading

Tobias

Thanks for the feedback.

The object-array-checking sounds like some workaround that wasn't cleaned up later on.
We will also take another look at the notification handling. We didn't spend much time on performance optimization yet.

Tobias

Dreamora, now that we have v1.2 out, we could concentrate on performance and improving existing features, so I would like to re-visit your topics.

We can't simply limit mono messages to PhotonViews. This will exclude plain scripts from updates and e.g. our menu won't work anymore.
We didn't invested time so far but will come up with something better. Maybe we can target the messages where possible or cache something.

I will check out the object versus object[] behaviour in SendMonoMessage. It shouldn't be a problem.

dreamora

I might not have explained myself too well. I'm not suggesting to limit it to the PhotonView. What I'm suggesting is to limit it to BroadcastMessage(PhotonView.owners) basically (pseudocode)
The alternative would be to go the Observer Pattern path. Make objects that want to get notified register themself with PhotonNetwork and those that no longer want to be informed unregister themself and only those specific component will then be called through the SendMonoMessage

The second one is clearly favored by me as its clean and much more focused. BroadcastMessage is no holy grail, its just better than GameObject.ForEach(SendMessageBomb)

Tobias

In v1.3 we changed SendMonoMessage() and tried to send the event to as few gameobjects as possible.
We think it's better than before that but we're not sure how this does on mobiles.

If you got the time, please provide feedback.

dreamora

Thanks for the update

Will give it a look after Nov 11th then when I will check the upgrade to the current Photon Versions (we have custom modification on client and server basing on PUN 1.0 and Photon 3 RC3 and I'll need to port the code, so I normally do it when enough has been changed to make sense)