New Improvements to Streaming Enabled

Updates Announcements
#117

But is there any way to make that ReplicationFocus part move along with the freecam? As I understood that part is stationary.

#118

You’d have to move the ReplicationFocus part yourself (because only you know the rules of where a person is allowed to look in the experience) but it is completely dynamic and will respect wherever the ReplicationFocus part moves.

1 Like
#119

Alright thanks for the help! I will try to figure out how to make that.

#120

We’ve recently enabled fixes for several issues that were reported here, or problems that were identified elsewhere. The fixed issues were:

  • Character models for players that have been streamed out may not be fully removed from memory. Fixed 2/23/2023
  • Models with ModelStreamingBehavior == Persistent will not be sent until a character or replication focus exists. Fixed 3/1/2023
  • Models with ModelStreamingBehavior != Default may not replicate correctly when stored outside of Workspace (ReplicatedStorage, ETC). Fixed 3/1/2023
  • Calling ModelInstance:RemovePersistentPlayer (or AddPersistentPlayer) for a player that is in the process of being removed, such as via the CharacterRemoved callback can result in a crash. Fixed 3/1/2023
3 Likes
#121

I’m experiencing, and have corroborated with some others, that when I have a model with ModelStreamingModel = Atomic, the PrimaryPart seems unset when first loaded (e.g. in CollectionService:GetInstanceAddedSignal) despite the parts existing because of Atomic… in fact even within a task.defer it seems the PrimaryPart becomes set.

This seems unintended, can you confirm @CorvusCoraxx @tnavarts ?

Working on converting Jailbreak to use streaming :+1:

6 Likes
#122

I believe the issue that you described, where the PrimaryPart isn’t set when the model arrives, should be resolved by a fix that we recently implemented but haven’t yet enabled. We will confirm and let you know when the fix is active, or if a separate fix will be needed.

6 Likes
Double firing of CollectionService:GetInstanceAddedSignal when applying tag in same frame that object is added to DataModel
#123

Are these issues with streaming enabled?

Case 1: HumanoidRootPart of the player undetectable by their own client.

This part always successfully runs.:

local Player = Players.LocalPlayer
local Character = Player.Character or Player.CharacterAdded:Wait()

WaitForChild(“HumanoidRootPart”) fails. It’s odd, but LeftFoot disappears too.

Case 2: Instance (presumably the InstanceID) that was just created is passed to client via remote function. Client receives “nil.” Sometimes this is still true with built in delays over a second.

Using “Persistent” to make sure parts are seen by the client only goes so far.

1 Like
#124

Am I the only one who can’t play animations in atomic? Are there specific guidelines to follow when using atomic streaming?

#125

As mentioned under “Known Issues” there is a problem with animations under atomic characters. We hope to enable a fix shortly.

2 Likes
#126

I’m unable to reproduce Case 1. Are you able to file a bug report with a repro place?

For Case 2, you may have to wait a brief time after a remote even for the instance to exist on the client. I would not expect it to take a second however. Are you able to share a simple repro place?

#127

I will try to prune down the game that has both errors. This was in the middle of the game jam, so pressure was on. Mistakes (or discoveries) may have been made. The HumanoidRootPart disappearing was very frustrating.

#128

It seems I was wrong on what I assumed the bug was. The model is actually replicating correctly but the primary part isn’t being set when the model is replicated via a CollectionService tag even though the primary part does seem to exist within the model. Here’s a repro

A fix for this issue is now active; the primary part property on atomic models should now be resolved before signals that the model has been added are fired. Please let us know if this did not resolve your issue.

1 Like
#129

@CorvusCoraxx It turns out my game has the same problem as @TheModsterRB is / was struggling with.
Entire server gets disconnected with error code 277 at random, and Roblox doesn’t register the server as dead so whenever people try rejoining the game it tries putting them into the same server.

I’d go so far as to call this a critical bug, my game does not function without streaming. The streaming mode (Opportunistic, LowMemory, etc) has no bearing on the issue, and I’ve been getting sporadic reports of this happening as far back as December, thought apparently it’s gotten markedly worse in recent weeks.

Ultimate Driving - Roblox

Ended up being a good old fashioned memory leak that happened to roughly coincide with this release and other bug reports, disregard.

1 Like
#130

It appears that attributes do not persist when streaming out and back in when set by a LocalScript. While the fix is to simply disable it from streaming out, I believe attributes should remain persistent regardless.

1 Like
#131

This behavior makes sense as the server streams things in, setting it from the client won’t replicate it normally and when being streamed in it fetches info from the server.

#132

It does to an extent, however the instance in question is also referenced by a variable on the client. I don’t think any changes should be lost when streaming out, especially if the instance is still referenced on the client.

#133

I hate I hate I HATEEE
how these recent modifications require models
I WANT INDIVIDUAL INSTANCE CONTROLlll

#134

Hey Thomas, wanted to message you directly but your PMs are disabled. A while back a fix for this rolled out and I was curious where you still have issues enabling Streaming in this place?

#135

I was made aware of this in a DM conversation with @CorvusCoraxx at the beginning of April. This is what I said to him:

With a lot of people joining, the server tends to die almost instantly as before. Once people are ‘slowly’ joining the server’s do last longer than before but its still crashing after a while.

Also, I noticed our server memory wasn’t going down at any point and mostly going up.
There’s certainly an improvement, but it doesn’t seem to have fixed the issue for us, yet. We have since reverted again.

#137

I still have issues regarding moving assemblies (like cars) with seats where NPC Characters are seated on; Both the vehicles and NPC Characters have their streaming mode set to Atomic and are both physics owned by the server.

When the vehicles and NPC Models stream in, there is a chance that the Characters “glitch” out of the seat and stay afloat on the same spot, the vehicles keep driving on as they should (I assume depending on what streams in first).

This is especially problematic because I have otherwise no ways to trace what seat the NPCs come from, as the SeatPart property of its Humanoids is nil, the Occupant property of the Seat is nil and the SeatPart doesn’t contain the SeatWeld on client side. The only inefficient way of fixing this currently is to ask the server what seats the humanoids are actually seated on the moment the vehicles stream in on client side.

https://gyazo.com/aec461c28e290d02644385d7aac5f633 (Looks laggy due to interpolation throttling)