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?
14 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
2.15.0 just shipped yesterday
It fixed one of the bugs Niv ran into but I believe there’s one more still in the works
I don’t have an ETA on that one but I expect it will ship in the next few weeks. it’s actively being worked on
yeah that bug is what's keeping me on 2.11.1 - the other bugs have fairly simple workaround but that other bug (not getting correct state of 'preventOwnershipTakeover' in remote clients) is impossible to work around.
But it's all good, we're working and happy so take your time figuring this one out.
glad to hear it. I know we’ve reproduced it on our end. should be straightforward to get a fix out, it’s just a more involved fix so it’ll take us a little longer
@Niv give this release a shot. I believe this should fix the bug you ran into: https://discord.com/channels/393839515074297858/852911447784947723/1349760514707685438
I'm experiencing this same behavior on a RealtimeView with
preventOwnershipTakeover, the ownerIDSelfDidChange triggers locally for a client trying to modify ownership when another client already has ownership, giving local client a false positive that the ownership actually changed, which then later gets rolled back by server, and ownerIDSelfDidChange doesn't trigger again with the rolled back data. What is the expected behavior here?, is it the first ownerIDSelfDidChange to not be triggered on the first instance?
I'm on 2.15.1 btwWill you try 2.15.4? we fixed more issues related to that
ok, will give it a stab
still same behavior. The only way I can make sure is by adding some wait time for the server to rollback
are you able to put a repro project together for us? we can get it fixed
sure, will make one