Feature request: events for non MonoBehaviour objects

Options
It looks that at the moment the only way to respond to OnConnectedToPhoton, OnDisconnectedFromPhoton, etc. is by creating a MonoBehaviour subclass and add it to your scene.

Is it possible to add support for events (might be c# specific) or some other form of callback support so that you can create non MonoBehaviour classes to react to these events (for example when creating an app using multiple scenes/levels)?

Comments

  • Tobias
    Options
    How is using multiple scenes related to using non-MonoBehaviours?

    I don't know yet what we should implement for you exactly. Maybe you give an example?
    In worst case: You can modify PUN at will. The source which calls the callbacks is there and can be replaced by whatever you like best.
    The enum PhotonNetworkingMessage contains all the callback methods we define. NetworkingPeer.SendMonoMessage() is where we call those methods.
  • I'm pretty new to Unity so maybe this setup I'm using is totally wrong. But I'm making a simple 2D game, using MVC pattern. The controller is a C# class not inheriting from the MonoBehaviour class. It is a singleton preserved between Levels. It would be nice if this controller could directly listen for events and respond to them by showing the correct visuals.

    C# only solution would be to define an c# event which contains the PhotonNetworkingMessage and maybe related data. Add an event variable to PhotonNetwork and let NetworkingPeer.SendMonoMessage fire events trough the variable. No idea what the javascript equivalent would be though.

    I rather not modify PUN myself, since I'm lazy and just want to press the update button when there is a new version :D

    At the moment I solved it by creating a stub MonoBehaviour component which implements all the event methods and calls the controller methods.
  • dreamora
    Options
    If I were you I would not use PUN in your situation but the Unity DotNet SDK from the download area here at ExitGames. It will integrate much better with your MVC than trying to make 'Unity Networking' work with it as it was developed and built fully around Unitys Component Pattern which goes against what you try to achieve with MVC generally

    When doing MVC with Unity there are a few things to keep in mind just as a warning in case you have C# background and draw potentially wrong conclussions from that side:

    * Unity classes are not GC managed (they are only proxys for unmanaged native code objects) while yours is and anything that extends System.Object etc directly will be too

    * Unity has a specific behavior at the end of scenes and start of new scenes (OnDisable, OnEnable) even for 'don't destroy' monobehaviours during which objects cease to exist. As such your controller will very likely need to be informed of the scene switch by a MonoBehaviour anyway or it will miss out on the stuff completely and probably call into null

    * A word of warning if you work outside the Unity class constraints: don't forget that when you use threads / async functionality in your controller, you are not allowed to call into UnityEngine.Object extending classes directly in any form. Unity is not threadsafe and a controller doing such calls would kill the game and even the editor
  • Thank you for your reply. Especially the first part was a duh! moment :D I never thought about it that I could probably use the .NET SDK instead of PUN.

    Also thank you for your tips; they were very much appreciated. I indeed already had a small component attached to every scene, to tell my Controller it became active.