koobas.hobune.stream
OnServerStart not working in Build. Works in editor
Unity 5.5.2f1
Build for Windows (.exe)
I have a GameManager derived from NetworkBehavior that overrides OnStartServer:
public class GameManager : NetworkBehaviour
{
static GameManager _manager = null;
public static GameManager Instance { get { return _manager; } }
ShipManager _shipManager;
void Awake()
{
if (_manager == null) _manager = this;
else if(_manager != this) Destroy(gameObject);
DontDestroyOnLoad(gameObject);
_shipManager = GetComponent<ShipManager>();
}
#region Overrides of NetworkBehaviour
public override void OnStartServer()
{
base.OnStartServer();
Debug.Log("OnStartServer running");
_shipManager.LoadShips();
}
#endregion
}
I run in the editor and select "Host", OnStartServer is called, all my ships are created, and everything seems to run fine.
However, when I build and run in standalone, the OnStartServer function never runs and my ships are never created. Does anyone have any pointers? What am I missing here? Thanks.
I have the same issue in 5.6. Did you find the cause of this issue?
@tito91 Gosh, it's been a while since I looked at this. I am not really using the GameManager right now, although it is still part of my project. Also, I am still very new to Unity and am slowly getting more comfortable with the architecture.
Anyway, the current incarnation of my GameManager is derived from a MonoBehavior and the Singleton instance is initialized in the Awake() function override.
However, I am beginning to understand a few things about Unity that may help:
1. Creating Unity derived objects in code scripts (i.e. MonoBehavior or NetworkBehavior) is a non-starter. These objects are meant to be created in the scene and referenced either in the Inspector or as a Prefab.
2. State objects (i.e. objects that are serialized or SyncVars) should NOT be derived from Unity constructs. They can simply be basic classes or structs.
3. It seems that SyncVars cannot be null, so dummy "uninitialized" objects must be created. Also, they need default constructors.
OK, I'm rambling a bit now. But, the bottom line is that, as I become more familiar with the Unity architecture, I am starting to feel like a central "Game Manager" may not be necessary. Each entity can sort of manage it's own state, maybe with the help of some less omniscient constructs..(?) I'm still learning so we will see. Hopefully you get a few ideas from this.
