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 @xKiiyoko 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?
There is a workaround for that, but it’s kind of hacky. Does that sword power shot need gravity for the distance or does it travel in a straight line from point of firing? Are you using physics to move it or Lerp cframes?
Can you give some more information on your usage scenario and what you would expect to see? For example, if we were to allow your projectile to continue simulating it would pass straight through content that is missing on the client. If there was only low res LOD for terrain and/or models then the projectile would not collide with them. Is that desirable?
I have just switch to updating CFrame every heartbeat and it seemingly works. I now use GetPartsInPart and BlockCast for collisions and they are also hitting low res terrain. You can see it here
Yes, it would have been desirable, at least considering most effects on the client are there for visual purposes anyway and randomly freezing in the air like this video ruins it
One solution would be to make a invisible anchored part persistent, but that wouldn’t work because the projectile would still freeze before colliding due to the setback
(also everything that the projectile is supposed to collide with in my game is persistent so it really doesn’t matter if it collides with the ground or not)
The ability to simulate persistent locally network owned parts outside the streaming radius is the only reason I am unable to use streaming enabled. I’ve been working on my Tycoon for many years, and over time, the average crash rate has slowly risen to 5 - 10%. I have everything I need set up to enable streaming, however:
Due to the size of my game, it is not always plausible to put the server in charge of hundreds of simulated ores. As a developer, it is my responsibility to ensure these ores have parts they are able to physically interact with, which I have, yet I am unable to force these ores to simulate. I severely desire the ability to force simulation, as otherwise there is no solution to this problem.
Currently, until this is resolved, it is impossible for me to use streaming enabled.
