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?
1 Like
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
Off-topic, but the GUI artwork is very nice in your videos. Did you make it yourself or do you have a graphic artist doing your GUI buttons? 
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.
1 Like
I am curious why not? If you had said ten-thousands I could understand, but hundreds? The server can easily handle this. 
1 Like
Apologies, I should’ve been more specific. Around 400 - 500 parts is where the server is no longer able to keep up with physics simulation.
50 parts handled on the server:
500 parts handled on the server:
1,000 parts handled on the server:
These all utilize adaptive physics stepping. Under no circumstance would I be able to reach 10k+ parts. There are already many optimizations to reduce the amount of parts created, the 1k being more of a stress-test. Additionally, this lag is solely caused by physics as otherwise the server runs at a solid 60 heartbeat.
Here is 1,000 ball physics objects running at 60 fps (on the server view, not enough client bandwidth to make it smooth on the client, known Roblox limitation of course) granted the video recorder was eating some of the CPU and was not as smooth with video capture than without it. I watched your videos and you demonstrate the issue you are seeing well, but I have to ask why you have objects colliding inside of each other? That would certainly cause some physics issues running those objects like that. 
Just to clarify, you are running your test on actual Roblox servers, not emulating this on your home PC? The Amazon servers that Roblox use are much more optimized for the physics and run faster than most typical home PCs from what I’ve seen. 
1 Like
To avoid making a reply mess from my previous reply… 
If those parts are only doing two things, falling down onto the conveyor and then moving along a straight line; you don’t even need physics for that. You can simulate all of that with just frame lerp. Give the parts a touch event so if you need them to “act” like they got moved by something, use the touch event to turn on the physics for that object then such as the player walking into them for example or other parts hitting each other.
1 Like
I am running these tests on a live server, not in studio. In studio, I am able to simulate 1000 parts without any issues. I intentionally apply a collision group to the ores so they don’t collide with each other, however, this is not the cause of the physics lag.
500 parts without collision groups:
I believe but can’t confirm Roblox gives priority servers to front page games, which could play a role as to why the physics are performing below your expectations. Other games such as Miner’s Haven, which was a front-page game, also applies network ownership to their ores.
The parts do quite a bit more than what I show in the video, however I will be experimenting with alternative ways to reduce the simulated part count further as a temporary solution until the streaming simulation issue is resolved.
Regardless, in my years on the platform I have never expected Roblox to simulate this many server-sided physics objects. I would much rather have the ability to force simulation of locally owned objects while using streaming as this gives other developers and I more control to push the boundaries of Roblox.
1 Like
I’ve read that here as well about front page games getting priority, but I don’t know if it’s ever been confirmed as I would be really curious myself.
Hmm, oddly enough, I am simulating (let me write a script to count all of them).
13,359 physics objects running concurrently… - Server
That many in my experience when it first starts and that’s before the players join and start adding to the total with their own stuff they throw around. I don’t think my servers are getting any special treatment, all objects are server owned, I never let the players do any physics other than their own character or else the client gets overloaded with physics in my game and kills the client frame rate. 
Are you explicitly setting these parts be simulated on the server with Part:SetNetworkOwner(nil)? If so, what happens when they’re left with automatic network ownership? I would expect the server to attempt to distribute the workload to clients so everything keeps simulating at a realtime rate.
I am setting parts to simulate on the server. I’ve had issues in the past where slow devices and networks would capture ownership and slow physics movement immensely, as well as both options overall performing similarly due to droppers being spaced far apart.
My current solution is adjust the number of simulated parts based on the server’s performance. This change alone has dropped my live server’s compute efficiency to <60% avg from ~95% avg and server heartbeat to ~57 from a solid 60 where four times the parts were handled on the client. It is not ideal, but functions in the meantime.
Edit: I should note these changes were implemented alongside streaming which may also impact these numbers
2 Likes
Just rework the system dude. Stop simulating these on the server/client.
When a dropper is supposed to drop something, if the client is close enough, process it. If not, make it delay add to the value, do no physics operations.
Not an option for a sandbox tycoons which could have radically different outcomes depending on placement of items. It is not feasible to run a mini-ideal physics simulation as well since there would be massive visual discrepancies alongside explosions and other (random) things that affects physics.
3 Likes
You could consider running the first drop on the server (or entering a specific time). Then reward your user on that interval. Then future drops could just be simulated on the client and be irrelevant to any income calculations
1 Like
Random chance is a large part of sandbox tycoons, and physics aren’t deterministic.