Making a combat game with ranged weapons? FastCast may be the module for you!

After trying the module I’ve noticed that it doesn’t do good with many projectiles and the fire function is pretty expensive, is that a known issue with this module?

I noticed that using the pierce function works half the time, using blacklist atleast I’ve noticed that the bullet will still pierce the object, but it will destroy the bullet and continue on as a ghost bullet.

Is there any way you can make the projectile move in an arc?, for example when you shoot a basketball.

1 Like

With the magic of cframing, yes. You can “modify” the firing direction parameter to account for adding in extra angle to a certain value. This way, you can add ark that is calculated and accurate.


You mentioned in a post (that I can’t find now) why this works better than using roblox’s default physics engine, can you elaborate on that for me please? Something about updating the cframe step by step or by lerping the cframe of the projectile on heartbeat, rather than the physics engine doing the update.

I have a problem simulating several hundred birds, they’re using BodyVelocity to move. Roblox’s physics engine simply cannot handle this so I’m hoping I can work around their physics engine altogether using a system like this or its underlying technique.

Any information on how I could use this for non-linear motion would be greatly appreciated :slight_smile:

Thank you!

How could I get the trajectory created by FastCast? I want to be able to like lerp a projectile’s trajectory into another trajectory so that I can solve this problem

Having trouble with position setting and beams in my v2 graphics engine. (admittedly) I am using a modified FastCast, but the only thing I changed was the part check on the cosmeticBullet to integrate it with beams.

Anways, I don’t see how that would be an issue because the issue is not replicated across the client/server boundary, which makes me think it’s a Roblox issue.



(there are bullets, even if you can’t tell. I’ve seen them. They look perfectly fine.)

Can anyone help me with this issue?

1 Like

That’s part of the pierce demo showing you how it can pierce objects (or basically ignore them)

Just for the demo gun, you would turn local PIERCE_DEMO to false

– pretty sure this was intended behavior

1 Like

Using only one script to handle all my weapons. How would I create a Caster instance unique to each player?

1 Like

Im having some problems, I figured out the arcing but the ball does not collide with any objects. Or is this not possible to fix?

1 Like

Sorry for being so late everyone. Been busy!

On the contrary! I’ve been able to do stress tests where I can run the Fire method over 1000 times per second without lag. You may need to check your implementation. One of the most common mistakes people make is creating a new caster in the function that fires the bullet. This will cause a lot of lag and also breaks a lot of how the module is supposed to work.

I’ll look into this. Could you try to disable the code that destroys your cosmetic bullet? I feel like it maybe firing Hit anyway even if it pierces.

Yep! Check out the API, there’s a parameter to the Fire function that can do this. @TeraWattt’s suggestion only works cosmetically, because it doesn’t change the actual ray itself.

The basic gist is that physics replication can cause problems when rendering. To offload server work, physics for blocks tend to be simulated on the computer of the client who’s closest to the part (or touching it directly). This system is complicated so my description there is a horrible simplification. Basically, you see parts jittering and hits failing to register because the part is lagging due to the simulator’s computer not being equipped for the task, or due to network problems. By taking the wheel yourself and CFraming things + rendering them for every client individually, you bypass this problem.

Dynamically changing trajectory isn’t possible. As for getting the trajectory? You have to get it as it calculates (just remember every segment when it fires). This is because if the world is dynamic or a player walks into the path of the bullet at a given time, it changes the outcome. Predetermining the outcome isn’t possible.

There’s a multitude of ways you could do this. My personal method? Create a custom module to keep track of players who join and leave. Clients can freely create their own casters whenever they spawn for rendering, and the server creates one for each player (or, one for each weapon a player could use). The player simply fires a server event that says “Hey, I fired this gun” and you handle the rest contextually on your server: What gun did they fire, and where are they?


Not sure if someone recommended this already, but it would be cool if we had the option to pause/stop and then continue to play the fired caster. When I fire the projectile from the client and send that information to the server, if the server declines the shot then I’m going to remove the projectile and stop the bindable event from being fired with that projectile. I made some edits so that your api would have the features that I listed, but it would be a really nice future update.


What if the projectile hits the enemy and the event gets fired before server declines the shot?

1 Like

I’ve tested that with the gun you provided to check if the problem relies with my code and it has been very expensive to use the fire function maybe there is a problem with the module? Try to do what I did with the gun for example that you made, instead of firing the bullet once every click do that multiple times one after another or just spam click and look at the script’s activity I dont really remember what went down completely but that’s what I do remember I’ve done.

1 Like

Will I be able to use this module for something like a shotgun, a weapon with multiple projectiles?

1 Like

You can make shotguns very easily with this absolutely beautiful module.


The server is the one handling hit detection so if you fire the bullet the server and there is a problem processing it, it will immediately respond to delete the bullet. If the bullet hits something already on the client it really doesn’t matter and it’s only a visual thing.

1 Like

Amazing. Are you creating new caster objects from the module and firing each caster for each shot? Or are you creating them with one caster object and firing that one caster multiple times?

1 Like

I’m using a for loop to create 4 bullets each with unique directions and then I’m using Caster:FireWithBlacklist to fire them.

So for loop creates a bullet, puts it into workspace (in a folder called CosmeticBullets), and it fires that bullet. Then it repeats three more times, but since there are no waits it is pretty much instant.


Are you going to / Did you update the Module to use the new API

workspace:Raycast, raycastParams and raycastResult?

1 Like