Question regarding Protocol.TryRegisterCustomType()

Yury

Hello everyone,

the small question about typeCode parameter in TryRegisterCustomType method. Do you have any suggestions if I need more than 256 custom types?

Thank you.

dreamora

Beside the obvious of reconsidering what you want to do (ie if you really need that many or if its just a matter of suboptimal mapping at the time) and completely rework it to use short instead of byte for identification, I fear no ...

Yury

Any chance to get this parameter as short in Photon Server 3.0 release version?

dreamora

Well I personally hope no cause this is a corner case needed for 2 projects a year perhaps if at all (in all other cases its just bad design out of my experience with past cases where people introduced new events / messages in other networking techs just 'cause they didn't think further than 1 step' when designing it) while the rest will suffer from the higher traffic.
I would favor a proper instruction on how to change it for those who really need it (or just feel like bloating their traffic ) while leaving it at the current level for the rest

Kaiserludi

dreamora wrote:

Well I personally hope no cause this is a corner case needed for 2 projects a year perhaps if at all (in all other cases its just bad design out of my experience with past cases where people introduced new events / messages in other networking techs just 'cause they didn't think further than 1 step' when designing it) while the rest will suffer from the higher traffic.

Thanks dreamora.
This is exactly, what we had in mind when deciding for byte instead of short to hold the custom type:
Most people will just not need more than a few custom types and most times, that people need dozens of different custom types, there is just a need to think again, if their approach is really well thought. And when a byte will be enough, there is no need to increase the traffic for all users by using a short.

Yury wrote:

Any chance to get this parameter as short in Photon Server 3.0 release version?

Tell us, why you need so many different custom types. If there really is no better approach to do, what you want to do, then using all those custom types, then maybe there is a chance, otherwise we could give you some ideas how to redesign your logic, so that you do not need so many custom types anymore.

Of course you could also just serialize your stuff first and send it trough as a byte-array then.

Yury

Thank you guys for your responses. Now in my mind (design document ) I see about 50-60 data contracts that potentially will be used. The project is really quite complex and now it's just first iteration. It would be great if number of data contracts will stay between 50 and 255. But I don't know for now.

dreamora

Multiple Data Contracts don't needfully justify and require extra types.

Completely different data contracts would but thats very rare in games. Often 1 parameter changes which changes the meaning slightly (buying / selling, or the target of a given operation) but for that you don't need an extra type, you just need to design the original contract to serve more purposes than a '1 trick pony' which is a thing to avoid in networking when it could be an allrounder horse without losing anything and save you bytes

As an example: Chat to 1 person, chat to your group, chat to world does not require 3 different types of messages, that requires a single one with a target param

Yury

Thanks dreamora. I understand what you mean. Of cause I will use such parameters where it makes sense.

Tobias

Yury, you always have the option to build sub-types if needed.
The custom types are there for really commonly used classes to make them "sendable" in Photon events. Example: A Vector3 in a 3d engine. Each type defines a relatively rigid byte-order and you can't omit info easily with those. Unless you take care of that explicitly.

I think in your case, events are more likely what you need. These also have a byte-typed code but are more flexible. You could use the event code as "class" of events and add your own type if needed inside.

Yury

If I understand correctly you are speaking about how can I use more than 256 event codes not custom types codes? As I know all custom types and custom (de)serializers registered in CodeDict and TypeDict dictionaries on client and server sides. And this dictionaries uses by Photon client/server code when it process requests and responses. Am I correct? Sorry if I'm missing something.

Tobias

You are correct.