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?
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.
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.
@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.
Ended up being a good old fashioned memory leak that happened to roughly coincide with this release and other bug reports, disregard.
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.
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.
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.
I hate I hate I HATEEE
how these recent modifications require models
I WANT INDIVIDUAL INSTANCE CONTROLlll
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?
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.
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)
@CorvusCoraxx Is there any extra clarification what this refers to?
If I have an Atomic vehicle and I parented an extra model to this Atomic vehicle from the server, would it not replicate for clients that have already streamed the vehicle? Or is it referring to something else?
Was just hoping to confirm since my game makes a lot of use of this on runtime (Such as parenting and welding new models to a vehicle, modifying part properties, adding new instances and forces, etc)
Are you able to create a bug report and/or simple repro place for this issue?
I’m saying that the subtree will appear on the client, but it will not appear atomically in most situations. For example, lets say you have an existing atomic model that is replicated and you add a folder as a descendant of the model and the folder has a script descendant. If you get an event for when the folder is added as a child to the model then when the folder is added as a child the script will not be a descendant yet.
I am quite unable to provide an uncopylocked repro place since I have tons of code and scripts that all depend on each other; although streaming in simpler but similar assemblies and Characters seems to work in other places seems to work as intended.
Otherwise, this is the place where it occurs (note the driving AI Vehicles streaming in and out) : Ai Test - Roblox
This property has recently disappeared from the studio Properties window. Is there any reason for this change? Does the behaviour still work in the background or has this feature been reverted?
Did you turn off streaming enabled for the place? If the place is not streaming enabled the property will not be shown.
That seems to have been the case. Sorry for any trouble caused!
It’s worth noting that I checked the Engine API page for Model before coming here, and this question could’ve been avoided by documenting this behaviour.
Assuming this is a bug. If I set TestModel2 in the screenshot below as Persistant, regardless of what TestModel is set to (in this case it is Default), everything inside TestModel is persistantly streamed. I would expect only parts in TestModel2 to be Persistant, as it is on that model that I have set the Persisant setting to. Any advice?
“Assuming this is a bug. If I set TestModel2 in the screenshot below as Persistant, regardless of what TestModel is set to (in this case it is Default), everything inside TestModel is persistantly streamed. I would expect only parts in TestModel2 to be Persistant, as it is on that model that I have set the Persisant setting to. Any advice?”
I’m unable to reproduce this problem when TestModel is set to Default. When I set TestModel to be atomic it does make everything in TestModel persistent, which is expected behavior.