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.
You should add a parameter to specify the starting alpha (totalDelta) of the shot.
Would it make sense to just keep track of every players Caster instance with the Players.PlayerAdded event?
FastCast v9.1.0 is out, ladies and gents!
+ Added new built-in cast visualization. No more copying code from the example gun. This new visualization is very versatile and shows casts that are cancelled (due to piercing), as well as hits.
* Fixed a bug with piercing casts sometimes skipping embedded solid objects (e.g. a piercable wall with a layer of non-piercable stuff inside of it) (reported by dispeller)
* POTENTIALLY fixed a bug causing physics casts to fall through the floor or walls (reported by lots and lots of people)
- Removed visualization code from the example gun.
(n.b. the red arrows are casts that ran but were cancelled due to piercing.Green spheres represent casts that were allowed to continue after impact, and red spheres represent casts that stopped due to an impact)
9 Likes
I could see to this.
It’d work.
2 Likes