koobas.hobune.stream
Error from Serializing Non Network Instance
In my network level I am getting these two errors on client machines :
View ID AllocatedID: 0 not found during lookup. Strange behaviour may occur
Received state update for view id'AllocatedID: 0' but the NetworkView doesn't exist
After some searching I found view id 0. My level has a setup area where the player can instantiate pre-play player instances for viewing / configuration. view id 0 is on this pre-play instance. I am not using Network.Instantiate for this area at all... which really begs the question.
I have tried several hacks to get this to work. I have disabled the network view and set its serialization to Off. Neither work. Any theories or suggestions would be great.
EDIT 1:
I noticed I can resend the errors if I activate the pre-play instances. Its like Unity is sending the serialization data once on activation regardless if its a network instance.
Btw, why you have deleted this question?
Since this question belongs to the same topic, here are some more points:
There is actually no network serialization, just synchronization which means values or states are transferred from the master(the owner) and updated on the slaves(all others).
Regarding your sequence, usually the server should tell the clients which level they should load. You usually use an RPC (or buffered RPC) to invoke the level load on the client.
Basically keep in $$anonymous$$d that objects which are linked with a NetworkView can't be manipulated / destroyed that easily since wou have to take care of the clones that exist on all other computers.
I was mistaken. I had read about some old known issues and mistook my error for their error.
On a second look at my code I realized an error I was making. The instance had a script which deleted all RPCs for its network view. This call was removing the network instantiate rpc. I no longer use buffered calls.
Sorry about the confusion.
There is nothing like a "network instance". Every player / peer has it's own set of objects. They are completely seperate. The only thing that actually makes a connection between two objects on different machines is the NetworkView. If two NetworkViews (on different machines) have the same NetworkViewID (which are unique across the network), they are "connected". The objects don't actually have to be the same. One could be a tree the other a car. That wouldn't make much sense, but it's possible without any problems.
There are actually only two basic ways how two NetworkView can be connected:
The NetworkView is placed in a scene and both, the server and the client, load the same scene. The NetworkViewIDs on scene objects are special. They are marked as SceneViewID. The difference to NetworkViewIDs created / allocated at runtime is that those are predefined and therefore both sides will use the same.
Using Network.Instantiate. Network.Instantiate will allocate a new ViewID for each NetworkView on the prefab you instantiate and it transfers those IDs automatically to all other players by sending an internal buffered RPC call which will instantiate the object on the client machines and assign the ViewIDs.
In both cases both peers have something in common. Either the scene, which has to be the exact same scene otherwise the networkViewIDs don't match up, or the prefab which also is the same on both sides.
If you want to avoid Network.Instantiate (which can cause a lot of trouble when it comes to removing objects due to the buffered RPC call) the usual way is to have one communication object in the first scene which establish a basic link between all peers so they can communicate.
You can use this link to send RPCs to other players and invoke the instantiation of certain objects. You have to allocate the ViewIDs manually with Network.AllocateViewID and pass those as parameters of an RPC call to the other players.
When you don't use buffered RPCs you have to "remember" each object yourself on the server machine and if a new client connects, send him the required RPCs to create all objects which are currently there.
Unity tried to make the whole Networking very easy, however because of that they sacrificed flexibility. Network.Instantiate does everything for you, but since you can't remove single buffered RPC calls it makes deleting objects way more complicated. If all buffered RPCs remain, a new client would have to execute ALL THOSE when he joins the game. Just imagine a game where you instantiate / destroy several objects per minute. When the game runs for one or two hours there are thousands of bufferd RPCs stored.
There are ways to implement a cleanup system using network groups, but it can get very complicated as well. Most people go for the manual approach and maintain their own list of objects and perform the instantiating manually on new clients.
