Making a combat game with ranged weapons? FastCast may be the module for you!

The ray’s current point is designed to simulate the end point of the projectile.

Based on what you said, I’m going to assume you are CFraming a projectile to the position of the ray. If this is the case, you simply need to modify your CFrame to put the bullet behind that point. This is fairly simple, but for the sake of giving proof of concept I’ll supply example code anyway.

You should do something along the lines of this. Assume the bullet is a standard block part. (If it’s a mesh that isn’t using a MeshPart, or more specifically the visual projectile does not reflect the size of the part instance itself, you will need to find this length value for how long the bullet is).

Bullet.CFrame = CFrame.new(RayPoint, RayPoint + RayDirection) * CFrame.new(0, 0, Bullet.Size.Z/2)

This will cause the front of the bullet to be placed at the location of the ray’s current point, thus causing the front of the bullet to be at the point of hit detection. Hopefully this helped you out enough. Just ask if you need anything else.

9 Likes

@Xan_TheDragon

Is there a reason why you do something like

if Tool.Parent:IsA("Backpack") then return end

instead of just

if true then
   Code
end

why are you doing

if false then
   return
end
Code
3 Likes

Would this work work with unique weapons such as firehoses and the boxing gloves from Nintendo’s Arms?

3 Likes

It’s a common coding style. It’s a way to get your edge cases out of the way so you know that the general case code will run correctly.

12 Likes

I thought it would have something to do with performance.

3 Likes

What I meant was if it’s possible to increase the size of the hit detection ray on the x and y axis so the projectile doesn’t go into the ground so much before a hit is detected:

image

I’d like the hit detection to happen when the very edge of the projectile hits something on all sides.

7 Likes

Is this Intentional or an Error?

When you zoom all the way with the Example Gun you provided, when I aimed at the Head it shot at the Body but when you zoom out it shot at the head.


I also want an Answer for this question from you @Xan_TheDragon


@Chaotic_Cody No hard feelings, maybe he has a different Reason.

5 Likes

No problem at all! In fact, it’s great to verify your information with multiple sources.

6 Likes

I’m not @Xan_TheDragon, but I personally do this, too. This is called a guard clause. Having lots of nested ifs can be hard to understand. A bit of code saying, “do nothing if X”, on the other hand, is pretty easy to understand even if there are a lot of them.

The guard clause is not a bad thing, and many (myself included) would consider it a very good thing that keeps code tidy and easy to understand. At the least it’s stylistic preference, which is :+1:.

19 Likes

If you have no else branch and you have a large amount of statements inside of the conditional, you’re saving on a lot of indentation space by returning when the guard doesn’t hold before doing that code.

6 Likes

@buildthomas @Corecii

That makes sense, I didn’t understand why Xan did it is because there is no Else or Elseif just one Condition.

So it’s kinda like a preference thing and also a good for performance if there are tons of Elseif & Else?

4 Likes

It is a preference thing. I don’t think it has a significant effect on performance. Most of its benefits are in readability and maintainability. Guard clauses are easier to understand and easier to work with than if blocks, which makes it easier and faster to write new code and maintain old code.

8 Likes

This is precisely the reason. It looks cleaner and gets stuff out of the way.

Performance really isn’t a worry. In the chance that something does affect performance, the amount of time is generally not perceivable (around 1ms, if that). Personally I wouldn’t worry about performance because of the way something is written or stored unless you’re writing in some language like C++ where you have control over memory and the exact ways something is handled on the lower levels of computing - more, where incorrect use of something can cause huge issues in the program.

There are some cases in Lua where performance is altered on a much larger scale (one observable case that was tested involved pairs vs table.foreach, where pairs ran faster), but there’s a certain point in which the changes are so minuscule that you can safely ignore them.

6 Likes

I see what you mean now. Thanks for the visual.

In this case, no, the module does not accommodate for wide projectiles. This is one drawback that I hadn’t foreseen, and I don’t see any immediately viable way to resolve this issue. I’ll think about it.

7 Likes

Ok got it.


What about this?

7 Likes

That’s a problem with my gun script rather than the module. I’ll have a look at it.

6 Likes

I think it has something to do with

function GetMouseDirection(MousePosOnScreen)
	local X = MousePosOnScreen.X
	local Y = MousePosOnScreen.Y
	local RayMag1 = Camera:ScreenPointToRay(X, Y) --Hence the var name, the magnitude of this is 1.
	local NewRay = Ray.new(RayMag1.Origin, RayMag1.Direction * 5000)
	local Target, Position = workspace:FindPartOnRay(NewRay, Players.LocalPlayer.Character)
	--NOTE: This ray is from CAMERA to cursor. This is why I check for a position value - With that value, I can get the proper direction
	return (Position - FirePointObject.WorldPosition).Unit
end

Client Line 15

local RayMag1 = Camera:ScreenPointToRay(X, Y)

4 Likes

Try changing it to Camera:ViewportPointToRay(X, Y) and see if that fixes the problem. Thanks for pointing it out.

3 Likes

Nope, I think it made things worse.

3 Likes

Does this feature penetration?

3 Likes