When the function returns it is completed, as best as it can. If it is done sooner than the timeout it will return earlier. We can’t guarantee it will be loaded since the client may not have sufficient memory available for both the current focus and the requested area.
The risk with using the replication focus is that if you set it far away from the player and they aren’t moved there then they will not get streamed regions around their current location and they may walk off the map or hit streaming pause.
So if I’m understanding this right, this’d be especially useful if you had a spectate feature that allows players to spectate other players that are far away?
in that case, would the area around my player simply stop streaming to my client, though it does not unload?
How big does the map need to be for this to have any real improvements to performance?
Kinda a vague question.
Cool features though!
If I’m correct, streaming helps memory at the cost of sporadic, eventful replication.
While exploring this for optimizing my case I came to the conclusion it is not for me, and possibly a bad idea. With users not suffering from geometry taking up too much memory but rather not rendering it I noticed that network replication had an indirect relationship with getting the full thing rendered:
With 36KB/S receive:
With <10 KB/S receive:
The players devices handle it, if they’re in the center of the boat the thing fully renders with no reported problems. Trimming off the stern is therefore somewhat redundant of whatever is approximating the costs.
Investing a week researching and experimenting with no results is a nightmare. So I’d like to ask if memory affects render, and by extension this new streaming API. If my idea of this, illustrated above, has any sense to it. I’m asking if RequestStreamAroundAsync center to the boat might help it render at greater distances, like at the bow and stern, or a submarine a thousand studs away intended to see it.
Will we ever see an addition to the streaming system that allows for only certain objects/actors to be streamed in and out? The use case I see for this is that in large, open worlds, there may be very large objects or terrain that are far away from the player and should ideally always be loaded and never streamed out. However, small objects such as flowers, rocks, etc would be just fine to stream out at large distances.
(I’m not super familiar with the streaming system so I’m unsure if the streaming system already takes this into account.)
@Quenty the request API can be called from either the client or the server. The timeout specifies the limit on how long it will try and satisfy the request. If you call it multiple times there is a limit on how many simultaneous requests are active and you may end up cancelling your older requests before the timeout.
@Dev0mar the request API causes streaming to occur around both the replication focus and the new position, but it will cause less regions to be sent to the primary focus than before the request.
@dispeller if you expect to CFrame the player farther away than the target radius from their current position, and you have some advance notice that they might move, then it will be useful.
I just read some stuff. So this is mainly for Wider Device Support and faster loading times?
Very cool
On a game I’m working on, I planned to split the world into a bunch of different places and have the player teleport between these places. That way I could have a larger map with minimal lag.
I might consider switching to using this instead. Or maybe a combo of the two.
The roadmap doesn’t appear to be updated frequently. I think it’s used more as a way to communicate long-term engineering goals to the developers rather than the state of individual components.
Atmospheric Fog, Expressive Output, Enhanced Audio Search, and Plugin Debugger still all say On Track instead of Beta or Live.
I am aware of that, however it’s nice when it’s updated so you can see collectively what’s been added, and what has not (short of manually searching each of the features to see if they’ve been implemented or not).
I was so confused by all of the bug reports I’ve been getting! My game is almost entirely local. I’m probably just going to finish implementing my own terrain system and disable StreamingEnabled to avoid headaches like this in the future. The cause of every major bug in my game has been due to StreamingEnabled (except for the one where toWorldSpace batches caused bad allocation errors.)
If the client’s memory stress was exposed somehow I could unload the models myself.
While convenient, I think there is something fundamentally wrong with the client being able to call this; An exploiter could peek across the map in a huge MMO and see what people are doing, or steal the map itself/stress the server by requesting everything. It would need to replicated to the server anyways, and would just be more secure for the developer to be the one to control how the server responds.
An exploiter will always be able to do this, so it actually doesn’t really have that much of a security issue. Right now exploiters can already change their root part position or use Replication Focus to do this. I believe having access to using the prestream api on the client is not only convenient but requiring in games that rely on the client for a lot of different aspects of their game.
This reminds me that I need to support streaming for my up coming game.
Thanks for making it easier and more controllable.
Amazing to see streaming finally getting some love
@MrGreystone can you create a separate bug report on the streaming/rendering issue you are seeing? Rendering adjusts to CPU and memory load. We’d like to better understand what is going on in your situation.
They would need to explore the entire map to get the data, so it wouldn’t be nearly as easy. With server-side sanity checks to prevent teleportation, it would be very difficult to steal a huge map.
This sounds like a problem in itself, not a reason to give the client even more control. Servers really need to be capable of doing sanity checks for character positions to prevent teleport hacks; This is a big reason I made my game entirely local.
I don’t see why you can’t just set up a RemoteEvent that makes the server call instead; it would need to send the server that request anyways.
There’s also some level of privacy players will expect when playing future games that have massive maps. Exploiters being able to watch what people are doing on the other side of the map or in their private house area is just creepy. Most Roblox games have relatively small maps today, but we need to be mindful of the engine’s future.
@Tomarty hopefully the change to how local parts are handled fixes the main issue you were likely seeing with streaming enabled. If you think there are additional streaming bugs still causing you problems please file a bug report to let us know.
Thanks for raising the concern about allowing prefetch to be called from the client. There are limits in place to prevent the requests from causing more load on the server. We will discuss the potential security concerns that you raised about letting clients stream regions they shouldn’t get.
Can we at least have the option to change these with a Script?
Think of Minecraft Render settings, different people have different devices and preferences.
Exploring game mechanics, player can expand their Render distance for example.
This is like Lightning.Technology all over again, why can’t we change this stuff in game?
What’s the point of using this then?
I understand that from time to time things will fail but that’s not the issue here, could we at least have something to let us know that this failed so we can do something about it?
What kind of terrible UX would this present?
Imagine being teleported then falling to your death in a Rouge like game because your Internet is bad…
This even happens in Minecraft while Chunk loading, it’s very frustrating.