kapa.ai
NNormal
•Created by RoyNexus on 2/27/2025 in #🤝ask-a-question
Toggle on/off network connectivity
7 replies
NNormal
•Created by RoyNexus on 2/27/2025 in #🤝ask-a-question
Toggle on/off network connectivity
For more details on offline mode and its limitations, you can refer to the Room > Offline Mode documentation.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
7 replies
NNormal
•Created by RoyNexus on 2/27/2025 in #🤝ask-a-question
Toggle on/off network connectivity
----------------------
Yes, Normcore provides an easy way to toggle between online and offline modes, which can be useful for mocking offline/online transitions in the Unity editor. This is done through the "Offline Mode" feature.
Here's how you can implement it:
1. First, make sure to uncheck "Join Room on Start" on the Realtime component in the Unity inspector if you're going to manually call
Connect()
.
2. Then, you can use the ConnectOptions
struct when calling Connect()
on your Realtime instance. The offlineMode
boolean in this struct allows you to toggle between online and offline modes.
Here's an example of how to implement this:
You can easily toggle between online and offline modes by changing the offlineMode
boolean in the ConnectOptions
.
It's important to note that in offline mode, some behaviors are different:
- Realtime.clientID
and Room.clientID
will always return 0
.
- Realtime.roomTime
and Room.time
will return the device's system time.
- The datastore state of an offline room is cleared upon calling Disconnect()
.7 replies
NNormal
•Created by RoyNexus on 2/27/2025 in #🤝ask-a-question
Toggle on/off network connectivity
Hi @RoyNexus. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
7 replies
NNormal
•Created by Niv on 2/26/2025 in #🤝ask-a-question
Not getting ownership changed event when remote authority prevents it
12 replies
NNormal
•Created by Niv on 2/26/2025 in #🤝ask-a-question
Not getting ownership changed event when remote authority prevents it
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:
----------------------12 replies
NNormal
•Created by Niv on 2/26/2025 in #🤝ask-a-question
Not getting ownership changed event when remote authority prevents it
----------------------
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."12 replies
NNormal
•Created by Niv on 2/26/2025 in #🤝ask-a-question
Not getting ownership changed event when remote authority prevents it
Hi @Niv. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
12 replies
NNormal
•Created by Niv on 2/25/2025 in #🤝ask-a-question
preventOwnershipTakeover is not synchronized between clients
10 replies
NNormal
•Created by Niv on 2/25/2025 in #🤝ask-a-question
preventOwnershipTakeover is not synchronized between clients
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:
----------------------10 replies
NNormal
•Created by Niv on 2/25/2025 in #🤝ask-a-question
preventOwnershipTakeover is not synchronized between clients
----------------------
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:10 replies
NNormal
•Created by Niv on 2/25/2025 in #🤝ask-a-question
preventOwnershipTakeover is not synchronized between clients
Hi @Niv. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
10 replies
NNormal
•Created by Niv on 2/24/2025 in #🤝ask-a-question
Getting property 'didChange' callbacks but value is identical to previous value.
43 replies
NNormal
•Created by Niv on 2/24/2025 in #🤝ask-a-question
Getting property 'didChange' callbacks but value is identical to previous value.
If this behavior is causing significant performance issues in your application, you might want to consider implementing additional checks in your callback methods to verify if the value has actually changed before performing any expensive operations.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
43 replies
NNormal
•Created by Niv on 2/24/2025 in #🤝ask-a-question
Getting property 'didChange' callbacks but value is identical to previous value.
----------------------
This behavior you're experiencing with RealtimeComponents in NormalVR is related to how Normcore handles property updates and change events. Let me explain based on the information from the knowledge sources:
The reason you're seeing 'didChange' callbacks for properties that haven't actually changed is due to how Normcore groups and applies updates. According to the Room > Datastore documentation:
"Normcore serializes all updates once per network frame (~20hz) and groups them into the same packet. When model updates are applied, they're applied one at a time, and a change event fires for that value. However, it's possible the other values from that packet hadn't yet been applied."
This means that when multiple properties in a RealtimeComponent are changed, Normcore groups these changes together and sends them in a single packet. When applying these updates on the receiving end, it processes them one by one, firing change events for each property, even if some of those properties haven't actually changed their values.
To address your specific concern about unnecessary work being done, the documentation suggests using RealtimeCallback to get an event that fires once all updates have been applied to a model. This can help you avoid processing changes multiple times for properties that haven't actually changed.
Unfortunately, the knowledge sources don't provide information about a specific grouping mechanism that you can control to prevent this behavior. It seems to be an inherent part of how Normcore optimizes network updates.
43 replies
NNormal
•Created by Niv on 2/24/2025 in #🤝ask-a-question
Getting property 'didChange' callbacks but value is identical to previous value.
Hi @Niv. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
43 replies
NNormal
•Created by Niv on 2/23/2025 in #🤝ask-a-question
Accessing the model's 'isRoomConnected', 'isOwnedLocallySelf' during OnRealtimeModelReplaced
24 replies
NNormal
•Created by Niv on 2/23/2025 in #🤝ask-a-question
Accessing the model's 'isRoomConnected', 'isOwnedLocallySelf' during OnRealtimeModelReplaced
2. Use the
didConnectToRoom
event:
Subscribe to the didConnectToRoom
event on your Realtime instance. This event will fire when the connection is fully established.
3. Check ownership after connection:
Once the room is connected, you can check and set up ownership for pre-existing models if necessary.
Here's a rough example of how you might implement this:
Remember, this is a simplified example and you'll need to adapt it to your specific use case.
If you're still experiencing issues after trying these approaches, it might be worth reaching out to the Normcore support team for more specific guidance, as there might be nuances to your particular setup that aren't covered in the general documentation.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------24 replies
NNormal
•Created by Niv on 2/23/2025 in #🤝ask-a-question
Accessing the model's 'isRoomConnected', 'isOwnedLocallySelf' during OnRealtimeModelReplaced
----------------------
I understand your concern about
isRoomConnected
being false and ownership not being set up properly for pre-existing models in the datastore. Let's explore this issue based on the information available in the knowledge sources.
1. Timing of Model Initialization:
The behavior you're experiencing might be related to the timing of when models are initialized and when the room connection is fully established. According to the RealtimeComponent documentation, for RealtimeViews that exist in a scene file, you need to wait until realtime.connected == true
, or the didConnectToRoom
event has fired.
2. Checking Connection Status:
Instead of relying solely on isRoomConnected
in OnRealtimeModelReplaced
, you might want to check the connection status of the Realtime instance. The RealtimeComponent<TModel> documentation mentions a realtime
property that gives access to the Realtime instance managing the component.
3. Ownership Setup:
For ownership, it's important to note that models can have different ownership states. The RealtimeModel documentation shows properties like ownerIDSelf
, isUnownedSelf
, isOwnedLocallySelf
, and isOwnedRemotelySelf
that you can use to check the ownership status.
To address these issues, you could try the following approach:
1. Wait for room connection:
Instead of checking isRoomConnected
on the model, wait for the Realtime instance to connect fully before interacting with pre-existing models.24 replies
NNormal
•Created by Niv on 2/23/2025 in #🤝ask-a-question
Accessing the model's 'isRoomConnected', 'isOwnedLocallySelf' during OnRealtimeModelReplaced
Let me check the knowledge base for you again. One moment! :books:
24 replies