Very cool! I will have to test this feature out.
This is a fantastic update, something I’ve been waiting on for a very long time! However, I do feel the LowMemory behaviour should be kept since removing that may break a lot of experiences, and some devs may not want to put strain on load times (also, choice is a good thing).
But your particular use-case is undefined, right? Memory pressure can kick in and stream things out at any moment.
In general, expecting streaming NOT to stream out for any reason before this update was an incorrect assumption because you always had players joining with devices that would force stream out. All this change does is make this behavior more consistent so that you can actually develop and test a consistent behavior accordingly.
I am also experiencing this issue, where the default R15 characters don’t load back in properly (limbs could be in the wrong position, missing, etc). I’d love to use this feature to optimise the games I work on, however, I cannot as it breaks characters.
Technically yes - and don’t get me wrong having an official way to get what I am trying to achieve would be much preferable, and I would have no need for the old behavior if that was the case.
With that said though, my game targets high-end devices and, from my testing on multiple PCs, that memory pressure never really comes into play and I’ve never had it be an issue. I do understand that a lower end user may stream out the distant scenery, but for my game lower end players already have an expectation that they are not accommodated to and something like not being able to see distant scenery is not a huge deal (even though I would say seeing the scenery is important for high-end players.)
Really all I am asking is that the new tools mentioned in the OP are able to account for a situation like mine of “I want areas that are beyond the regular StreamingTargetRadius to stay loaded when I tell them to be.” Because yes, while my solution is hacky and technically fallible it is still preferable to always having the TargetRadius at a very high number or never being able to see that far in the distance.
We’ve been able to reproduce the issues with R15 avatars that have been reported and we are going to have to temporarily disable this feature while we address the issue. We will follow up on this post when we are able to reenable the feature.
Thanks for the early issue reports and for the other feedback.
What are the requirements that need to be met in order to stream objects out using Opportunistic mode? I set the option live in Ultimate Driving over the weekend and am quite disappointed in how unwilling the client still is to unstream faraway objects.
Case in point, I was able to get a feel for just how little was still being streamed out by going into freecam. I drove around the map, then wandered to a location a few thousand studs away to see if the map would unload itself.
If the stream-out requirements aren’t going to be made more aggressive, I’d honestly prefer some kind of property for a hard stream-out limit.
EDIT: When was this feature disabled? I’m pretty confident my findings were on a server still using this feature and are still valid.
Feature was disabled at 12:53 pm PDT on 8/30.
The requirements for what will allow something to be streamed out are a bit complicated, but things far away may still not be streamed out if the engine thinks they are needed due to an association with instances that are closer the streaming focus.
If that’s the case, I really don’t feel this new setting is much of an improvement over the original LowMemory setting in its current state. It feels unpredictable and timid in deciding when it’ll actually decide to stream objects out, which is resulting in the same degraded performance that the LowMemory setting struggles with.
I’d love to know what these association requirements that the engine is looking for so that I can use them to my advantage with performance, or preferably get the ability to finetune the stream-out radius and deal with its ramifications in my experience myself.
While I do love this update, I’ve noticed that it is negatively impacting players with high ping. The constant cycle of streaming out and streaming in tends to cause players to fall through our map if their ping is in the thousands.
I’ve come to the decision that this setting provides way more pros than cons in our use case due to the fact it greatly enhances optimization for an open-world driving game, however I do feel bad for players in regions with poor internet service. Our map has become a death trap for users in Australia for example who consistently experience anywhere from 500ms to upwards of 5000ms depending on the network congestion of their particular area. The only solution that immediately comes to mind is forcing streaming with Player:RequestStreamAroundAsync() if a player’s ping is over a certain threshold.
It would be great if network latency was factored into the logic of the Opportunistic setting, and/or more versatility by allowing developers to modify streaming properties during runtime.
Current configuration is such that things outside a radius 1.5 * target radius will stream out. This multiplier will not be static, we want to optimize this system and move it closer to 1.0.
The only reason far away objects objects wouldn’t stream out is if their Mechanism intersects inside the Streaming Target Radius. If you make a big anchored assembly, we may always stream all of the parts from the instances within the streaming radius to the root part of the assembly.
@TwentyTwoPilots I force enabled the stream out and went to a similar distance to your test and I did observe content being streamed out, leaving mostly only terrain and model LOD. Not sure what might have been different with your test. If you continue seeing very little stream out after we reenable this feature we can investigate.
Any ETA on readdition
Our game desperately needed this and its removal has brought back much-unneeded lag
There are a couple related fixes under development. I suspect it will be a few weeks before this feature can be reactivated unfortunately.
I really hope this feature come back soon. It would enable me to create a massive open world rpg with smooth performance.
This update will be vary useful for my railway!
My massive new game is patiently waiting for this to be enabled, its a huge map, with lots of parts and terrain, stream out will be required, but I agree with @TwentyTwoPilots that it needs to be an aggressive hard stream-out limit for performance to be majorly impacted.
Heya, I’ve scoured through the thread and have been unable to find any answers, so I’ll post my question here instead: what would happen if the client keeps a reference to an asset that then unloads? Is the reference kept & able to be read from? If so, is it the exact same object that’s loaded back again? I.e., would Reference == LoadedAsset
be true
?
It would honestly be really nice if we had the option to choose the streaming radius for specific items in the game.
My game has a house building feature where anyone can build quite literally anything they want on their plot. Most of the time, players end up having big houses that are made up of thousands of parts in a small area, which in turn makes the memory usage very high if a player were to just get close to one of these buildings, usually resulting in the client crashing if they are on a very low memory device.
As a developer, I have done everything I can to minimize this (Lowering collision fidelity for meshes, using downscaled textures etc.)
Here is an example of a user-built house:
As you can see, there is a lot going on here. It would be Ideal to have some sort of system that lets us choose the streaming radius of certain models, especially on lower memory devices such as mobile, so that only a part of the interior of houses is loaded at a time. Another option would be to give developers an API that lets us request to stream in/out any parts or models for specific clients.
In answer to your direct question, Pyseph:
A reference that is held by the client which then streams out can still be read from, but will not receive any updates from the server while in a streamed out state.
It is the same object when streamed back in, and will be updated to reflect the current server state upon stream in. Reference == LoadedAsset
is true
.