Why to work out lookvector using VectorToWordSpace always require negative 1 on the z plane
For example:
Yes look vector would be equal to negative 1 on the z axis because its facing the opposite of the z axis. So to get it using VectorToWorldSpace it would be
part.CFrame:VectorToWorldSpace(0, 0, -1)
However if it was facing the opposite direction:
wouldn’t it now be
part.CFrame:VectorToWorldSpace(0, 0, 1)
to find the look vector?
VectorToWorldSpace takes a vector relative to a cframe, and converts it to a world space vector
No matter which way the part is facing, Vector3.new(0,0,-1) should always get the same face
Thanks I understand now, however I have another question. If you have a CFrame of a part, what does it do to it if you
CFrame:VectorToWorldSpace(Vector3.new(0, -1, 0))
how come it changes the values of the CFrame on X, Y and Z, not just Y?
What it basically does is add the rotations of the cframe and vector together
Say you have a part tilted 45 degrees upwards and put its cframe into that function, then you plug in vector3.new(0,1,0) (which has a rotation of 90 degrees up)
The thing it returns to you would be a vector at 90+45, or 135 degrees
This would result in a vector like:
(-0.707,0.707,0)
It has values in both the x and y directions because you rotated the vector 45 degrees into the x axis
Thank you so much for the help, so basically the Vector3 in VectorToWorldSpace is all about orientation and not position?
local hit, position = Raycast.new(thruster.Position, thruster.CFrame:vectorToWorldSpace(Vector3.new(0, -1, 0)) * stats.Height.Value)
where ToWorldSpace is used for raycasting module ray (stats.Value is 3)
Yes, its all about orientation
It completely ignores the position, treats the vector3 like a direction, and returns a vector3 direction
Also Im not sure why he didnt just use
-thruster.CFrame.UpVector
Because those two things are the exact same, one is just extremely simpler