So a summary of my (almost certainly bad) way:
(Maybe that's the way Unity communicates Network.Instantiates behind the scenes anyway?) Just using Network.Instantiate as demora indicated seems like a much better solution. I don't know if this is intended behaviour that can be relied upon.
So if you don't assign a view id to an object on both the client and server they seem to communicate using the "unassigned" id. The Unity reference says unassigned "Represents an invalid network view ID." However, invalid, as in "will not work" (which is what I would have guessed) doesn't seem to be exactly what it means.
Unity networkview component code#
I just tested it in my code and NetworkViewID.unassigned is = to the default state of the NetworkViewID (which is view id 0) when a NetworkView is created. Reading this thread and having a bit of eureka moment I can see that was incorrect. So I was automatically able to communicate using the first view instantiated on each side. At the time I thought the first NetworkView on each side always got the view id 0. My solution was to not allocate view ids before connecting on either the client or the server for the connection manager objects (this was the only network view I had setup before connecting). (The same senario I have when connecting in my game at the moment.) If you don't Network.Instantiate the manager. Click to expand.If you Network.Instantiate the manager the initial view id allocation will be handled by Unity.
0 kommentar(er)
