There is a slight delay in the spacestation actually rendering the parts from when it was created/added to workspace. It is just added to the workspace by cloning a model in serverstorage.
It shows as though all parts are loaded into the workspace on both the client and server.
Although it is slight in the gif, I have had it take 2-3 seconds to finish rendering before.
By “rendering”, I mean not only are they unable to be seen, but they also are unable to collide. They might as well not be in game. My player falls through the ground occasionally because of this.
Is there any way I can figure out through code when the parts have fully “initialized”?
Alright, I retract my previous statement. It seems as though the raycasting can actually solve my problem here. (Although, it still might be a bit early to say.) Thanks buildthomas!
You guys can disregard this post. As is the case 99% of the time, turns out my code was just at fault. After some messing with things it turns out my “Check” for all of the parts being fully loaded in on the client was actually being done AFTER the player was loaded onto the space station. (as well as the initial raycast test).
The order of things done was essentially
Server: loads station
Server: Tells player station is loaded, and loads player into it
Client (After getting message from server): Does checks to make sure level is fully loaded
When it needed to be
Server: loads station
Server: Tells player station is loaded
Client (After getting message from server): Does checks to make sure level is fully loaded, sends message to server saying when it is fully loaded
Server(After getting message from player): Loads player into station
After fixing this I found that the parts just weren’t in workspace client side when the player was being loaded, which makes much more sense. I thought I had it this way in the first place, but I obviously forgot about it or something. Thanks for the help @buildthomas!
You could also do something like getting the number of parts in the space station model on the server, sending that to the client when you parent it to workspace, then the client can check every frame until the number of parts matches. This only works if the station’s not exactly changing, though.
You can get the number of instances in a model quite easily: #model:GetDescendants().
You might be a able to use a RemoteEvent to do this. I think that the reason the parts take a bit to appear isn’t because the engine takes time to “draw” them after it knows they’re there, but because they haven’t replicated yet since you’re temporarily bottlenecking on replication.
And replication is generally strongly ordered.
That means that if you copy in the model, and then fire a remote event on that client, the event should only get raised on the client after all of the parts in the model have replicated, so you effectively get a “replication finished” event that tells you what you’re asking for.
That might work, but I’d be afraid to rely on that behavior. It should be stable, since there’s a somewhat implicit guarantee that if you add something to a replicating container and then pass a reference in a Remote invocation, it’ll exist for the client.
Well, that actually seems to be the case. It is also essentially what I am doing right now, as right when the client gets the remote event message, the level is loaded. (so the checks the client does are “just in case”).
Just wanted to add that I did end up encountering rare instances where this wasnt the case, and the level was not fully loaded yet. So, not 100% safe to rely on.