Cannot serialize DateTime?

dubbreak

Seriously? I can register a de/serializer for the type I guess, or just convert to/from OADate in my code (which is a double).

Am I going to have to custom handle Guid as well or does that serialize to a byte[] automatically?

dubbreak

So GUID isn't supported either (by default).

I'd really like all types in the System namespace to be supported:
-DateTime
-Decimal
-guid
-timespan

Supporting nullable type of the available ones would be good as well.

dreamora

Nullable makes 0 sense.
Networking is to send state and state updates, if you have nothing to send then just don't send anyhting, cause the overhead is massive for sending messages even with Photons batching as it still needs to process 'nothing' on multiple places.

Photon supports the relevant types for games (as its a gaming oriented networking) though not sure if double and long work, cause if not that would definitely be on the list of types that need to be supported.

GUID is about the most useless thing to send cause there is no GUID with networking when a client provides it. there is a guid for your local machine and thats where it ends. If you want a unique identifier then add a functionality for that to photon to get one assigned from the only authority that knows about uniqueness at all which is the server backend.

Datetime also is only of limited use cause UTC enforcing has its drawbacks (yet would be the very least thing that would be required). Also its not the most efficient format

Kaiserludi

@dreamora:
Yes, long and double are both supported.

Tobias

We could hardly support all available types. Someone else might need Lists or Queues, etc.
Instead, we made it (relatively) simple to integrate needed types, so you will never really get into a dead end.

GUIDs can either be sent as strings or byte-arrays.

dreamora

Kaiserludi wrote:

@dreamora:
Yes, long and double are both supported.

Thats what I assumed. Thanks for the clarification.

dubbreak

Tobias wrote:

We could hardly support all available types. Someone else might need Lists or Queues, etc.
Instead, we made it (relatively) simple to integrate needed types, so you will never really get into a dead end.

GUIDs can either be sent as strings or byte-arrays.

Obviously. However the types I mentioned are all in the system namespace and basic types. Queues etc are complex data types that can be transferred by other means.

dubbreak

dreamora wrote:

Nullable makes 0 sense.
Networking is to send state and state updates, if you have nothing to send then just don't send anyhting, cause the overhead is massive for sending messages even with Photons batching as it still needs to process 'nothing' on multiple places.

And if an item is changing from something to nothing? The overhead of sending null (if you need to) would be the same or less than sending a value. I choose how often I send it, so overhead isn't an issue. Just because you have no use for it doesn't mean no one else will. Have you ever used nullable types? If you have think hard, you might be able to dream up some way it makes sense (rather than a knee jerk reaction that smells of false consensus effect).

dreamora wrote:

Photon supports the relevant types for games (as its a gaming oriented networking) though not sure if double and long work, cause if not that would definitely be on the list of types that need to be supported.

And if double why not decimal?

dreamora wrote:

GUID is about the most useless thing to send cause there is no GUID with networking when a client provides it. there is a guid for your local machine and thats where it ends. If you want a unique identifier then add a functionality for that to photon to get one assigned from the only authority that knows about uniqueness at all which is the server backend.

GUIDs aren't just for identifying machines. Plenty of uses for a GUID (even if you can't think of one) and it's a basic type in the System namespace. I'm not asking for a GUID generator on the client side, just support for the type so I don't have to convert it to a byte array (definitely not converting to a string array).

dreamora wrote:

Datetime also is only of limited use cause UTC enforcing has its drawbacks (yet would be the very least thing that would be required). Also its not the most efficient format

I agree it's not the most efficient format, but as a developer I should be smart enough to know if it's worth the overhead or not. In this case sending datetime (especially with the frequency) would have been fine. OADate is more efficient though.

dreamora

I'm not talking about GUID for machine identification but for what the short stands: Global Unique Identifier
As such it has to be globally known and in a networked, authorative environment, only the authorative client / server can provide you with them.

do it on any other end and I will guarantee you that you will get clashes due to non-uniqueness
Look at the PhotonView ID problems on instantiated prefabs to get a feel for what happens if you approach the problem from the wrong end. As long as the PhotonCloud doesn't get a function to provide unique longs for a room, that problem is never gonna vanish, it will only be more or less visible depending on the message travel times that hide or do not hide it.