Increasing RPC count?

The whole answer can be found below.

Please note: The Photon forum is closed permanently. After many dedicated years of service we have made the decision to retire our forum and switch to read-only: we've saved the best to last! And we offer you support through these channels:

Try Our
Documentation

Please check if you can find an answer in our extensive documentation on PUN.

Join Us
on Discord

Meet and talk to our staff and the entire Photon-Community via Discord.

Read More on
Stack Overflow

Find more information on Stack Overflow (for Circle members only).

Write Us
an E-Mail

Feel free to send your question directly to our developers.

Increasing RPC count?

waxx
2014-12-05 12:11:28

Hey.

Today I got the message that my RPC-list is full and it says something about modifying the source to increase that maximum count. Not exactly sure what I should do though - can anyone help?

Comments

vadim
2014-12-05 16:49:57

Can you please post error message?

waxx
2014-12-10 13:56:19

Here's the message: http://i.imgur.com/7eVOjt3.png

vadim
2014-12-16 11:56:12

The message refers to lines of Assets\Photon Unity Networking\Editor\PhotonNetwork\PhotonEditor.cs : // LIMITS RPC COUNT if (additionalRpcs.Count + PhotonEditor.Current.RpcList.Count >= byte.MaxValue)

Try change this condition to pass rpc count more than byte.MaxValue

Tobias
2014-12-16 14:11:45

We didn't expect so many RPCs to be used but obviously we are wrong. You can't simply change the limit, sorry. The list of RPC names is ordered and the index for any entry is what we send. However, we send it as byte, which means a limit of 255. As you have the code of PUN, you could modify all related pieces to send the RPC shortcut as short. This is a bit more traffic but lots more RPC names in that list. Or you can clean up the RPCs you define and summarize some by introducing parameters. Similar tasks can maybe done by similar methods.

I can't promise any fix for this from our side before early next year, sorry.

JamesMac
2021-03-01 19:27:36

Before editing PUN code, I would like to check to see if a "fix" has been made for this issue. Specifically if you have created a centralized option to alter the limit from a byte to a short, please?

I am rebuilding sections of our game and server code and before I joined the team the previous coder had been combining RPC's to stay below the RPC limit and sent far too much data across the network that was not needed.
In short, poor practice. I am rebuilding all of this so that RPC's are specific to the purpose and only send what data is required and in the smallest data type. But this means I need a higher RPC limit.

If there is not a solution built into PUN, then I will need to edit the code to use a short for the index value instead of the byte it currently uses. ( I have run a search on the documentation and found nothing related so far.)
Thank you for the assistance.

EDIT: Currently we're using PUN v1. I had to dive into the assets folder to get the version. I am going to look at v2 while I take a break before diving back in.

Tobias
2021-03-03 16:25:18

This change did not get implemented. Prio was low as was the interest, sorry.
If you go for the leanest possible approach, you might switch to using RaiseEvent. It does not refer to networked objects and you control what goes into this.
Aside from that, modifying the type of the RPC index is OK, too.

JamesMac
2021-03-10 20:45:24

Development time is spent where the priorities are, so I can understand it not having been changed. I will commit the change to the index and limit checks.

What bothers me is that network traffic is optimized by sending only the data required and ensuring the smallest viable data types are used, not in how many unique types of RPC/network calls you have, and sending it only as frequently is required for syncing clients and server(s). For larger, more complex games, that means the addition of another byte in the index has far less of an effect on bytes sent over the network than having to combine network calls/RPC's which end up containing additional data that isn't needed for the purpose served.
Short form, I prefer control and optimized data. Every RPC I am using has a specific purpose, is target specific, and only sends the data required, nothing more.

So my point of view is much like with a sql database. Optimization and efficiency. That generally means you only send what is needed and you have a large number of different calls for updating an object, each specific to the purpose of the update.

Tobias
2021-03-12 15:20:41

Change the index to integer and you should be fine with relatively low effort. This is the leanest approach.

If you really want control or if your messages or if you are not targeting a PhotonView, then use RaiseEvent and you get even more control.

HarderUser
2022-08-27 07:12:12

I have reached the RPC maximum as well. And I have tried this approach "if (additionalRpcs.Count + PhotonEditor.Current.RpcList.Count >= 2 * byte.MaxValue)".

"RPC-list is full" message no longer pop up, but if I want to call rpc[258] from the list, the PUN would call rpc[258-256] which is rpc[2]. How do I solve this.🤣

Tobias
2022-08-29 13:18:30

See above...

Back to top