Greetings,
Didn’t he mean : If two RPC functions in different scripts on the same gameObject have the same name ?
I mean, isn’t a RPC some sort of SendMessage ? And don’t you send a message to a NetworkView, which is related to a gameObject, so the message is only sent to the gameObject ?
yes, that’s correct. It’s only per “game object”, as the rpc’s for one object are going to be from a different networkview id than from another object. This is because you’ll probably be sending them, like I said from a different networkview id.
However, if you have two different objects with the same networkview id, then it will be called on both.
So the sentence I quoted is either incomplete, or incorrect ?
How could it be possible ? I thought NetworkViewID had to be unique ? (source)
yes, of course you want them to be unique, or as the page says:
“or else network synchronization will break.”
How do you make sure they have the same networkView ID without using network.instantiate?
I guess a simple networkView.viewID = someNetworkViewID for two NetworkView would do the job but after reading cerebrate’s answers, I think the best move is not to do that.
I don’t get this at all, i’ve been reading this stuff for 12 hours now.
If i have 3 objects on the (unconnected) client and three objects on the server, each with their unique network view id. how do i get the network views to match when the client connects to the server, so the server can send RPC calls to the right objects? 
function OnGUI () {
GUI.Label (Rect (0,450, 100, 100), networkView.viewID.ToString ());
}
I added these lines to the tutorial_2A1 scene of the M2H Network tutorial. When you launch the scene twice, you can observe they have the same NetworkViewID (I chose this scene because the same gameObject is already present twice).
Maybe you don’t need to do anything ?
I wish that were true, I’m running the server in unity and the client in a browser. The server reports different numbers to the client every time.
The M2H Networking tutorial uses prefabs with everything on one gameobject, including the pre-made networkView component. I’m trying to add the component via code but as you can tell, I can’t get their viewID’s to match at all 
So the both the client and server create an object called network_manager and adds a networkView component so that when they connect that can talk to other network_manager objects via RPC calls. But when the client connects I can’t tell the client what networkView ID to use without having already set up identical networkviews… ARG!
Why don’t you try using Network.Instantiate ? It should instantiate a gameObject for every client and those should have the same NetworkViewID.
Because the objects need to already exist before the client is connected. objects such as a player manager singleton or network management. If I wait for the client to connect then that means I can have no real network management that’s not spread throughout other classes. Or even player management for local multiplayer
and why wouldn’t you be able to.
you can network instantiate a manager for real networking and normal instantiate one for local mp.
nothing prevents you from that.
also, doing mass spreading with RPC will be something you will be regreting the sooner or later, cause even with RPC, you optimally handle all communication through 1 view and one main handling class that forwards the stuff to where they are meant to go (message notification style through delegates etc)
The reason you might want to consider that is that RPCs are not bound to the network interval so if you don’t have a central management your handling of data traffic will become complex over time.
as for getting the network view to work nicely in manual mode: Network has a function to allocate network view ids. use that one
Hi, Thanks for the reply!
i’m using the following to assign network views:
public NetworkView assignUniqueNetworkView(GameObject aGameObject)
{
NetworkViewID newViewID = Network.AllocateViewID();
networkView = (NetworkView)aGameObject.AddComponent();
networkView.stateSynchronization = NetworkStateSynchronization.Off;
networkView.viewID = newViewID;
networkView.observed = null;
debug("new network view assigned to: " + aGameObject.name);
return networkView;
}
Even if I route all RPC’s through a single object, how do I get that one object to have the same viewID as the one on the server?
Reading that was a head slap, “why haven’t I been doing that” moment for me.
I had all sorts of problems getting my network management going nicely with network classes being instantiated on each system individually before connecting rather than via Network.Instantiate after connecting. One of those things where I got a pattern in my head (the pattern being i needed the network objects on both sides before I connected - which i really don’t) and didn’t realise there was a much simpler solution.
If you Network.Instantiate the manager the initial view id allocation will be handled by Unity.
If you don’t Network.Instantiate the manager. (The same senario I have when connecting in my game at the moment.)
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). At the time I thought the first NetworkView on each side always got the view id 0. So I was automatically able to communicate using the first view instantiated on each side. Reading this thread and having a bit of eureka moment I can see that was incorrect.
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. 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.
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. I don’t know if this is intended behaviour that can be relied upon. (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.
So a summary of my (almost certainly bad) way:
It works, but as I say, having just been thinking after reading demoras post I don’t think it’s a good way to go. I’m going to branch my code and investigate changing things to work demoras way, it sounds a lot cleaner (and probably the way it’s intended that it be done).
I guess another possible way to do it would be to Network.Instantiate another seperate object and just use that to synch all your other network views after connecting. Hmm, off to ponder that I shall go.
This is identical to how I plan to do it! if, as you say, it’s safe to assume that a non-assigned network view will try to communicate with other non-assigned network views then I figure I’ll have a network_manager object that uses that to do the initial set-up. maybe even setting an assigned networkViewID once it’s connected using
function RPC (name : string, target : NetworkPlayer, params args : object[]) : void
note that it doesn’t require a network view ID, no idea where it routes the msg to tho :?
But as you say, once there’s an initial connection everything can be managed and routed through there for easy management and tracking.
I’m kinda talking cross-post here but if you have a look at the other forum post of mine with regards to the same subject, you’ll see I’m thinking about creating an event based model to handle all RPC calls including assigning network views to objects.
Any thoughts?
RPC is a method of the NetworkView class. It communicates using the view you call it on.
I’m still getting to grips with Unity I’ve only been using it for about a month so anything I say should probably be treated with care ;).
I keep all the RPCs in the scripts that they logically belong to at the moment, if it starts to cause me problems latter I may centralise and switch to a messaging system.
That said I do make all my RPC broadcast calls from the server via my own RPC method in my network management class. Signature is something like
void customRPC(NetworkView sendOver, string method, RPCMode rpcMode, params object[] parameters)
So I do have a central point where I can control the message rate in the future if needed. Although the primary reason for doing things that way was due to issues I was having implementing join in progress with the standard Buffering behaviour. So that method (and a few others for network instantiation and destruction) are used to implement a custom buffering layer.
Internally the actual communication takes place with standard non-buffered rpc calls and I have a bunch of code to manage my buffer and handle sending the messages from the buffer to new players.
Best way to get these things working, I find, is just to dig in and solve the problems as you get to them. If the solution doesn’t keep working in the long term by then you’ve learnt a bunch more and can refactor your design into something better. Code loves to evolve.