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.
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?
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.
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.
Ok got it.
What about this?
That’s a problem with my gun script rather than the module. I’ll have a look at it.
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)
Try changing it to Camera:ViewportPointToRay(X, Y) and see if that fixes the problem. Thanks for pointing it out.
Nope, I think it made things worse.
Does this feature penetration?
It doesn’t, but you can just fire the bullet again (probably have to move the bullet foward a bit) once it hits something.
This is one method, yes Rather, the second bullet should start from the previous hit location however. My suggested method was to add the parts that you wish to penetrate to an ignore list.
To @TheRings0fSaturn - I may add a few other utilities to modify ignore lists / whitelists in realtime, it just depends on what gets requested. For now you will have to use a tricky method like the one lightning suggested. I may append such a feature though.
Please add a system for penetration - I feel it’s a needed feature in a system such as FastCast. 
Though, I might create a penetration system and make it based on material w/ a thickness modifier, if I can figure out how to recast raycasts.
I’m a bit late but yeah, I think something like that could be written in whenever I get some free time.
Sounds awesome, Xan!
@Xan_TheDragon I plan to use FastCast in an upcoming game of mine where shooting is an essential part of the gameplay. Unfortunately, I’ve found some limitations with your module, and I wanted to recommend some potential changes to make it better The first recommendation is that, I don’t believe at the moment there is a way to send an ignore list into the module and have the raycasting ignore any objects on that list. This is essential because bullets need to shoot through windows and invisible parts. I also think collision groups for the bullet would be extremely useful to support. Aside from that, I’d have to say it’s hard to beat! Good luck, and thanks,
-big
An ignore list is included already as part of the feature set. Check out the functions section of the API to see it.
As for collision groups, that would be an interesting capability. I may consider it.
Hey everybody! I’ve just uploaded a video to YouTube in regards to those reporting issues with network latency (Bullets don’t lag in studio but lag in online mode).
This video is a basic tutorial of how to set up a simple network replication script. For those who are familiar with this, I have simply removed the cosmetic bullet from the server and instead told all of the clients to fire their own caster with a specific cosmetic bullet depending on the weapon or tool that has fired the event.
Hopefully this clears up a lot of issues. I may re-do this video in the future since I do take quite some time to explain and create this stuff.