preventOwnershipTakeover is not synchronized between clients
I might be missing something very stupid, but this doesn't seem to work for me or I'm not understanding some core concept.
I asked it here before and got confirmation that this value is indeed synchronized between all clients. Meaning when the owner toggles 'preventOwnershipTakeover' it should be reflected on all remote clients as well.
I used the Realtime+CubePlayer example to demonstrate my issue by adding a simple script to the CubePlayer prefab (script attached here).
What it does is simply show the current value of 'preventOwnershipTakeover' of the realtimeView that is next to it.
It also shows the current ownerIDInHierarchy (which synchronized well).
It also allows changing the state of the prevent property, when you are the authority.
moreover, it seems like even when I turn 'preventOwnershipTakeover' on - a remote client is able to to request (and be granted) ownership.
[ Please view attached video ]
Thanks
6 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:
----------------------
Based on the information provided in the knowledge sources, I can address some aspects of your question about
preventOwnershipTakeover in NormalVR, but there are some details that are not fully covered in the available documentation.
1. Synchronization of preventOwnershipTakeover:
The documentation doesn't explicitly state that the preventOwnershipTakeover flag is automatically synchronized between clients. This property is mentioned in the RealtimeView documentation as a setting that can be changed at runtime, but it doesn't specify how this change is propagated to other clients.
2. Ownership request behavior:
According to the Server Authority + Ownership + Lifetime Flags documentation, when preventOwnershipTakeover is true, the server should deny any client's attempt to change the ownership of an object unless it has no owner. However, your observation that remote clients can still request and be granted ownership contradicts this expected behavior.
3. Visibility of preventOwnershipTakeover value:
The documentation doesn't mention a direct way to observe the current value of preventOwnershipTakeover on remote clients. The property is accessible through the RealtimeView component, but it's not clear if changes to this property are automatically reflected on other clients.
4. Ownership synchronization:
The fact that ownerIDInHierarchy is synchronizing correctly suggests that the basic ownership system is functioning as expected.
Given the discrepancy between the expected behavior and what you're observing, there are a few possibilities:
1. There might be a bug in the NormalVR implementation.
2. The preventOwnershipTakeover flag might require additional steps to be properly synchronized or enforced.
3. There could be a misunderstanding about how this feature is supposed to work.
To troubleshoot this issue, you might want to:
1. Double-check that you're setting the preventOwnershipTakeover flag correctly on the RealtimeView component.
2. Verify that the owner is indeed setting this flag before other clients attempt to take ownership.
3. Check if there are any NormalVR updates that might address this issue.
4. Reach out to NormalVR support or community forums with your specific implementation details, as they might be able to provide more targeted assistance.
Unfortunately, the provided knowledge sources don't contain enough information to fully explain the behavior you're observing or to provide a definitive solution. It would be beneficial to consult the most up-to-date NormalVR documentation or contact their support team for more detailed guidance on this specific issue.
----------------------
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.
OK - one update. I went back a few versions - and it started behaving as expected (at least as I expect it to) in version 2.11.1
All the versions after it seem to show the same problem
Thanks for checking that for us. @NormalMark will look into this one this week for you and we'll get it fixed.
thanks, I'll continue developing on 2.11.1 in the meantime.
I'll help if there's a tested "stable" release shown somewhere so we can avoid wasting time looking into such issues
Hey, we found the bug. Working on a fix 👍