As a developer, it is currently impossible to use physics to its highest potential with StreamingEnabled.
About
Any client-owned physics part is not simulated outside of the streaming radius. This means that even a player’s character is completely stopped when stepping outside (shown within the last few seconds of the video below.)
This also happens when a part is within a Persistent model, meaning that there are no workarounds for this issue.
I’ve attached a studio file below. Observe the player as they walk up the ramp and as the parts fall out of the streaming radius. streaming_physics_issue_repro.rbxl (47.9 KB)
Why?
This behaviour, at least to me seems extremely unexpected. This forces tycoon games to either run custom physics (very anti-pattern) or not use StreamingEnabled at all. I also feel like this ruins a point of persistent models–for them to stay persistent.
This issue originally arose because one of my tycoon games I’m working on is heavily physics reliant–this is our only problem with StreamingEnabled.
Solution?
I am aware I shouldn’t suggest solutions because I am unaware of the backend, but I would greatly enjoy if persistent models are always physically simulated.
We know. But this is unbearably straining for the server, especially on games like Miner’s Haven. We forcibly set the network owner to the client in order to take load off from the server.
EDIT: Although I get that this is “bad practice” as we shouldn’t trust the client for these types of things (I am aware of the vulnerability issues it opens) I would rather have a exploiter-ridden game than one that performs badly (the thing StreamingEnabled attempts to circumvent).
With adaptive time stepping, I haven’t noticed serious problems with physics anymore. Additionally, you can use simple physics meshes, box collisions are the most effective at reducing performance issues.
This isn’t an option for our game. The client is also used heavily in order to make responsive gameplay to forego delay, I cannot use server sided physics as a viable option.
I recall there being a bug report similar to this, about client-owned parts freezing when they went too far from the player, I remember an engineer saying that it was intentional for physics to freeze like this because the physics engine can’t know what the geometry is like outside of the streaming radius, so it freezes it to be safe.
I just found it while typing this up:
They suggest later in the thread a system where parts revert back to a server-owned state if they go outside of the player’s simulation radius, but it is yet to be implemented in the engine far as I can tell. Maybe you could do it manually itself, where a script goes through physics parts owned by the client every once in a while, and if it’s outside of workspace.StreamingMinRadius, set it’s ownership to the server, if it’s inside of the min radius, set it to the client.
Of course, it isn’t as optimized as it could be. As far as I know, the engine doesn’t expose a way to view how much of the world is currently streamed in, so the StreamingMinRadius could be wildly inaccurate if you left the values at the default settings, but hopefully it should eliminate the freezing problem.
Yeah–this is why I made this as a feature request instead of a bug report. (I originally made it as a bug report but I quickly backtracked after reading the documentation)
I really wish I could revert to server-owned parts but it’s insanely difficult with the way I have everything set up already… plus the issue isn’t an issue of keeping the parts simulated at all, it’s an issue of keeping them simulated whilst still being owned by the client.
Like the thread owner in there, I assume that Persistent models should ignore streaming completely, and that the person who’s making the game should be able to gauge if this is good enough for their game.
I am perfectly fine with this! I would prefer this behaviour, since if I knew about this behaviour beforehand I would set up for it. Freezing outside of the streaming radius despite them being Persistent feels less intuitive. Maybe there could be a Workspace property for this in order to make it more obvious? I’m not sure.
This problem also extends to parts created by the client–I would expect those to be 100% unaffected by streaming because the server has no knowledge of them, but this isn’t the case.
Nope, you got it.
They ignore streaming as in they always stay there on the Client. However, their physics freeze up as soon as they leave the player’s streaming radius if owned by the client. That’s the thing I want to be solved–not anything else. (That’s also why I find this so odd because whenever I hear “Persistent” I also think of the physics themselves being Persistent as well.)
not simulating physics outside of the streaming radius makes sense to me. the majority of the world (assuming you’re using streaming properly) should be entirely unloaded outside of the radius. the majority of unanchored parts would just end up falling into the void, right?
changing the behavior of unanchored persistent parts to let them continue interacting with the nearly if not entirely empty world outside of the streaming radius would likely break existing games and has a really tiny use case for where it could be useful (tycoon games)
My motto for this is: “If you have persistent parts, you should be able to handle them.”
As much as I agree with you that it would break some existing things, there should at the very least be a workspace property or something just so that we could control this behaviour, because to me, persistent parts falling into the void seems kind of like the developer’s problem by having a lack of foresight—but again, that might just be me.
There have been others as well who need this feature and many others have even saw it as a bug.
e.g. Client owned physics-based train systems
Having made my own request about another issue this causes which @KiiyokoDev has kindly replied to and explained on, I also back this feature.
I am running a train game with streaming enabled, the player driving the train needs to be the network owner of the train in question. They run on LinearVelocity and if a coach goes out of the streaming radius, even if each coach in the train is persistant (or in my case, Atomic, as we allow each coach in a train to stream out to save strain on players that are far away from it) the LinearVelocity doesn’t do anything, and its ‘Active’ property is set to false. We need the LinearVelocity to always be active if the model is streamed in.
Thanks for raising these issues. We are discussing internally various options for handling these kind of scenarios, including the possibility of allowing simulation even when outside streamed areas.
Please allow for at least parts that only exist on a single client to continue physics. I am already managing replication distance for the bullets on a per-player basis
Hi; I’m truly sorry for bumping this but I’m curious if there has been anything upcoming we should be looking out for?
If not I might just bite the bullet and turn off StreamingEnabled for a better user experience for my players.
Thanks!
Improving the physics on objects outside the active streaming area is high on our priority list. Unfortunately, solutions for it are not straightforward and are not things we can rush in. Always allowing simulation of persistent models could cause problems for experiences since continuing simulation might result in objects falling through the world due to parts necessary for accurate simulation being missing. The best recommendation we can make currently is to not manually set network ownership to the client for parts that are likely to leave the streamed area.
Please allow for at least parts that only exist on a single client to continue physics. I am already managing replication distance for the bullets on a per-player basis
My projectile is stuck there (until I move a bit closer) even though there is no server version of the part and creation is fully managed
I see this discussion come up a lot here and while I agree with the need of the request, I do run into exactly what the devs are talking about and physics failing for parts outside of the streaming radius. Currently the game engine gives you about a target streaming radius +30% distance to work with for client physics. For example, a target streaming distance of 64 gives you physics to about 82 studs radius that physics will work. This seems to be an issue on the PC because they usually have so much RAM that the entire map being visible in streaming enabled is no big deal. On Mobile clients, it’s a different story and having object physics working outside of the target streaming radius absolutely falls apart because Mobile is much more limited for RAM and often the area that the part was going to be simulated just falls through the world. The issue really doesn’t have a one-for-all solution because how is a client going to simulate anything with a piece of the world missing. I have to agree with what others have posted here, the request is more wishful thinking because there is no way to implement this on clients that have less RAM than other clients, basically an impossible feature request I’m afraid.
I couldn’t watch your previous video, but I am curious what your issue is. Is the screenshot a part that is suppose to be moving but just stuck at the streaming radius limit?
