Hi there!
I was reviewing my game’s error report and stumbled upon some unexpected behavior related to atomically loaded models. I’ve concluded that the descendants of atomic models that are not BasePart instances appear to load non-atomically.
The error report recorded several instances where, if an atomic model loads on a client and an object under that model is referenced immediately, the object may not yet be loaded and is therefore nil. The object classes I have confirmed to load non-atomically include: Sound, PointLight, SpotLight, SurfaceGui, TextLabel, ModuleScript, and IntValue.
This suggests a pattern where all non-BasePart objects may be affected, though I can only speculate about other object classes. The number of errors received was relatively low, but they occurred across various parts of the code, which makes the issue difficult to fix. However, this widespread occurrence also strongly indicates that it is an engine bug. I have not been able to reproduce the issue in Studio.
@EmesOfficial Thanks for reaching out. An Atomic model is guaranteed to be parented under Workspace only after the entire subtree rooted at the model has been fully received from the server and constructed. This means that once the model appears under Workspace, all of its descendants are guaranteed to be present and accessible without issues – no matter what the type of the descendent is.
However, there are cases where an Atomic model does not behave atomically. For example, if a new instance—or a subtree—is parented under an Atomic model after it has already been replicated to the client, that update is not treated atomically.
Could you clarify whether the issue you’re encountering occurs because you’re modifying the Atomic model’s subtree after it has already been replicated to the client?
Hey @dear_gee!
The issue seems like it is common to happen, so I assumed it’s something wrong on my part, because it would have been reported already (I helped fix a simple streaming bug once before, that nobody has mentioned, so this can happen). I double checked both the code and the documentation to make sure. I’m aware that instances parented to an atomic model that has been replicated already become non-atomic, but I’ve focused only on cases where that doesn’t apply.
From the gathered error data, there are 4 distinct instances where a descendant exhibiting the unexpected behavior is parented to an atomic model on the server as soon as the server starts - meaning no players are present yet. Additionally, there are 3 cases where the descendant is never moved in or out of an atomic model.
The atomic model in question for all the examples is a vehicle, which is cloned from ReplicatedStorage to Workspace upon player request. Perhaps it has to do with cloning the atomic model.
I may have just realized something while writing this response and have a question about your second paragraph. If a single object is parented to an atomic model, are ALL descendants of the atomic model treated as non-atomic during the update, or is it just that ONE specific object?
Atomicity is defined in the context of server-client replication. If a model is marked as Atomic, it will not be parented under Workspace on the client until its entire subtree has been fully constructed. However, this guarantee does not apply in cases of client de-sync. Cloning an Atomic model from ReplicatedStorage to Workspace on the client side, does not offer any atomicity.
No no yeah, that’s correct. I should have mentioned that the vehicle cloning operation is done on the server side. I’m fully aware that streaming is not supported for local objects. Any object that exists solely on the client is not subject to any streaming behavior.
@EmesOfficial To better assist with this issue, please share a reproducible file along with clear steps to replicate this behavior. Certain dynamics or nuances may be getting lost in communication, and having a repro file to study will make it easier for us to understand and provide more accurate feedback.
