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).
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.
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:
I’d like the hit detection to happen when the very edge of the projectile hits something on all sides.
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 .
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.
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.
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.
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.
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
.