Determine If Message Was Reliable

Options
My Unity app involves a lot of networked rigidbodies in a scene, most of which are at rest. As a result, I think that the ideal Observe Option is unreliable on change. This way, if an object is at rest, it won't be utilizing bandwidth.

One issue that I have been having is that the client simulation might not realize that a PhotonView is at rest. It receives the reliable message, but due to non-determinism in the physics engine, it continues to move slightly. Is it possible for the client to know if the message received was reliable or unreliable? This way, the client code could be written so as to "lock" the rigidbody until a new message is received.

Comments

  • JohnTube
    JohnTube ✭✭✭✭✭
    Options
    Hi @kepler,

    Thank you for choosing Photon!

    By default, when a client receives an event it can't know if it was sent reliable or unreliable unless you explicitly add something custom in the payload to indicate this or use separate event codes.

    In PUN, internal event codes for PhotonView serialization are PunEvent.SendSerialize and PunEvent.SendSerializeReliable. However, I don't see how you could make use of those yourself without modifying PUN code.

    I still don't see the use case clearly.
    Maybe you need to come up with your own custom IPunObservable component?
  • kepler
    Options
    Hi @JohnTube,

    Thank you for being a part of Photon! I'm really impressed by how quickly I can set up networking using it.

    I know that I can add another byte to determine if the message was reliable or not on the receiving end, but I figured that the receiving client must already have that information (otherwise it wouldn't know which messages to ack). I was just hoping to save a byte of data.

    On a somewhat unrelated note, I'm curious about why CAS doesn't support initialization. Is the only option pre-initializing everything in CustomProperties to ensure concurrent safety?

  • JohnTube
    JohnTube ✭✭✭✭✭
    Options
    Hi @kepler,

    but I figured that the receiving client must already have that information (otherwise it wouldn't know which messages to ack)
    This is not exposed on the higher-level API. it's only available at a low level (library / ENet).

    On a somewhat unrelated note, I'm curious about why CAS doesn't support initialization. Is the only option pre-initializing everything in CustomProperties to ensure concurrent safety?
    Yes you need to create rooms w/ pre-initialized properties values. This feature (properties initialization w/ CAS) was requested a couple of times before.