Are model value updates all received at the same time?
As stated in the title, if I updated multiple values on a model at the same time (Reliable ones for context), would it be guaranteed that on the receiving end that all these values would be received at the same time? I know for unreliable this isn't the case (At least I believe so, correct me if I am wrong), but if this is the case for reliable ones this could help drastically simplify some of my existing code around, which would be great.
As an example, if I had a transform and my model contained
position, rotation, and scale. If I set all 3 of these at once, could I consistently expect that they would all be received at the same time?Solution:Jump to solution
all changes made in the same network frame go out in the same packet. even if you hit the max packet size, they’re split but then regrouped on receive as though they were in the same packet.
sets only send delta updates but changes to models within them go out in the same packet.
what the bot is talking about here is that changes are deserialized like this:...
13 Replies
Hi @Camobiwon. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
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. In order to get an event that fires once all updates have been applied to a model, you can use RealtimeCallback.
So, in your example, if you set
position, rotation, and scale all at once, they would be grouped into the same packet but applied one at a time. It's not guaranteed that all these values would be received at the same time.
For reliable properties, when you change it, Normcore will ensure that this value is synchronized between all clients and that it is in sync before any newer reliable updates are applied to the datastore.
For unreliable properties, if you plan to change a property very often, you should use an unreliable property. Unreliable updates are not resent if they’re dropped in transit because it’s expected that another update is following shortly after.
You can find more information in the Normcore Documentation (https://normcore.io/documentation/room/common-questions#sometimes-when-i-log-the-values-on-my-model-from-inside-of-valuedidchange-not-all-the-values-that-i-set-on-another-client-update-when-are-updates-sent-out-and-how-are-they-applied).
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------<@271788139381653514> kapa.ai is still learning and improving, please let us know how it did by reacting below
Not sure if what the bot said is correct. @maxweisel if you have any insight that would be great!
i think its true unless you hit the max packet size. i don't think the order of property updates is consistent though. sometimes my priperties update in a different order
So setting all of them at the same time would have them all be received at the same time, but say it could just come in at like rotation, scale, position?
yeah
Got it, that's mainly what I need yeah. I'm assuming unreliable, like in the name can come it at any given time though?
not sure
i think it either arrives all at once or not at all
If you do know by chance, because models internally I believe are RealtimeSets, if you update only 1 reliable property I assume it only sends that single one that changed in the data packet right? If that is the case would the same thing apply to custom RealtimeSets, so if I had all those values in a set and only updated one, it wouldn't have to send out the entire thing?
Oh interesting, that could make sense if it bundles all the changes into one packet
i think sets are delta changes but ask max lol
Hopefully he sees when he wakes up lol
Solution
all changes made in the same network frame go out in the same packet. even if you hit the max packet size, they’re split but then regrouped on receive as though they were in the same packet.
sets only send delta updates but changes to models within them go out in the same packet.
what the bot is talking about here is that changes are deserialized like this:
for (deltaUpdate in packet) model.value = deltaUpdate.value
so change events end up firing as values are deserialized. so it’s possible for one to fire for propertyA but propertyB hasn’t been updated in the loop yet
Got it, thanks for the clarification, as long as I can pretty much bank on setting multiple things at the same time and having them be received in the same tick that's the most helpful to me