FishNet ObserverRPC: Owner Included On Client Predicted Objects?

Hey there, game developers! Let's dive into a curious little quirk we've noticed with FishNet's ObserverRPC when working with client-predicted objects. It seems that sometimes, even when you tell the RPC to exclude the owner, the owner still ends up receiving the message. Is this a bug, or just a nuance we need to understand? We're using Unity version 6000.0.47f1 and FishNet version 4.6.15. While it's a minor issue and easy to work around, consistency is key, and this feels a bit off compared to how non-client predicted objects behave. Let's explore this intriguing behavior together and figure out what's going on.

Understanding ObserverRPC and Client Prediction in FishNet

First off, let's get on the same page about what we're dealing with here. ObserverRPC in FishNet is a powerful tool for sending messages from the server to specific clients. It's designed to be efficient by only sending data to those clients that actually need to see it – the observers. Now, when you add ExcludeOwner = true to an ObserverRPC, the intention is crystal clear: the client that owns the object should not receive this particular RPC call. This is super useful for things like cosmetic effects or updates that only matter to other players, not the one controlling the object. On the other hand, client prediction is a technique used to make networked games feel more responsive. Instead of waiting for the server to confirm every action, the client predicts the outcome of the player's input locally and shows it immediately. This is fantastic for reducing perceived latency, but it introduces complexity because the client and server need to stay in sync. When you combine client prediction with ObserverRPC, especially with the ExcludeOwner flag, you expect a certain behavior: the owner's client should be spared from the RPC.

The Scenario: Client Prediction Meets ExcludeOwner

So, what exactly is happening? Imagine this: a client creates and spawns a client-predicted object. This means the client has local control and is already showing the object's state changing. Then, the server (or host client, which acts as both) decides to call an ObserverRPC. Crucially, this RPC is set up with both ExcludeOwner = true and BufferLast = true. BufferLast is another neat feature that ensures if a client joins late, they'll still get the last state of that RPC. The expectation here is straightforward: since ExcludeOwner is true, the client that owns this predicted object should be left out of the RPC. However, what we're observing is that the owner does receive the RPC, even though we've explicitly asked it not to. This disconnect between our intention and the actual behavior is what we need to investigate. It's not a game-breaking bug, as we can simply add a check on the client side to see if the local player is the owner and ignore the RPC if so. But it does raise questions about the internal logic and whether this is an intended edge case or something that could be refined for greater predictability. We're keen to understand the underlying mechanics that might lead to this outcome, especially when contrasted with how non-client predicted objects behave under the same conditions.

Why Might This Be Happening?

Let's put on our detective hats and ponder why this ObserverRPC behavior might be occurring with client-predicted objects. One strong possibility revolves around the timing and lifecycle of client-predicted objects. When an object is client-predicted, the client often takes ownership and begins simulating it before the server has fully acknowledged its existence or replicated it to all observers. The server might still be in the process of reconciling the object's state or determining ownership across the network. It's possible that at the exact moment the ObserverRPC is fired, the server's authoritative understanding of who the