DidChangeEvents
Do the did change events on values on models fire off on the client who set the model data? or just the remaining clients who haven't set that data? is there a way I can set it up so it actually ignores the client who set the model
3 Replies
Hi @RonJames. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
When you set a value on a model in Normcore, the did change events (such as
colorDidChange in a custom model) fire on all clients—including the client that set the value. This is by design: updates to RealtimeModel objects appear to take effect immediately for the local client, and change events also fire immediately for the local client. This ensures that the local state is updated right away, as in most cases the server will accept the update and apply it. If the server later rejects the update, the datastore will roll back the value and fire the change event again to reflect the new value from the server. This behavior is described in the documentation:
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. So, for the most part, the datastore state does not need to wait for confirmation.Datastore There is no built-in way in Normcore to prevent the did change event from firing on the client that set the value. If you need to ignore the event on the client that made the change, you will need to implement your own logic inside the event handler. For example, you can check the sender's client ID (if you store it in the model) and compare it to the local client ID, then ignore the event if they match. In summary: - Did change events fire on all clients, including the one that set the value. - To ignore the event on the client that set the value, you must add custom logic in your event handler to check the sender and skip processing if needed. There is no built-in option to automatically suppress the event for the originating client. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------
...
Change events then fire again to reflect the new values.
<@378869779668140042> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
The bot is correct. When ex this code runs
myModel.myProperty = 3f; the change event would be called locally right away inside the setter.
Sometimes doing a check like if (isLocallyOwnedInHierarchy) ... inside the event handler can be enough. But that's not an option if the object is unowned by design.
If the object is unowned by design then it gets trickier. I can imagine a few hacky ways to solve it depending on your use case. Can you describe your use case in more detail?