Would be much appreciated if we could get more info about these planned features you mention sooner rather than later, so that we can plan and provide feedback. I take advantage of the current behavior for my game, and hearing that it will be removed without knowing what the new features actually are is a little bit worrying (though I do expect the new tools will probably be sufficient for what I need.)
To give more info, my use case of the current system is the following: Most of my game has a fog system and you can’t see very far around your character, so I don’t need or want a large TargetRadius - however I do have a few areas where there is no fog and I want the player to be able to see into the distance quite far. Currently I use RequestStreamAroundAsync and Player.ReplicationFocus to force load in the areas that are far from the player / outside of the TargetRadius, then I place the player in their intended location (which is farther than the StreamingTargetRadius from the preloaded spots) and the result is that the player gets to see the whole area at once (assuming they have the memory for it.)
A feature to dynamically change the StreamingTargetRadius on a per-player basis, or a way to tell the system “keep these areas loaded in even if the player isn’t within radius” (memory allowing) would probably be the simplest ways to solve my particular use case.
One other thing to note is that I do find it convenient in general that areas don’t unload if you have the memory to keep them. Specifically, my game is very part-dense and when a player teleports into a new area there is a small timeframe of noticeable lag while the new area loads. If the player was just at that place and returns to it, however, there is no lag as it is still loaded. Assuming that my player has the memory, I’m not sure why I would ever want it unloaded (though maybe areas that have been loaded previously load quicker than those that are loading for the first time, anyways? I’m not too sure on that as I’ve never tested / compared.)
Hopefully these things can be taken into account. I’m glad to see Streaming get more features!
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.
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.
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?
