So to confirm, a part instance returned by a remote function when streaming will always be an invalid reference (i.e. unreliably nil)?
Actually I retract my retraction of the earlier suggestion WRT unique IDs, this is tremendously messy that I have to use the part’s name for this to find it uniquely inside its container. I cannot provide a friendly name for the part to players now without having to refactor a ton of code or else desync the part’s name on the client, and there’s no fast way otherwise to find the part within it’s container.
I am patching around this with the following code and using it everywhere I need to pass parts from server to client, but this solution desyncs the part’s name from the server. Hopefully this will not be an issue down the road.
I think API to obtain a part’s unique ID and efficiently wait for a child/ancestor part with that ID would solve my issues.
If the part is created in the remote function then at the time the function returns on the client the part will be invalid.
We are evaluating ways to simplify things for developers writing local scripts in streaming enabled games. Thanks for your suggestion about waiting using unique IDs.
Shenanigans! This new change completely streaming for my game (I have always used it). The NPC enemies do not show up at any range, sometimes even when my character is attacking them (range < 15 studs).
In this delightful moment, a rock was thrown by an invisible enemy. The rock shows up immediately (presumably because it does not have skinned mesh animations)
I only have skinned mesh characters, so I only know that angle. /shrug
Some never appear. Some appear when I’m right on top of them.
Actually, there are probably 3 moving parts to this. I will dig a little to make sure I am blaming the right problem.
Some NPCs are loading without any meshes. Just the Humanoid and HRP. This was client side only.
Some NPCs are not showing up at all client side.
Dialog is triggered by distance (under 20). THOSE npc’s show up, but they do not trigger dialog.
There is a change to the size of the HRP and how it reacts to the bones. My oldest models imploded, but my newer ones are fine. I will reload them. The imploded models now just scatter their parts to the wind.
I also recently added a lot of triangles at a distance (the map is approx 2k x 2k right now), so I was expecting some changes while streaming enabled. Close stuff should still show up.
“The specified replication focus has not been streamed to the client.”
I set the replication focus to the HRP and use Player:RequestStreamAroundAsync() so yeah I have no idea how it managed to fail to load in the player’s character
I think this is a studio bug because if I swap my studio view to the server and do literally anything to the player’s character such as move it the tiniest bit then it manages to stream to the client instantly.
^^ I know this might not be related but the client is still managing to play animations / use all humanoid functionality on their character even though they don’t have the bodyparts streamed in
This has been driving me crazy for the past few days so this morning I just made the decision to opt-out of Streaming Enabled as I can’t seem to fix this and I can’t risk players spawning in and being unable to see their character.
(Please note that sometimes the character respawns in the exact same location and still fails to stream in despite being the exact same pretty much)
but my game had 0 issues with streaming in the character before this change
now im just gonna wait for it to be enabled in live games and try to fix it from there…
probably gonna change to using the normal Player:LoadCharacter() and changing the character from that it may not perform as well due to replication but I assume its safer
(Probably should have mentioned I can’t reproduce this bug so im assuming the client is running out of memory due to the map being streamed in)
To update developers waiting for this change to be enabled globally, we are delaying this while we investigate some of the issues recently reported on this thread. Will update timeline when we expect to enable this soon.
Our current plan is to enable an improved version of these changes in Studio on March 22nd, followed by global enabling on March 28th if no major issues are observed.
FYI, this is no real replacement but in the mean-time (and actually quite convenient as well) you can use the returned GetInstanceAddedSignal and GetInstanceRemovedSignal events of collection service to listen for streamable parts to be added, and removed.
The issue with spawning during a heartbeat is the problem that GolgiToad shared and has been fixed. The fixed version will be enabled in Studio next week.
