ModelStreamingMode properties for non-streaming games

Having the ability to set models to Atomic or Persistent is very valuable as a dev to help make guarantees as to what has been replicated to the player, however it is unavailable when streaming is disabled and we could very much use that to avoid writing clunky code.

Since we cannot make guarantees that the replicated model the client sees will have the children ready in the same frame, we are forced in situations where we must wait for all the children we expect.

local function ModelAddedFromServer(Model: Model)
 local Part1 = Model:WaitForChild("Part1")
 local Part2 = Model:WaitForChild("Part2")
 local Part3 = Model:WaitForChild("Part3")
 etc...
end

And what makes it even more problematic is that if you are in a situation where the model could potentially be unloaded your code will have to look something like this:

local function ModelAddedFromServer(Model: Model)
 local Part1 = Model:WaitForChild("Part1")
 if not Model.Parent then return end
 
 local Part2 = Model:WaitForChild("Part2")
 if not Model.Parent then return end

 local Part3 = Model:WaitForChild("Part3")
 if not Model.Parent then return end
 etc...
end

And this is also under the assumption we know in advance what we’re looking for, if we have a situation where we don’t know the children in advance and we need to iterate all the model’s children, there’s no easy solution there.

To simplify it, having the Atomic/Persistent properties also apply to non-streaming games would very much solve this annoying complication that is both very easy to overlook and very annoying to account for.

12 Likes

I think a more general solution would be to have something Instance:AreDescendantsLoaded() and instance:WaitForAllDescendantsToLoad()
Having to wait for descendants to load is really common, and not just for models. It doesn’t even matter if you use StreamingEnabled or not.

Writing annoying code like you showed is a huge bother, but it’s unavoidable right now. There is also a nuance,in some cases :WaitForChild() might get forever stuck if the parent gets destroyed.

1 Like

This should be implemented. Suppose a dynamic instance is added to the game hierarchy by the server during runtime (in a non-streaming game). In that case, we should have the ability to decide if we want that model to be atomic, so all children are immediately accessible to the clients.

Currently, we have to yield for any descendants we want to access.

Atomic models for non-streaming games are a must-have!