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.
Is it possible to increase the hitbox (size) of the ray? Deciding if I should use this over my own module.
I could add a cancellation token system, an object you keep track of that offers a cancel method that tells the cast to stop.
I might.
Nope! Rays are always one-dimensional. There’s no way to add width to them. The only method would be a grid of rays which can cause other problems.
I had figured out an alternative, I added a hitbox that travels with the ray and that acts as my primary hitbox.
I’m having a hard time figuring out how to even get the module working. I am able to require the module but when I try to draw a ray I get nothing. What I’m trying to do shoot a bullet using fastcast and part cache from a brick that shoots at a interval from a server script.
Fastcast.new() Fastcast.fire(Script.Parent.Cframe * CFrame.new(0,5,0))
1 Like
Is there any way to remove or reduce the delay between bullets appearing ?
Thanks for helpful answers ^^
There actually is! This module is using spawn(), which is decent for debugging, but when it comes to instant firing, using a coroutine is much better. To fix the delay, just replace spawn with coroutine.resume(coroutine.create and add ) to the end of the function. For whatever reason (could just be me being an idiot with coroutines) coroutine.wrap doesn’t work. This makes projectiles fire as soon as it can, instead of next wait() resume, which can be seconds in some cases. More info about spawn vs coroutines here
@EtiTheSpirit, do you have plans to replace the spawn functions with coroutines to allow for faster bullet spawn times? -Edit; my module was 2 versions out of date.
2 Likes
I can’t find a single line where FastCastRedux uses spawn()?
2 Likes
That delay is because you’re waiting for the server to render the bullet
You should render a client side bullet on the client and fire an invisible bullet on the server and replicate it to the other clients
2 Likes
I must have an old version then. In the module I am using there were 3 spawn lines.
Edit, yes, my module was 2 versions out of date, my bad.
1 Like
Would it be possible to add a bool for the bullet to follow the mouse cursor for guided projectiles? That would be super useful!
1 Like
I don’t fully understand this module after ~1 month of using it
since I’m horrible at CFrames, but I’m pretty sure it casts rays each time it travels.
So maybe you can go inside the module and make the rayDir.Unit be the current segment/origin facing mouse.hit.p
Is there a way to port this code in to an local script ?
Im making a single player game and i dont like those delays, or maybe im better of making a tradytional ray based weapons ?
Change the server script to listen to a remote event, and move the code from the current server script to a localscript. Connect the firing function to a click, and when the gun fires, fire a remote event with bullet information (startPos, startDirection, gunType, etc). When the server is fired, it goes through all the players and fires a remote event to replicate the bullet to all players but the one who fired the bullet. When the bullet hits something, if the bullet is owned by the player (not a replication bullet from the replication event), it tells the server what it hit and what gun it hit with. This isn’t the most secure, there are many ways to make it more secure and prevent exploits from abusing it, but that is the basic idea.
2 Likes
How do you make sure it’s not exploited? Like if you make it so when the bullet hits something, you fire a remote to tell the server it will be easily exploited. Could you give me some sanity check ideas
Something like keeping track of players and their respective pings, and keeping track of where all the players are. When a remote is fired, you raycast from the player’s position that fired the remote, and check to see if it can actually go to the place it says it was hit from, using the array of player pings and positions to check. Here is some more info about sanity checks with a gun game: Anti Exploit in a gun-based game?
That raycast check will only work with high speed bullets. With something like an arrow, or really anything slower speed they will shoot, instantly go behind a wall. By the time the arrow hits something, they’ll already be behind a wall, so that raycast check will fail.
Now, you could store the location of where you shot from on the client, but the exploiter will easily be able to change that value next to the enemy’s head. And even with this system, since arrows have curves it would still fail since the arrow might land behind a wall.
Really, it’s a constant cat and mouse game against exploiters, you’ll never win against them. Whatever you do, they’ll be able to exploit in a few hours so I really think it won’t be worth spending like 20 hours to make some really complicated system that would still eventually inevitably get exploited if your game is popular enough.