I can see that it isn’t a red underline, meaning it isn’t an error and just roblox being roblox.
1 Like
Is it possible to use this even if the bullets are all client sided? So I would have to use it on the localscript, and is it also possible if I could use it to also delete impact parts?
How does this deal with cases where a part from part cache gets destroyed, or properties of a part in the cache change? When getting that part again, it won’t be the same as the template part anymore.
1 Like
It doesn’t. If it happens to pick the altered part, then all alterations will still be there. If you destroy the part, it will not be removed (and by extension, if it is in the available list, GetPart may return the destroyed reference.)
Hello!
This is the first time im trying to use modulescripts and im having a hard time understanding how it works.
I wrote this line of code that i think should spawn a part.
local danmaku = PC:new(BType.bullet3,1,workspace.Projectiles)
But it gives an error saying that the modulescript is trying to compare a number to nil.
I’ve looked inside the modulescript and the error is caused by this line.
assert(numPrecreatedParts > 0, "PrecreatedParts can not be negative!")
I’ve tried deleting it, but it just makes a chain reaction where more and more errors appear.
Can anyone tell me what im doing wrong here?
edit:I got everthing working except for 1 part… is there any way to replicate a debris using returnpart?
That sounds like a significant problem to me.
1 Like
Heya, I have a question about the module.
Say if there are multiple players in the game and they’re all shooting at the same time, while all bullets are client-sided, do I need to create a new cache with a bunch of parts for each player or could there be another way? Thanks for reading 
Also I noticed that the FPS still drops even though the bullets are cached…
1 Like
Hi, I’ve been using your Module in combination with FastCast for some time now, and I’ve noticed a small problem. Sometimes, the created cosmetic parts are not deleted properly, and they keep floating in the world. This is probably due to server lag or whatever, and that’s fine. How do I remove these though? Clearing the cosmetic parts map doesn’t work properly -as it causes current used guns to not show any cosmetic bullets anymore- and I can’t use :Dispose, as the provider that was used to create them is long deleted.
So, any way to properly remove old cosmetic bullets and let new bullets be created using the MakeFromTemplate function?
I figured out how this happens btw; it’s when the entire tool (and thus script) is destroyed, but the cosmetic bullets are not removed. Any quick solution for that?
I have fixed this myself for now, by firing an event every time I destroy the tool harbouring the cache. Maybe there’s an automatic way to implement this in the cache, so I’ll leave my previous comments.
1 Like
I’ve run into bug where if I shoot my bullet you can see bullet’s trail going from the sky and when the bullet lands you can also see that the trail goes into the sky
I tried enabling and disabling the trail but it didn’t give me any results 
oh and here’s my script
local function onRayHit(cast, raycastResult, segmentVelocity, bullet)
local hitPart = raycastResult.Instance
local hitPoint = raycastResult.Position
local normal = raycastResult.Normal
local hit = hitPart ~= nil and hitPart.Parent ~= nil
if hit then
local humanoid = hitPart.Parent:FindFirstChildOfClass("Humanoid") -- Is there a humanoid?
delay(.01, function()
bullet.tracer.Parent = nil
print("falsed yo mama")
wait(2)
bulletCache:ReturnPart(bullet)
end)
end
end
This issue is happening because the PartCache system essentially teleports parts to a very high position out of render.
To fix this, you could either:
- Switch from trails to beams, as they follow very similar properties, allowing you to use the same textures, attachments etc. (easy way).
- Go into the FastCast module itself, and find where the projectile is teleported, then enable the trail right after its teleported. You would have to also disable the trail before its teleported back to the sky. (hard way)
Beams don’t have lifetime since they don’t draw trail-like segments as beams are only for parts to parts instead of that, it’s better to use mesh as bullet or particles.
2 Likes
Whenever I pull parts into the workspace it causes SERIOUS lag. Im thinking it could be because of the module because if I put the parts into the workspace before running the game, it works super smoothly. The part is a meshpart with 24 bones in it (using it for mesh deformation). Do you know what the issue could be?
I am using this module for a barrage effect. For some reason the trail shoots up into the air, and when I just disable the effect until its in the air it affects all the parts in the cache.
I noticed if you use this with any part with trails it becomes quite weird, with the trail being visible as the part teleports to the proper location. How could I fix this?
Disable the trail right before it’s teleported, and just enable on parent.
Running into a critical issue right now, in conjunction with FastCast. Whenever I return a bullet to the container while the camera is looking in certain directions, nearby parts flash for precisely one frame. It’s uncomfortable to look at, breaks immersion, and is - most importantly - a health and safety risk to players with epilepsy.
EPILEPSY WARNING
4 Likes
I’m getting this errror
Attempted to return part "AcidRain" (Workspace.Debris.AcidRain) to the cache, but it's not in-use! Did you call this on the wrong part?
However, I can’t see how this could ever be possible? As the only way the .Touched on a part is being called, is when it’s repositioned, which is after the GetPart is called
self.AcidRainCache = PartCache.new(AcidRain, PART_CACHE_LIMIT, workspace.Debris)
for _, acidRain in workspace.Debris:GetChildren() do
self.Trove:Connect(acidRain.Touched, function(hit)
if hit:IsDescendantOf(workspace.Debris) then
return -- Ignore other acid rain pars
end
self.AcidRainCache:ReturnPart(acidRain) -- ERROR
end)
end
task.spawn(function()
local Interval = 0
while self.Active do
for _ = 1, 10 do
local NewAcidRain = self.AcidRainCache:GetPart()
NewAcidRain.Position = MapContainer.Position
+ Vector3.new(
math.random(-MapContainer.Size.X / 2, MapContainer.Size.X / 2),
MapContainer.Size.Y / 2,
math.random(-MapContainer.Size.Z / 2, MapContainer.Size.Z / 2)
)
NewAcidRain.Anchored = false
end
task.wait(0.05)
Interval += 0.05
end
end)
Seems like the issue is that the .Touched event remains connected while the part is cached. PartCache keeps parts in the workspace - thousands of studs away. Try connecting .Touched when the part is taken from the cache, and disconnecting the event immediately before the part is returned to the cache.
2 Likes
Unsure what I am doing wrong, but I have a part structured like this. When using PartCache however, the Fure part isn’t attached to the bomb, even tho the weld constraint is connected properly.
So when they spawn in, the fuse is seperated from the part for some reason.
Note, when just using Bomb:Clone() it works fine, so it’s definitely not the weld/etc.
bit late but I ran into this same issue with my part caching implementation and realized that it’s caused by the cframe location where parts are sent to when they’re in cache. parts being sent >10e8 studs away causes this to happen semi consistently when looking downward near adjacent walls in first person, I currently have the cache at CFrame.new(0, 10e7, 0) which doesn’t have this issue
3 Likes