Not getting ownership changed event when remote authority prevents it
So still with ownership woes ... If I call "RequestOwnershipOfSelfAndChildren" it seems to succeed regardless to the state of 'preventOwnershipTakeover' (which is fine, it might have been removed remotely - and we can always test for that locally if we want).
But if takeover is indeed prevented, it'll restore the ownership state once I assume it gets refused by the server. It seems like in this situation the 'ownerIDSelfDidChange' event of that realtimeView does not get called.
I realize that ownership was never really transfered (as far as the server goes), but locally - that even DOES get triggered when I request ownership, shouldn't it be called again when I am refused?
Is this a bug or intended behavior?
4 Replies
Hi @Niv. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
This is an interesting question about the ownership behavior in NormalVR. Let's examine the available information to address your concern.
Based on the knowledge sources provided, it appears that the behavior you're experiencing is likely intended, although it's not explicitly stated as such. Here's what we can infer:
1. Instant updates: According to the Datastore documentation, updates to RealtimeModel objects (which includes ownership changes) appear to take effect immediately for the local client. The documentation states:
"Updates to RealtimeModel objects appear to take effect immediately for the local client. Change events also fire immediately for the local client. This is because, 99% of the time, the server accepts the update and applies it."
2. Rollback behavior: The same document mentions that if the server rejects an update, the datastore rolls back the data:
"When this happens, the server sends back the rejected update or a modified version of the state in the update. The datastore then rolls the data back or replaces it with the version transformed by the server. Change events then fire again to reflect the new values."
3. Ownership requests: The Ownership documentation mentions that
RequestOwnership() takes effect immediately, but can be rolled back:
"It's worth noting that RequestOwnership() and ClearOwnership() take effect immediately, but if the server blocks the request—say, because preventOwnershipTakeover is true or because the view's parent is owned by another client—then ownership and all changes that required ownership will be rolled back."
Given this information, it seems that the behavior you're experiencing is consistent with how Normcore is designed to handle ownership requests and rollbacks. The ownerIDSelfDidChange event is likely triggered when you initially request ownership, but when the server rejects the request and rolls back the change, it may not trigger the event again since, from the server's perspective, the ownership never actually changed.
This behavior allows for optimistic updates on the client side while ensuring consistency with the server's authoritative state. It's a common pattern in real-time systems to provide immediate feedback to the user while waiting for server confirmation.
However, if you need to react to failed ownership requests, you might want to consider implementing additional logic in your code to check the ownership state after a short delay following the request. This would allow you to detect cases where the ownership didn't stick due to server rejection.
While this behavior isn't explicitly documented as intended, it appears to be consistent with the overall design of Normcore's ownership system. If you find this behavior problematic for your specific use case, you might want to reach out to the NormalVR support team for further clarification or to suggest it as a potential improvement to the API.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------<@269927864265211906> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
this bug was fixed in 2.14.0
😂 Alright ... guess I'll hold for the fixed 2.14, do you an approximate time on the next patch?
Thanks