How would I calculate in which direction a part is going based on it's velocity?

[ZYTRXS (ZYTRIS)]

The title says it all, I’m trying to use raycasting with this

Image example:

LookVector or UpVector or anything like that is very unreliable. Just like in real life, things may or may not rotate while falling down

[Friendly4Crafter]

You can use a part’s AssemblyLinearVelocity to find out where it goes, since it is the rate of change in studs of its center of mass per second.

For example, let’s say a part is at 10,10,0, and its AssemblyLinearVelocity is 2,5,0.

In one second, its position will be at 8,5,0
In two seconds, its position will be at 6,0,0

Then you can calculate the direction of the raycast using this information, the DevHub has a useful equation for this:

[koziahss (Agent_Invalid)]

Yes AssemblyLinearVelocity would be the way to go.

If you want just the direction you can do .Unit which returns the unit vector for the direction of the assembly’s velocity.

[ZYTRXS (ZYTRIS)]

Thank you Friendly4Crafter and thank you kozhiass aswell, but, i’ve found out that just doing ((Part.Position + Part.Velocity) - Part.Position).Unit works aswell, REALLY well actually! I’m probaly going to use AssemblyLinearVelocity for other stuff in the future, I wasn’t even aware that existed.

[BuilderBob25620 (BuilderBob)]

Wait, why are you adding and subtracting the part position? Isn’t that redundant? You could just use Part.Velocity.Unit

[ZYTRXS (ZYTRIS)]

No, this doesn’t subtract it, (position - position) provides a direction.

[koziahss (Agent_Invalid)]

That’s not entirly true.
Direction is a unit vector
Position1 - Position2 Gives a Vector that is a vector from Position2 to Position1. Yes, it includes a direction but it also has a Magnitude which isn’t always 1.

It is quite confusing yes but put simply.

VectorA - VectorB Gives a vector from B>A (Which includes the direction)
(VectorA - VectorB) .Unit gives the direction from VectorB to VectorA

[BuilderBob25620 (BuilderBob)]

Yes, but my point is that the Part.Velocity itself is the direction. All the other math you’re doing is unnecessary. It’s like adding 2 + 1 - 2 = 1. The two’s are completely unnecessary so why have them? Even if you did need the magnitude it wouldn’t matter, because it will always be zero.

So again, all you really need is Part.Velocity.Unit because it still provides you the direction. Subtracting a parts position from itself doesn’t give you anything because your subtracting the same value. In other words, because each value is the same position you can’t get a direction vector to anywhere since you are already there.

Also, as you mentioned

@ZYTRXS

I’m probaly going to use AssemblyLinearVelocity for other stuff in the future

you really should use BasePart.AssemblyLinearVelocity instead of BasePart | Roblox Creator Documentation, as BasePart.Velocity is deprecated now.

EDIT:
If you want to learn more about vector math you should visit the resources listed below.

On this one go to the Math Operations section.

Vector3

This one will be helpful for understanding the Vector3:Cross and Vector3:Dot functions.

The Ultimate Guide to Vector3:Cross() and Vector3:Dot()

You can use this as a way to fight against silent aim. Take the below code for example: local function GetDirectionAccuracy(CF0,CF1) local Direction = (CF1.Position - CF0.Position).Unit local DotProduct = CF0.LookVector:Dot(Direction) return DotProduct end In this case, imagine CF0 is the CFrame of a user firing a bullet, and CF1 is the CFrame of the victim. The closer the result is to 1, the more likely it was a legit shot. The closer the result is to 0 or -1, then the more likely it wa…

[ZYTRXS (ZYTRIS)]

Personally, using deprecated functions is okay (sometimes it isn’t but most of the time it is).

For example, tick() has miliseconds which very is needed most of the time, os.clock() however only provides seconds. Yes, os.clock is in vanilla lua, but this is roblox so I dont need it, so tick is way more efficient.

Anyways about the ((part.Velocity + Part.Position) - part.Position).Unit, I did that just to be safe, it might use more resources and be a nano second slower but it is what it is I guess. Thanks anyways!

[BuilderBob25620 (BuilderBob)]

@ZYTRXS

I did that just to be safe

What do you mean by this? I’ve explained how you are basically adding 0 to the velocity which just gives you the velocity itself. How is this safer in any way? Doing this doesn’t even add any additional functionality.

@ZYTRXS

tick() has miliseconds which very is needed most of the time, os.clock() however only provides seconds.

For this use the DateTime | Roblox Creator Documentation userdata, as it provides you with milliseconds and many other units of time measurement. For milliseconds use DateTime.now().UnixTimestampMillis. Also, according to the documentation for os | Roblox Creator Documentation, os.clock uses microseconds, which is even more accurate than milliseconds. Below is a table of how much of a second a millisecond and microsecond is.

	Seconds
Milliseconds	0.001
Microseconds	0.000001

As you can see, microseconds is clearly more accurate than milliseconds. os.clock is also specifically meant for benchmarking.

You should not use deprecated methods because newer methods that replace them also add additional functionality and are generally more efficient. Deprecated methods are no longer supported meaning that if they break in the future then all the code you wrote with them will no longer work. So while you can still use deprecated methods it isn’t good practice to nor is it safe.

[Phoenix1205555]

When I was looking at the answer to this post; adding then substracting the position didn’t seem right to me. Not sure if ZYTRIS is doing it any safer despite confusing others.