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
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.
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.
Fastcast fire function which enables the trail if it finds one
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
Clean up function disabling the trail using cast terminating like a good boy
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
Sorry for the bump, but oh wow. This module is simple yet soooo effective. It made my part rain script run waaaay much efficiently. I can now have over 300 moving rain parts on screen with maximum performance!
I’m trying to make it 0 parts big so it will auto fill up as needed. I don’t want to start with a value which seems sort of arbitrary. Is it better to start with a super small value and let it fill up automatically or have some random large number so you never have to worry about auto fill but possibly have excess parts. I would really prefer the former.
Im using CFrames to actually and FINALLY make Occlusion Culling a real thing. Initially i thought reparenting is the best option but i guess im wrong.
Now this is how it works, I’ll be using Camera: WorldToScreenPoint() to check if the player can see the parts/models or not. If they can they will stay at their original position, if not they will be CFramed away.
Thank you @Xan_TheDragon for letting me realize this as a solution.\
The problem is bringing the models/parts back, thought of replacing those with invisible parts.
so thats to avoid the fact that not all my bullets have a .Trail so just be aware of that.
