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
Uhh, I don’t think this looks right?
https://gyazo.com/d103d43733889386e338c419e2a4047b
All I did was make the projectile slow, and add downwards acceleration in the bulletAcceleration parameter to simulate gravity
The shots seem to hit correctly (I tested 20 shots, and all of them hit correctly), so is it a problem with your visualizator?
Also, do you simply ray cast from point in previous frame to point in current frame? If so, then wouldn’t shots with unique acceleration, like not hit detect correctly if there is lag/delay between frames?
Apologies if this has been answered already, I tried to look through most of the thread (over 90%). I’m new to using this module and I’m trying to make a gun system. I want to make the networking behind it as least laggy as possible while not being too exploitable. I found that this reply and this reply seemed to know how to make a non-laggy weapon but I’m having trouble understanding how they work so I can make my own from scratch using those ideas while functioning well. I noticed that using a modified debug gun it gets annoying to try and aim at moving targets as the higher the ping, the later the shots you sent in certain directions hits the target you want.
Any help would be greatly appreciated. 
1 Like
Hey EtiTheSpirit!
I’m not sure if you updated the Module to use the new Raycast API but I think you should put the module on Github since you are busy and we want to help you with maintenance.
1 Like
Probably. I’ll look into it.
Yes, this is one of the caveats of lag. Think of it like this: You have a graphing function, say, x^2. On a real graph, that’s a smooth curve, but in a game we are limited by certain increments of time. The effect is that you get a jagged line instead of a curve. More latency between captures (more lag) = a less precise representation of what’s truly going on under the hood.
Thank you, this module is amazing! It works perfectly.
When looking through the example gun, I noticed this (on line 96 of the server script):
local myMovementSpeed = humanoidRootPart.Velocity -- To do: It may be better to get this value on the clientside since the server will see this value differently due to ping and such.
Wouldn’t that be exploitable? Exploiters could send any value they want though the RemoteEvent. This could be fixed with clamping it on the server, but exploiters could still send a high value and have the bullets travel slightly faster for them.
Also, is it possible to have bouncing bullets with this module? I’m ok with having to do a little extra math myself, but I don’t exactly know how this module works yet and if it would even be possible.
Is there a way to prevent the bullet delay that occurs when shooting? When shooting initially, the bullet doesn’t appear until it reaches a few studs from the gun. This happens sporadically, and I was wondering if there was a fix for it. Thank you!
Is there a way I can access the velocity of the cast at any time during its trajectory? Trying to manually figure out the velocity with the formula v = d / t by using past positions and their times is very unreliable. LengthChanged seems to fire at such frequent intervals that recording time in the connected function seems to round off a lot of numbers. This results in wild discrepancies in the calculated velocity.
Code:
Caster.LengthChanged:Connect(
function(_, SegmentOrigin, SegmentDirection, _, Projectile)
local CurrentTime, CurrentPos = time(), SegmentOrigin
local DeltaTime, DeltaPos = CurrentTime - Projectile.LastTime.Value, (Projectile.LastPosition.Value - CurrentPos).Magnitude
Projectile.CurrentSpeed.Value = DeltaPos / DeltaTime
print(DeltaPos, "|||||", DeltaTime, "|||||", Projectile.CurrentSpeed.Value)
Projectile.LastTime.Value = CurrentTime
Projectile.LastPosition.Value = CurrentPos
Projectile.CFrame = CFrame.new(SegmentOrigin, SegmentOrigin + SegmentDirection)
end
)
When the Caster is first fired, the LastTime, LastPosition, and CurrentSpeed ValueBases are assigned the initial values that were input into the Caster’s Fire function.
Black cone arrows are just from FastCast’s
VisualizeCasts property enabled.
1 Like
Bug
Looks like you made a mistake with the distance traveled. You added displacement.Magnitude. This is fine with non-piercing projectiles, but it reduces the “range” (total distance to be traveled) on piercing projectiles (test this out with the DebugGun by shooting it at bunch of parts together while piercing demo is on, it should not go 1000 studs (the default range), but less because of hitting those parts). I believe you were supposed to add (point-lastPoint).magnitude right before the if hit and hit ~= cosmeticBulletObject then line? Unless you intended to reduce its “range” on hit?
Feature request
could you add a way to change the projectile’s trajectory mid-fire/mid-flight? Maybe store the projectile and check if another FastCast:Fire() sent the same object as projectile, and discard the projectiles’s previous :Fire()?
1 Like
That needs to be done manually for now. When I get around to adding the ability to redirect bullets during flight-time, this will probably be an option.
Not with default behavior, no, but I can see about adding this in.
The underlying issue is actually kind of complicated it seems, or I’m overcomplicating it due to being so tired. The old behavior set lastPoint = at. This worked great, with the exception that sometimes rays got spaced apart and this is why people were reporting issues where bullets with physics fell through the floor.
I’m going to do some work on this issue after I sleep so ideally I should have it fixed in a little while.