Changes to PartInstance Streaming with Streaming Enabled

Updates Announcements
#65

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.

2 Likes
#66

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. :slight_smile:

1 Like
#67

Rather than using a timed wait the recommended way to wait for a particular instance to be streamed is via Instance:WaitForChild

#68

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!

#69

Sorry for my misunderstanding. Are you able to create a simple repro place that demonstrates the problem and file a bug report?

#70

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. :slight_smile: European office hours tomorrow, so I will post here after work.

1 Like
#71

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
#72

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
#73

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.