Sorry for the late response, came here from a hyperlink.
Anyways for a solution I handled objects that aren’t necessary to the server, like bullet trails (that don’t need collision) on the client. Reduced the Network problem.
Essentially what was wrong is I was using part cache only on the server. I had to make my own for the client but it didn’t take too long thanks to you making your scripts easy to read, thank you.
Whats happening…
local RandomPosModule = require(script.RandomPositionModule)
local PartCacheModule = require(script.Parent.PartCache)
local Droplet = game.ReplicatedStorage.RainDroplet
local ModuleRain = PartCacheModule.new(Droplet, 50)
while wait() do
for i = 1,(script.Parent.Amount.Value) do
local DropletClone = PartCacheModule.GetPart(ModuleRain)
DropletClone.Parent = workspace
RandomPosModule.RandomPosition(script.Parent,DropletClone)
end
end
You need to return the part to the cache at some point using ReturnPart.
Oh, let me give it a try.
Thank you.
local RandomPosModule = require(script.RandomPositionModule)
local PartCacheModule = require(script.Parent.PartCache)
local Droplet = game.ReplicatedStorage.RainDroplet
local ModuleRain = PartCacheModule.new(Droplet, 50)
while wait() do
for i = 1,(script.Parent.Amount.Value) do
local DropletClone = PartCacheModule.GetPart(ModuleRain)
DropletClone.Parent = workspace
RandomPosModule.RandomPosition(script.Parent,DropletClone)
ModuleRain:ReturnPart(DropletClone)
end
end
so now theres no errors, but its not spawning. Its just staying un-used
You’re instantly returning to the cache afterwards. You’ll probably want something like this.
local RandomPosModule = require(script.RandomPositionModule)
local PartCacheModule = require(script.Parent.PartCache)
local Droplet = game.ReplicatedStorage.RainDroplet
local ModuleRain = PartCacheModule.new(Droplet, 50)
while true do
local parts = {}
for i = 1,(script.Parent.Amount.Value) do
local DropletClone = PartCacheModule.GetPart(ModuleRain)
DropletClone.Parent = workspace
RandomPosModule.RandomPosition(script.Parent,DropletClone)
table.insert(parts, DropletClone)
end
wait()
for _, part in ipairs(parts) do
ModuleRain:ReturnPart(part)
end
end
It works, thanks! However, I want them to fall when they spawn there. When they touch something they go back to the cache. How can I do this?
Sounds like something that would depend on how your code is all setup, but I think use of the Touched event and Anchored property will help you with that.
When you put a trail on the part you can see it being sent down and returned. How would you fix this?
I had the same issue with the intended use with fastcast. My solution was to disable the trail when the bullets are put away and reenable them when they spawn back in.
Edit: Here is how it goes which uses the fastcasthandler approach. I had to coroutine a yield to guarantee the bullet gets moved into position then the trail activates but turns out it’s not that necessary just there if it happens.
local fastcastHandler = {
fastcast = castComponent,
velocity = bulletVelocity or 1000,
ratePerMinute = ratePerMinuteFire or rpm, --second per bullet
}
function fastcastHandler:Fire(origin, direction)
local activeCast = self.fastcast:Fire(origin, direction, self.velocity, fastCastBehavior)
local bullet = activeCast.RayInfo.CosmeticBulletObject
local trail = bullet:FindFirstChildWhichIsA("Trail")
if trail then
trail.Enabled = false
--coroutine.wrap(function()
--Prevents the trail glitch from occuring
--RunService.RenderStepped:Wait()
trail.Enabled = true
--end)()
end
local function cleanUpBullet(activeCast)
local bullet = activeCast.RayInfo.CosmeticBulletObject
--Debris:AddItem(bullet,1)--normal instance.new clone
local trail = bullet:FindFirstChildWhichIsA("Trail")
if trail then
trail.Enabled = false
end
projectileCache:ReturnPart(bullet)
end
castComponent.CastTerminating:Connect(cleanUpBullet)
It can be more optimized using bullet.Trail instead of FindFirstChild but I’m lazy 
so thats to avoid the fact that not all my bullets have a .Trail so just be aware of that.
Do I need to remove any connections and remove any parented instance in the part before using returnpart() or does the module revert the part automatically?
The module does not dispose of any connections to the part’s events. You will need to track these yourself. Its not possible for the module to do so, unfortunately.
How would I be able to get old part caches made previously in the games runtime (possibly from its parent folder, etc.) I’ve been having difficulties trying to do so with the usage of fast cast with it. To specify, I don’t know if PartCacheModule.new() will always make a new one, and even if it does or doesn’t, if there’s any way to grab it and store it into a variable from a complete seperate script.
I really can’t tell if this module is actually increasing FPS.
I ran 3 questionable tests and got mixed results
I fired 1,681 projectiles at once that disappeared in 8 seconds with PartCache and without it. PartCache dropped to ~47 FPS and normally it dropped to ~44 FPS. However, cleaning up the projectiles dropped PartCache to ~57 FPS whereas normally it’s ~59 FPS.
I fired 6,561 projectiles this time and I honestly couldn’t see a difference in FPS when spawning the projectiles in for both methods. However, PartCache had a very noticeable stutter when cleaning up the projectiles.
I fired 121 projectiles every 0.1 seconds. PartCache was at ~59.5 FPS whereas normally it was basically 60 FPS.
I’m not sure if I’m using it wrong or something, but I’m pretty sure that PartCache suffers a lot when cleaning the parts. It does seemingly improve spawn FPS but not enough to entirely rely on it.
Maybe some other people can do proper tests instead of my “look hard at the FPS in view >> summary.”
I feel so lucky to have found this topic. Currently, I am working on infinite two dimensional terrain generation. One optimization that I want to add is part caching. This is something that I planned on making myself. Luckily, I found this system which is exactly what I am looking for.
PartCache seems to be mainly made for faster creation / destruction of parts (as the part CFrame is the only property that replicates unreliably, which makes it faster), it doesn’t seem to be made to increase the fps when creating / destroying parts.
I was just trying to say that “returning” the parts takes up more performance than calling :Destroy() on the BasePart. However, it’s undeniable that caching the part vastly improves performance over calling Instance.new() hence PartCache.
For me, however, I found that CFraming the parts far away actually took more performance than making the object parent nil. Plus, I didn’t like how PartCache only cached BaseParts and wanted more freedom with what :ReturnPart() did, so I made my own InstanceCache.
By the way, a micro-optimization would be using :PivotTo(CFrame) than basePart.CFrame = CFrame now that pivots are here
It might be more performant to disable CanQuery, CanCollide, CanTouch and CastShadow for cached parts. I have not tested this, but maybe this works.
is this better than debris service?
Short and simple: Yes.
CFrame works best.