if you want to use trial and error, it really depends on the gun. older guns might have much more bullet drop than modern ones, but either way it should only really be noticable at long range. remember that in real life bullets are so fast you can’t usually see them, not a lot of time for gravity to act on it.
Why is the projectile trajectory origin positioning so inconsistent? I am running FastCast on the server, so is it because of ping?
I think I found a solution for the bullets phasing through targets problem.
It seems that the lower the bullet’s velocity, the more likely the bullet travels through the target. I’m guessing the issue is that lower velocities increase the chance that a ray is created at the exact edge of a part, making them not register the hit.
My solution was to bring back every ray by 1 unit, to catch any potential surfaces before continuing. Here’s a visualization:
In code it’s pretty simple, just replaced this code on Line 152 of FastCastRedux:
local hit, point, normal, material = castFunction(lastPoint, rayDir, listOrIgnoreDescendantsInstance, ignoreWater)
with this one:
local hit, point, normal, material = castFunction(lastPoint-displacement.Unit, rayDir+displacement.Unit, listOrIgnoreDescendantsInstance, ignoreWater)
Feel free to code this more elegantly, but this seemed to work for me
Is there any way to affect the bullets after they have been fired? e.g freezing it or controlling its direction
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.
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.
@EtiTheSpirit
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
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.
CLIENT
SERVER
(there are bullets, even if you can’t tell. I’ve seen them. They look perfectly fine.)
Can anyone help me with this issue?
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
Using only one script to handle all my weapons. How would I create a Caster instance unique to each player?
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?
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?
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.
Will I be able to use this module for something like a shotgun, a weapon with multiple projectiles?
You can make shotguns very easily with this absolutely beautiful module.