-
Description - My game uses unanchored assemblies of parts with a primary part and other meshes/parts welded to it as vehicles. Clients have network ownership over their vehicles. I recently added streaming enabled to the game and got lots of reports from players where they see frozen vehicles in unusual places, these vehicles don’t have physics, neither do they react to shooting them or other game related features. Sometimes the vehicle is also deformed and split into two parts: hull and turret.
I, myself, have encountered this behavior only once in studio, and I am 100% positive this is an issue with Streaming Enabled feature. -
Reproduction - I can not consistently reproduce the issue but this is what happened in studio: I had 2 player test running, player 1 and player 2, both with spawned vehicles and both vehicles were in streaming radius of one another. However, when I would move Vehicle1, its physics would replicate to server only, but not to the player 2. Vehicle1 was stuck on player2’s screen, just like the reports I get from real players in live game place. In another studio reproduction example, the turret of vehicle1 was stuck on player2’s screen, but the hull was still moving.
Note: when player1 was streamed out of player2’s streaming radius, and then streamed back in again, the vehicle would fix itself. This behavior was implemented thanks to another report of similar issue: https://devforum.roblox.com/t/vehicles-not-getting-streamed-inout-correctly/447201/12?u=ratismyusername. However, the problem is that I use relatively large streaming radius, so re-streaming of the vehicles does not happen very often. Streaming settings are:
-
Where the bug happens - Game link
-
Related images and videos -
Streamable video
From what I can tell Streaming Enabled has been deprecated and doesn’t work correctly, you may need to re-do how the vehicles move.
If your game was ok before streaming enabled, why don’t you just deactivate it lol, after all it’s a deprecated property
Streaming enabled is definitely not deprecated.
@RatIsMyUsername are you able to create a simple test place with one vehicle and a small target radius? Does having the vehicle stream out and back in cause issues reliably?
Are you using A-Chassis by any chance?
- I am not using A-Chassis, its a completely custom vehicle system with welded parts and ray casts for wheels.
- As for the sample test place, before pushing the update I have tested exactly what you are suggesting a countless times: small streaming radius, opportunistic streaming mode. Vehicle physics replication, or turret/hull separation issue was very hard and random to reproduce. However, I will still make a simple test place, although I will have to share it privately to you as a staff member, the place will contain a lot of the game code, I don’t want it to be public. I will share the place as soon as it is ready
- The error below pops up on server occasionally, might be connected to all of this:
I also discussed that particular error with you on another devforum thread:
https://devforum.roblox.com/t/streaming-error-no-workspace-or-streaming-enabled-not-active/1494417/9?u=ratismyusername
It’s not deprecated, in fact they are adding more features to it over time. Also I don’t want to deactivate Streaming Enabled for my game as it has saved tons of game loading time and reduced general lag
My bad sorry, my brain confused FilteringEnabled with StreamingEnabled haha
Unfortunately I was not able to create a testing place, the game does have modularity but not to a degree where I can separate only physics-related aspects of the game to testing place.
The issue is still actively occurring though, I also have new type of stream-out failing bug:
I use workspace.Terrain:Clear() and workspace.Terrain:PasteRegion(someTerrainRegion, workspace.Terrain.MaxExtents.Min, true) commands to load/unload different map terrains every time new round starts, after I turned on streaming enabled, chunks of terrain of previous maps fail to unload for some users:
I would have to share the whole game file in order to have a recreation file, is there any other way I can help with the bug diagnosis?
In any case I will provide more information that could help:
-
My game scale is a bit larger than normal Roblox scale, 1 meter = 6 studs in the game
-
This is what a typical tank model looks like on client, with “Engine” being primary part, everything else welded to it previously by server, network ownership given to client:
-
I do vfx and custom detail settings on client exclusively, so for example when an enemy tank shoots, my client machine will create all the projectile vfx, parent projectile under enemy tank model in my local version of the world, apply animations and delete it.
-
Same with details: if client has details settings turned on,
RunService.RenderStepped-ran code will check for every enemy tank that is streamed in, and apply corresponding details to them: it will set primary part CFrame of anchored “Details” model to enemy tank’s relative cframe. “Details” model also being parented under enemy tank model locally
I do think the last two bulletpoints might have the most to do with the streaming bug? I am not sure.
When did this terrain issue start occurring? Is this a new behavior?
This behavior started the first thing after I enabled streaming for the game, so it is not new. I did forget to include it in the original post, probably because it is not as important as the tanks not streaming out bug.
More details about the terrain (everything below was already implemented before this post was created):
The terrain swapping happens fully on server when game round changes with above mentioned workspace.Terrain:...commands. I figured, after server supposedly clears the terrain, but due to streaming bug, some clients have chunks of old terrain, it would be a good idea to call workspace.Terrain:Clear() once more locally for all the players, and it did help the issue tremendously. In fact I could not replicate the bug myself anymore, but I am still getting reports of it time after time. It is most likely due to the fact that when players join, there can be lag spikes because of loading, that can mess up sync between my scripts calling workspace.Terrain:Clear() on server and then clients, and god knows what happens inside the engine on the lower level, since clearing the terrain for huge maps is not a task that happens in a blink of an eye. Here more proof:
Summary:
I can safely report an engine bug that calling workspace.Terrain:Clear() and workspace.Terrain:PasteRegion(someMapTerrainRegion, workspace.Terrain.MaxExtents.Min, true) on server, while having the streaming enabled settings I have (present in original post), does not guarantee that the old terrain will fully be removed from every client.
Again, this is not my main concern however, just thought it could give some leads.