Also try changing the hitbox type from default to box. That helped me a ton
The github link doesnt work anymore??
I had just purchased my own domain – it’s fixed now. Sorry! I’m brand new to DNS stuff and messed up some stuff.
3 Likes
These recent updates are excellent! I love that you incorporated the reflecting right into the example gun. I have to say though, I didn’t realize that I could use the Pierce function for so much more than just going through specific walls. I’ve been toying with it a bit and it’s actually a super helpful function.
Regardless, being able to change the velocity, acceleration, and position of my casts on the fly, along with pausing/resuming them is great. I already have a couple ideas in mind for what I’m going to do with these. I believe the most helpful new addition I’ve started using is the UserData table. It’s really nice to be able to throw variables into this table rather than passing that variable through like 4 functions.
All of these changes are very welcome, although I do have a question. Is there some way that I can still pass in my own cloned CosmeticBullet rather than the module doing the cloning itself from the template it’s given? In FastCast Ver. 10.0.0, the user is required to clone the bullet themselves and pass it in, and while the new template functionality is much cleaner, passing in my own cosmetic bullet was crucial to incorporating FastCast with the PartCache module.
Basically, this was my code before:
-- Get a bullet from the PartCache
local bullet = BulletCache:GetPart()
bullet.CFrame = CFrame.new(FirePointObject.WorldPosition, FirePointObject.WorldPosition + direction)
bullet.Parent = CosmeticBulletsFolder
-- Fire the caster
Caster:FireWithBlacklist(FirePointObject.WorldPosition, direction * BULLET_MAXDIST, modifiedBulletSpeed, blacklist, bullet, true, BULLET_GRAVITY, CanRayPierce)
As you can see, rather than cloning my own CosmeticBullet, I get one from a PartCache, and then give the FastCast module that bullet. While I could probably get by without using the PartCache module, my game is most likely going to need it so that I can keep it as fast as possible. I’ve been looking through the documentation and also the FastCast module itself for somewhere I could edit the PartCache functionality in, although honestly I’d rather leave the FastCast module as it is so that I don’t have to put the edits in with every new version.
Perhaps doing this is still possible and I’m just missing it somehow, if it is then I wouldn’t mind a pointer where haha. Other than this though, I’m really loving the FastCast updates! It took me a bit to get around to incorporating it into my game, although I find that all this new functionality is already paying off! 
EDIT: One more thing, is there some reason we’re not allowed to Pierce water? In the previous version of my guns I had a BULLETS_IGNORE_WATER variable, although now I can’t seem to get it to work. It’s for deciding whether bullets should stop or not when they hit water. Editing the cast with cast.RayInfo.Parameters.IgnoreWater = false has an error specifically for that case for some reason. I could just disable the error() call, although I’m wondering why that might be a fatally bad idea 
2 Likes
To be honest, “pierce” is a bit misleading, but fitting “A function that runs on any hit and can decide to terminate the cast or keep it going after changing it in any way” into a simple name is a bit tough. That, and the main purpose is for piercing. Yeah, any changes on the fly where the bullet hits something and you want to keep it going are indeed possible. The pierce function is a lot more powerful than it seems on the surface, which is part of why I added that to the example - I wanted people to see just how far they could push it.
Right now, no, not in the function call itself. I did this change because the vast majority of use cases ended up just cloning some template so I decided to cut that out of user scripts. On top of this, the ideology of the behavior packet is that it should be a singleton, so editing in something dynamic (setting your own instance of a cosmetic bullet) doesn’t fit that ideology.
You can do it manually, however, via editing the RayInfo object (see https://etithespirit.xyz/FastCastAPIDocs/fastcast-objects/castrayinfo/)
local cast = Caster:Fire(...)
cast.RayInfo.CosmeticBulletObject = whatever_you_want_here
That instance will be passed into the functions like any other cosmetic object, so it will be fully compatible with all existing code - no complications.
If I recall, a comment there or the error message itself describes it. In the scope of raycasting, Terrain is a single part. If you pierce water, that cast will never hit terrain again until the pierce routine completes, which means that if you shoot a body of water, that bullet will keep going until it exits the terrain without registering hits. This is part of why Roblox’s raycasting offers a specific variable to ignore water, and is why you should use that as well.
2 Likes
Yeah the name might’ve misleaded me previously, although now I realize that the functionality of the function can be pretty powerful. Can’t wait to see how far I can push it.
If I set the CosmeticBulletObject after firing, will the FastCast still be creating a bullet from the template first and then replacing it with mine? If that’s the case, I feel like incorporating the PartCache module now may actually be slower than not having it at all. What I mean by this:
No PartCache module:
-- Caster creates new instance from the template
local cast = Caster:Fire(...)
With PartCache module:
-- Caster creates new instance from the template
-- Get a new CosmeticBulletObject from the PartCache module and put it into the RayInfo
-- Potentially some internal thing goes on inside FastCast that discards the old CosmeticBulletObject
local cast = Caster:Fire(...)
cast.RayInfo.CosmeticBulletObject = BulletCache:GetPart()
As you can see, even with the PartCache incorporated, the Caster may still be creating a new instance when its fired, which is slow and defeats the purpose of the PartCache (which is to avoid creating new instances). In my game, I plan to have a lot of players firing guns very rapidly, so keeping the server as fast as possible is crucial. Any insight on if my thinking here is right or wrong would be super appreciated! Also thanks for the insight about the terrain issue, I don’t think I’ve heard of that issue before.
Which is why you set the template to nil if you are using this method. If you don’t do that, you’ll actually leave a stray clone part just laying around in the parent for the cosmetic bullets because you overwrote its reference with your own.
Effectively what you’d be doing with this manual change is exactly what it seems like - manually controlling the cosmetic bullet that the module keeps track of rather than allowing it to create it automatically.
On a bit of a side note, I may write in support for PartCache natively anyway. I was working on another tiny utility I’m internally calling TypeMarshaller (it might have a different name on public release) which allows objects to return custom type names in typeof via providing a custom overwrite of the typeof function, and I can use this to determine whether or not the referenced module is an instance of PartCache.
FastCast v13.1.0 Released.
I’ve addressed the ever-popular request to incorporate PartCache into the module. It is now able to interface with PartCache (it doesn’t actually include it, it can just use it). See FastCastBehavior.CosmeticBulletProvider for more information.
Note: To use this, you need to upgrade PartCache. That, or add PartCache.__type = "PartCache" to the top of the module where the table is defined.
4 Likes
Ohhh so that’s why that was happening to me. I overrode the old CosmeticBulletObject anyway despite my fears and didn’t think of setting the template to nil. Also, that TypeMarshaller utility sounds OP. I’ve been experimenting with the new Luau type checking beta recently so I’ll be checking that function out once I get to developing today
On a side note, this is awesome! I hope I didn’t pressure you too much into doing this haha. This update is super appreciated though and I’m gonna get right to updating my modules. Thank you for all the help!
1 Like
Hey, sorry to bother you here, but I’ve been having problems with actually firing a projectile. There’s a good chance I’m doing it wrong but it always ends up looking like this. Here’s the code:
local repStorage = game:GetService("ReplicatedStorage")
local attackRemote = repStorage.Remotes.AttackRemote
local deb = {}
local cooldowns = {
PUNCH_COOLDOWN = 3;
PSYCHIC_COOLDOWN = 1;
}
local fastCast = require(script.FastCastRedux)
local caster = fastCast.new()
local params = RaycastParams.new()
local castVisual = Instance.new("Part")
castVisual.Color = Color3.fromRGB(99, 45, 132)
castVisual.Size = Vector3.new(1,1,1)
local behavior = {
Ranged = function(plr, weapon)
local a = deb[plr] and print(os.clock() - deb[plr])
if deb[plr] and os.clock() - deb[plr] < cooldowns[weapon:upper().."_COOLDOWN"] then return end
deb[plr] = os.clock()
local castBehavior = fastCast.newBehavior()
params.FilterDescendantsInstances = {plr.Character}
params.FilterType = Enum.RaycastFilterType.Blacklist
castBehavior.RaycastParams = params
castBehavior.MaxDistance = math.huge
castBehavior.Acceleration = Vector3.new(0, -workspace.Gravity, 0)
castBehavior.CosmeticBulletTemplate = castVisual
castBehavior.CosmeticBulletContainer = workspace.visual
local char = plr.Character or plr.CharacterAdded:Wait()
local hum = char:WaitForChild("Humanoid")
local headFacePosition = plr.Character.Head.CFrame * Vector3.new(0,0,-(plr.Character.Head.Size.Z/2 + 2))
caster:Fire(headFacePosition, plr.Character.Head.CFrame.LookVector * 99999, 99, castBehavior)
attackRemote:FireClient(plr, weapon)
print("can punch againg")
end;
Melee = function(plr)
end
}
attackRemote.OnServerEvent:Connect(function(plr, weapon)
behavior["Ranged"](plr, weapon)
end)
1 Like
Do you connect to caster.LengthChanged anywhere? You need to use this function to CFrame your cosmetic bullet (refer to the example gun). Also, anchor your cosmetic bullet.
3 Likes
You can sync them to nearly 100% accuracy.
When you shoot on client, the server can offset the bullet based on your ping. I did this by manipulating some of the variables when fast cast starts. The issue with this is, close range shots will go through walls, but to fix that I added a raycast and its functioning fine now, although my syntax is pretty crappy.You can sync them to nearly 100% accuracy.
When you shoot on client, the server can offset the bullet based on your ping. I did this by manipulating some of the variables when fast cast starts. The issue with this is, close range shots will go through walls, but to fix that I added a raycast and its functioning fine now, although my syntax is pretty crappy.
2 Likes
Thanks for telling me that lol. I had a feeling I needed to look for something about CFrame or some kinda movement but ig I missed that hehe.
2 Likes
Quick follow-up question though, is it bad to create multiple part cache objects at once? Common sense should obviously say yes but are the effects severe?
1 Like
Quick question, does this work irregular projectiles like say, a fireball which is a circle? or is it only useful for guns?
1 Like
if you still didnt fix the problem DM me on discord and I’ll see if i can help you TheFortex#3192
1 Like
If you need different part pools then yeah go right ahead and make multiple. Just don’t make a new one every time the gun is equipped or whatever.
3 Likes
It would work. You just need to modify the script slightly
1 Like
Hey this is a question about the example gun I can’t check the source right now but are you creating a new RayCastParams every fire, or reusing one? The problem I see with reusing is bullet penetration, when something is hit you wanna add it to the ignore list. But if you add to the ignore-list it will affect all the bullets because it’s the same table reference. (or is raycastParams.FilterIgnoreDecednats doing something else)?
So are you creating a raycastparams each shot or reusing?
1 Like