Disabling registered realtime object
If I've spawned a realtime object that has successfully registered with the datastore and I want to disable that object just for let's say the local client for a time (maybe for area of interest or something like that), if I were to reenable that object would it resync to the current data store state or just break?
The edge case I can think of is if the object was destroyed by another client that probably the destroy call wouldn't be synced on reenable so you'd have some phantom local object on one client now, but I could be wrong.
5 Replies
Hi @foundrey. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Disabling a GameObject with a
- Do not disable the root GameObject or its
RealtimeView or RealtimeComponent is not recommended in Normcore. According to the documentation, scene RealtimeViews register with Realtime in Start(). If they are disabled, they will never register: Realtime will neither initialize them nor connect them to the datastore. For already registered objects (such as prefabs instantiated via Realtime.Instantiate()), disabling the RealtimeView itself is not supported and can lead to desynchronization issues.
Instead, the recommended approach is to use a custom RealtimeComponent to enable/disable child GameObjects, scripts, or renderers directly, rather than disabling the root object or its RealtimeView component. This way, the object remains registered and synchronized with the datastore, but you can control its visibility or activity locally as needed.
Regarding your edge case: if the object is destroyed by another client while you have it disabled locally (and thus not processing updates), you risk ending up with a "phantom" object on your client, since the destroy call would not be processed. This is a real risk, as Normcore does not synchronize parent/child relationships or handle re-registration of disabled views, and disabling a RealtimeView can break synchronization between clients, leading to desyncs and orphaned objects RealtimeView Common Questions.
Summary:- Do not disable the root GameObject or its
RealtimeView component.
- Instead, disable child objects, scripts, or renderers for local-only effects.
- If you disable a registered object and it is destroyed remotely, you may end up with a phantom object locally, as the destroy event will not be processed.
For more details, see the official guidance:"We generally recommend that you don't [reparent or disable a game object with a RealtimeView or RealtimeComponent on it]... This can result in desyncs between your clients."RealtimeView Common Questions ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------
<@719968242445058051> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
Yeah the docs make sense there I guess I was more curious what the extent of desync you get and if it's systemic or recoverable on reenable
I think local interest stuff is on the to do list
for the moment you can split the world into multiple rooms and only connect to rooms that you are interested in
you might need a host that connects to all rooms so they don't spin down for being empty though
the model updates even if you disable the area
there’s no desync
We don’t use Update() on RealtimeComponents or models to do any syncing so disabling once it’s already connected has no affect on network sync