Raycasting question and swords

Help and Feedback Scripting Support
#1

I’m attempting a few theories but I’ve always been bad at how rays work.

I’m simply attempting to create a ray between two attachments of a sword (top and bottom) and use it to detect what parts are intersecting with the ray.

It is a part of a theory and my research of people with the same question just ended up with people saying “not to do it”. I’m doing it to see how accurate it is on the server because to my surprise GetTouchingParts is somewhere in the ether with detecting accurate position on the server.

local RayCasted = Ray.new(Sword.Attachment0.Position, Sword.Attachment1.Position)
local Hit_Parts = GetAllParts(RayCasted, Sword)

Sword is the handle just to note.

local function GetAllParts(Hit, Sword)
	local Parts = {Sword}
	local LastPart
	if Hit ~= nil then
		print(Hit)
		repeat
			LastPart = workspace:FindPartOnRayWithIgnoreList(Hit, Parts)
			table.insert(Parts, LastPart)
		until LastPart == nil
	end
	return Parts
end

Thank you in advance!

#2

If there are any alternatives to rays I am open to that as well.

#3

I would recommend doing hitbox’s on the client if you prefer Accuracy over Security

Clientside = Accuracy > Security
Serverside = Security > Accuracy

Pretty sure no matter what method you use it will perform better on the client instead of the server

#4

If I understand this post correctly, Swordphin123 has made a Raycast Hitbox Module that should be really easy and useful for your cases, if you’re trying to get accurate melee weapons while optimizing and having it not be a big hassle. It uses attachments so you don’t have to hardcode the hitboxes for different weapons, and raycasts them every frame.

Another person has made a client-sided alternative to this hitbox module if you want to raycast on the client. Gives much better accuracy and low latency at the cost of a security compromise, however, you can minimize exploits on the client with sanity checks on the server for hit registration and all that stuff. (e.g. how far away the raycast is from the origin of the attachments)

As with @Extrenious’ post, it’s not 100% possible to stop exploits on the client when raycasting, but the best you can do is basic sanity checks on the server to minimize the hacks.

However, it’s up to you if you want to do stuff on the client (less lag, but is most vulnerable without server-sided sanity checks) or on the server (more security, more latency)

#5

Adding onto this, it’s actually possible to verify raycast data from the client within 0.1 stud accuracy! I’ve spent a month or so working on code that backtracks not only a player’s position, but their animation too - and then, the server compares the backtracked positions of the attachments, and how far off the line between two attachments the hit position actually is.
In theory, if a hit is sent from client that is not exploited, then the hit position shouldn’t be more than one tenth of a stud away from the line which the server calculates.

1 Like
#6

I’m aware. My goal is to create a sword that cannot be exploited. GetTouchingParts I tested and is not actually accurate to the absolute position from the server. That is why I’m trying to see why the ray isn’t working.

#7

I saw the module but I’m trying to do something a little bit different than that. I’m looking to do it on the server. Just trying to see why the ray isn’t working.

#8

Sounds awesome! Share? :3 If not share then halp with ma issue? :)?

#9

The issue is that rays take in two inputs: the starting position, and the direction. What you provided instead was two positions, which is very different.

instead, your could should look like so:

local Position0 = Sword.Attachment0.Position
local Position1 = Sword.Attachment1.Position

local Direction = Position0 - Position1

Ray.new(Position0, Direction)

If that doesn’t work, try Position1 - Position0 instead. As a sidenote though, you should be using workspace:Raycast instead, as workspace:FindPartOnRayWithIgnoreList is deprecated.

#10

Didn’t seem to work. Direction makes sense, but does that provide the direction?

#11

If I’m not mistaken your logic is a little off being you’re using Position0 as a starting point you’d want to make direction Position1 - Position0, or just flip the starting Position to Position1

#12

Oddly enough it still didn’t work reversing it in any regard so far…

#13

Is the way that the table is set up for the ray the issue?