Oh my, there’s so much to unpack in this thread.
The people here are not explaining why.
…and this bothers me, a lot! So, let’s explain some concepts.
@Styre_x says that,
A ray is not a “physical” object, nor is it something you can parent to! If you want a ray to be able to have a “velocity” you need to update it frequently.
This is a very good start, but we can expand on this.
Think of a raycasting operation as a laser beam; a raycasting operation will send out a beam from a given position with a given direction and instantaneously evaluate whether or not that beam hit a part, mesh, terrain, or other collidable object using only math.
The key word here is math. The raycast is never a physical instance like a part; that’s why you never have to call Instance.new(). Instead, you just call the raycast function, it does the math, and then spits out the result.
What I think you’re trying to do…
I think you’re trying to create a small part instance that represents the bullet, and then give it a high velocity to simulate a speed of a bullet.
As other people have been saying, this is going to leave you with a disaster. But let’s explain why:
Why it isn’t going to work well…
Using small parts going at high speeds to simulate bullets will have a lot of problems.
First, as @marfit diagnosed, you will have lag issues. Despite the Roblox engineering team’s best efforts, fast moving parts that are physically simulate will still have some lag due to the unavoidable problems that slow connections have with realtime physics. Your part-based projectiles will be very laggy and will not play well.
The worst problem, however, comes down to how Roblox’s physics engine handles collision detection. If I’m not wrong, Roblox implements discrete collision detection. In discrete collision detection, objects are translated by their velocity every frame. Once an object is moved, the physics engine checks if it has any collisions, and if so, it resolves them by adding the necessary force to keep the objects separated.
This sounds bulletproof in theory, but consider the figure below. The first example shows discrete collision detection. As we can see, the velocity of the puck is so fast that it will bring the puck through the wall. Once it has moved for that increment of time, it technically isn’t colliding with anything, so the physics engine will evaluate this movement as valid. The result: the puck goes through the wall even though the wall exists and should cause a collision.
What this will translate into in Roblox is that your small, fast moving part-based projectiles will often fail to hit physical targets like players. This is because they are moving so fast that the bullets literally phase through them.
What raycasting will give you is what is called continuous collision detection, which is represented in the above figure as the second example. Using mathematics and a known position and initial velocity of a projectile, we can evaluate for collisions continuously rather than only at the end of each frame’s movement.
How we can use raycasting to simulate fast-moving projectiles?
This brings us to the following question: if raycasting is instantaneous, how do we simulate projectiles with velocity using raycasting?
Truth is, implementing something like this on your own is far out of scope of a single forum thread, and I think this is a lengthy enough read as is. This is also why folks like @Styre_x have suggested to use FastCast; making something like this on your own is difficult, requires a solid foundational understanding of networking and physics, and is just hard to get right.
HOWEVER, If you do wish to fall down the rabbit hole of implementing something like FastCast on your own, I have an open source uncopylocked place that has (albeit, an inferior implementation) of a similar way to simulate projectiles using raycasting. It is thoroughly commented, so you should be able to pick it apart and then use it as a foundation for your implementation. You can find it here!
On being dismissive…
I’m not going to use any dumb other things because my game isn’t an FPS game it’s a regular game.
For one, please refrain from calling libraries “dumb.” Libraries like FastCast are built by passionate and incredibly bright programmers who have published the results of many hours of frusturation and labor free for everyone to use. Open source developers aren’t dumb; they are the unsung heroes of this platform.
Lastly, if my post did anything, I hope it makes you understand why using libraries such as FastCast is far from dumb. Making something equal to FastCast will take many hours of labor, and there’s really no reason not to just use a library as ubiquitous as FastCast in your situation. In short, using FastCast is easier, and will likely make your codebase leaner rather than more bloated.
I hope my post was helpful to you or any passing readers!
