Quick explanation: Parts that have the NetworkOwner of a client will freeze at the edge of the streamingenabled simulation on both the client and server, even when set to Persistant ModelStreamingMode, and therefore never fall into the void to be destroyed in my scenario.
In my mind, since they are set to Persistant and therefore shouldn’t be streamed in or out, the physics of the part should not freeze regardless of whether it’s in the StreamingRadius of the player or not.
Reproduction Steps
Create new place
Enable StreamingEnabled and set MinRadius and TargetRadius to small number like 64.
Create 2 parts.
Make each part a model with Ctrl + G.
Name one model “ClientPart”. We will set NetworkOwner of this part to your client.
Name the other “ServerPart”. We won’t change it’s NetworkOwner.
Set both models’ ModelStreamingMode to Persistant.
Anchor both parts and place over void.
Play game, head to server, and run following code in cmd line:
All parts, whether NetworkOwner is set to a player or the server, should fall into the void and not be affected by StreamingEnabled at all since the ModelStreamingMode is set to Persistant.
Actual Behavior
The model that has the client NetworkOwnership freezes at the boundary of StreamingEnabled radius on both client and server. Shown in video as yellow block.
In video I included 3 parts with different settings.
Grey: Mode = Default, Network = None
Green: Mode = Persistant, Network = None
Yellow: Mode = Persistant, Network = Client
Issue Area: Engine Issue Type: Other Impact: Moderate Frequency: Constantly
What is the use case where you are setting something to Persistent + Client Physics Ownership?
Right now there is logic in the engine that basically goes:
Outside of the Streaming Radius, we don’t know whether the client has enough information about the environment to simulate correctly, so we locally freeze it.
If you make a block outside of StreamingRadius Persistent and Client Owned, you run into the issue where the block will fall through the terrain because it doesn’t exist and be deleted.
If we understand the use case you are trying to solve we can think about a proper way to handle this case.
The issue I am facing is that any client networked part, regardless of StreamingMode, will freeze after the streaming radius (therefore not destroying itself if falling into void). I was expecting Persistent to change this behaviour.
For some context: I’m working on a project with a similar gameplay mechanic to Steep Steps, where you can place down a ladder and move it around to help you progress. StreamingEnabled is on.
I decided to make your client have NetworkOwnership of your ladder because the feedback when pushing it felt more responsive, which is when started running into the freezing issue. I set the ladder to have the Persistant mode expecting the ladder to ignore streaming completely and so I thought it would fix the freezing problem.
Having looked at your explanation it makes more sense, but I actually think that when there is both Client NetworkOwnership and Persistant StreamingMode, since the physics are being controlled by the client it wouldn’t be completely unrealistic for it to keep simulating physics with whatever environment is currently available on the client.
For now, I guess I’ll have to choose between keeping NetworkOwnership default or disabling StreamingEnabled. If there is another workaround that would be great, if not, thanks for your help!
So if I understand correctly, the problem you are trying to solve with the ladder is that you want it to stay Client Owned?
I don’t think we can ever make a part outside of Streaming Radius simulate because of the issue I mentioned, but I wonder if allowing Client-Owned parts that Stream Out to remember that they were Client Owned, but become Server-simulated and only restore Client Ownership once they Stream In is a behavior you would prefer in this case?
Basically, be Client Owned whenever possible, but revert to Server if not?
Yes, I think that behaviour would work well in this scenario as it’s not very important for a client owner ladder to be simulated by the client when further away.
Seems like something I could program by checking if parts are further than MinRadius and setting them to server ownership, and vice versa if they come back within the MinRadius. Though there isn’t any way to my knowledge to get a players actual current streaming radius, so I’d have to assume MinRadius (or smaller) at all times.