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.
5 Likes
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.
6 Likes
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.
1 Like
When you create a new character model for the player, are you setting player.Character equal to the new model? If not, you could try that
1 Like
@CorvusCoraxx sent me a really interesting suggestion in private messages to not spawn during a Heartbeat
previously I was spawning right after task.wait ( aka the next heartbeat)
I swapped it to RunService.Stepped:Wait() and my problem appears to be fixed
2 Likes
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.
3 Likes
The improved version with the fix for parts created during heartbeat is now enabled in Studio.
2 Likes
Looking good over here! Thanks for the update!
1 Like
Shouldn’t it be enabled now or was there another issue?
1 Like
Sorry, should be enabling today. Will update when enabled.
1 Like
Hello! My game is heavily reliant on Streaming Enabled, and while playing the last few days, I have noticed that having it turned on, instantly crashes my client, both in-studio and in-player.
I’ve tried re-installing Roblox & Studio twice, deleting all related files etc.
However, turning streaming enabled off, fixes the issue completely.
It should be noted I have an RTX3090, 5900x and 1000Mbit internet connection, so I doubt the problem is on my end, since it only started happening to suddenly.
3 Likes
Hi!
We make a vehicleseat on the server, and sit people down on it. By doing this without a wait() between these steps, the player is seated in the new camera mode. When I add task.wait(.011) it uses the old camera mode.
I reported earlier on release of the new vehicleseat camera, that seating players locally triggers the new camera, but seating players from the server does not. It appears that the delay causes the seating to be done ‘locally’, probably because the seat is not streamed yet at the moment of seating the player.
This took me quite long to find and fix. It seems to have also caused a bug when sitting down in first person, zooming out, and getting up, which is fixed by the same workaround. However, after the hotfix (adding wait(0.011)), sitting down in first person mode warps the camera to third-person view (I’m not 100% this is not a side effect of one of my own scripts, but I don’t think this happened before). By setting the localPlr.CameraMinZoomDistance manually to 0 after seating, this magically fixes it.
I was quite lost on this problem, but I think we solved it. I just cannot guarantuee that it works for all devices and connections, since I tested with a low ping and fast device. But waiting on the server for something to stream to the client, and only then seating on the server, may cause ‘race conditions’ effects where the wait() is not long enough. I am also not a big fan of such a wait(.011) statement, but unsure how to properly wait for the part being streamed to the client…
Any further advice is very welcome, or please take note of this side effect. It would in fact be nice for us to be able to trigger the new vehicleseat camera while server-side seating - we were not able to accomodate local seating in the context of our experience.
Thanks for continuing improvements to streaming enabled, Snow Resort makes very good use of streaming! Dealing with partially streamed mechanisms was doable when very careful, but indeed quite challenging at times. 
2 Likes
Rather than using a timed wait the recommended way to wait for a particular instance to be streamed is via Instance:WaitForChild
Thanks, but since I make the part on the server, using WaitForChild() on the server before seating players on the server, would not seem to make a difference. Just now I tested that to be sure.
Indeed, one way would be to check on the client if streaming completed, and then send a message back to the server. This would in turn however introduce too much noticable latency. The 0.011 seconds is admissible.
I may end up implementing that anyway if the current solution leads to problems, unless perhaps a fix/further changes appear imminent.
Also, I wasn’t able to fully reproduce the described behaviour in a standalone place, in that the workaround at first didn’t seem to work. I didn’t spend too much time on it to be frank.
Thank you for your help and suggestion!
Sorry for my misunderstanding. Are you able to create a simple repro place that demonstrates the problem and file a bug report?
1 Like
Thank you, I will try tomorrow to improve the standalone reproduction. However, I think that after many years on the forum, being featured and visiting RDC, I still have no permissions to post on the bug report board. European office hours tomorrow, so I will post here after work.
2 Likes
Hi!
I’m sorry, it seems I drew some incorrect conclusions. In my tests, the new camera mode works fine, even when seating from the server. The only bug that remains is the first-person mode bug. Strangely, the workaround that fixed this in Snow Resort also doesn’t fix the first-person mode bug in my tests.
The first-person bug has already been reported elsewhere in January 2021 and is said to be already filed into a ticket to an internal database (I just found out). Apologies to be superfluous, the rest of this post relates my investigation and tests and is fully non-obligatory and non-recommended to read. Thank you for your support earlier!
In case it may shed any light on anything, though in retrospect likely it won’t:
To see the first-person mode bug, go to my test place, and immediately on entering the game, scroll to zoom in to first-person mode. After a few seconds a car will spawn and you will be seated (from the server) into its vehicleSeat. Zoom out into third-person mode, and jump to get off the seat. Now the character moves strangely, staying aligned with the camera angle. Zooming in and out fixes it back to normal.
In Snow Resort, setting localPlr.CameraMinZoomDistance = 0 locally, right after being seated, prevents this bug from happening. However, in my test place, it still happens regardless.
This bug can actually be reproduced much more easily with just any vehicleSeat in workspace. I added one next to the spawn to demonstrate.
About the camera mode bug in Snow Resort, I am completely lost why this happens. Our conclusion that it was caused by seating on the server is (at least now) incorrect. We don’t override any scripts by forking them into StarterPlayerScripts or StarterCharacterScripts. I tried to reproduce as many settings from Snow Resort into the test as I could think of that might have an effect, including our StreamingEnabled settings, a disabled vehicleSeat, etc. Even when I copy the reproduction test into Snow Resort, the camera works fine. Using the Snow Resort sled in the test place (instead of my makeshift car), the camera works fine. Something on our end is breaking the new camera mode for the Snow Resort sleds in Snow Resort, but I cannot figure it out. The code is kind of extensive, making it difficult to pinpoint, and I used up all my leads. However it seems, in retrospect, unrelated to this StreamingEnabled change.
Since the first-person bug happens for any vehicleSeat, much of the test place environment I created is almost obsolete. But just for completeness, I will describe the contents:
A script called TestScript in workspace looks for new players and gives them a car. Setting the networkOwner to the player has no effect at all, but I tested that too. According to the boolean ‘addWait’ a task.Wait(0.11) is executed (but in the test no amount of waiting has any effect at all). It then fires a remoteEvent in ReplicatedStorage. A localScript in StarterGui listens to the remoteEvent and sets up the car controls locally. Directly after this, the localscript sets localPlr.CameraMinZoomDistance = 0, but again, this now has no effect at all and no longer fixes the first-person bug.
In Snow Resort, adding localPlr.CameraMinZoomDistance = 0 locally in the same way, immediately after being seated from the server, magically fixes the first person bug. To be honest I am completely stumped, but also very tired. Sorry to previously relate incorrect conclusions, I have now simply given you any and all info that I could be sure of. Later I will try again to get the new camera mode to work for Snow Resort, if I find any more clues that might be relevant to any platform bug I will report them. Apologies for my confusion and extensive investigative writing. It’s probably implausible that this post may be of any help to at least solve the first-person bug.
Thank you for your help and time!
Some final practical info:
-Both studio and live-game behaviour seems to be identical in all cases, as far as I could tell (both on Snow Resort and the test place).
-I only tested on my PC. I use a 3.4Ghz quadcore intel-I7, GeForce GTX 3060 with 16 MB RAM and Windows 10 Pro.
-The test place is uncopylocked, of course.
1 Like
Is there any chance for us to receive a property that changes the streaming rate of parts?
By example, if your place is extremely detailed, have a big map and a long streaming range, this change causes the client to load massive amounts of parts, obviously dropping the FPS every single time.
Is there any planned feature to fix this? Like slowly loading parts far from the player, because this not only causes massive FPS drops, but also crash low-end devices more frequently.
If you wish to replicate the issue, you can teleport around, something similar to changing worlds/islands that are considerably detailed, this will make the whole region to load almost instantly, dropping your framerate and may crash low-end devices sometimes. (After searching around the forum, I noticed people reporting issues with client crashing this morning, since I applied this feature in my place at the same time, it caused me to think that the reason was the Opportunistic feature. Although the FPS dropping issue still a thing)
I would like to thanks all the team that is developing this new feature, Streaming has a lot of potential and can change how users experience up-coming games.
2 Likes
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.