Invoking an RPC is similar to calling a normal function and almost as easy but there are some important differences to understand.Īn RPC call can have as many parameters as you like but the network bandwidth involved will increase with the number and size of parameters. Remote Procedure Calls (RPCs) let you call functions on a remote machine. This information is for legacy projects using the old networking system.) This is my preference so I can control when things are instantiated and destroyed, but you might want to use AllBuffered.(For new projects, you should use the new networking system introduced in 5.1. Note: In my final version I'm using RPCMode.All, not a buffered mode. Sounds like it was expected behavior if I understand what you did. I literally spent 8 hours cutting this issue from every angle and am not sure if I'm even thinking straight anymore. ![]() If you have multiple copies, you could be having similar issues of RPC-induced server-side Network.Instantiations actually instantiating on the Client(s) side. I guess the point I'm trying to make is, if you are having ghost objects even after RemoveRPC-ing, check to see how many instances are actually spawned before you try Network.Destroy or RemoveRPC. No more duplicate copies of the object, and RemoveRPCs started behaving "correctly" as well. I called Network.Instantiate directly from the server ![]() Instead of Network.Instantiating the object from within an RPC on the server, I don't know if this is a bug or intended behavior (I don't see why it should behave this way, TBH), but due to this I was not able to remove the RPC(s) correctly from the buffer for the longest time. (I confirmed that there were multiple instances of the same object being instantiated right on top of each other, all with their own unique viewIDs belonging to each player I confirmed it with their Network.Player as well) What I instead discovered was that when I call an RPC on the SERVER and perform Network.Instantiate, it actually ends up creating a separate instance of a network-instantiated object FROM EACH CONNECTED PLAYER. I just spent the whole day struggling with this issue ( sidetracked by this issue, rather), because the RemoveRPCs call didn't appear to be working correctly. Has anyone tried this, who can share their experiences/pitfalls encountered? The other option I can think of would be to make explicit all of the RPC calls included in Network.Instantiate(), which seems less ideal. So we're thinking we'd like to use Network.RemoveRPCsInGroup() to get rid of the RPCs (reserving a bunch of communication groups to be claimed by each Network.Instantiate() call). for things that don't really exist anymore. Which would work, but the RPC buffer could get really bloated with unnecessary calls, and we'd need to be careful about initialization-we wouldn't really want clients to load models, animations, etc. Now, one solution would be to add a buffered RPC call that destroys the objects. ![]() This results in ghost copies of whatever it is you instantiate and destroy. The symptom that brought this to our attention is that, because Network.Destroy() doesn't use buffered RPC calls, new clients get the calls to Instantiate already-destroyed objects and don't get corresponding messages to destroy them. The issue, as I'm sure many of you have come across, is that those buffered RPCs can stack up after they're useful. ![]() OK, I know that Network.Instantiate() works using buffered RPC calls does anyone have a recommended system for getting rid of those buffered calls after they're no longer needed?
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |