print(KartGyro.CFrame.lookVector.magnitude)–>0.37738969922066
According to the wiki: “returns the facing direction (unit vector)”

this makes it sound like the lookVector will always be a unit vector, which is not true in the case of corrupted matrices (which I encountered due to vector magnitude creep).

Honestly, I wouldn’t expect it to maintain a magnitude of one, as there’s no logical reason it should. If anything, it’d be a waste of calculation to always force it to be a unit vector, since it’s assumed a rotation matrix will always be square and unit sized anyway.

It just threw me off since it specifically mentioned on the wiki that it was a unit vector, yet it didn’t live up to it. I kinda understand why they said it that way, as it’s simpler for normal people to understand, yet do we really want a very technical topic like CFrames to be laden down with things meant to make it sound simpler?

Perhaps there should be both a technical page on CFrames, since they break standards, as well as belong to a topic where there’s an abundant number of disagreeing standards, as well as optimization making things that are ‘typical’ not always be 100% true. Like one page for the person who just wants to move and rotate a brick around; another page for people who know what a matrix is, and want to know the specifics.

I’m not sure I’ve ever seen a look vector not be a unit vector. The only time I can imagine this happening is if non-standard transformations are done on the cframe matrix. Do you have a place or model that reliably reproduces this behavior?

If you start doing transformations to rotation matrices to make them non-uniform, I don’t think it should be ROBLOX’s responsibility to make sure the look-vector you get back is in unit form either, since you specifically made the matrix non-uniform yourself. The vector you get back is still technically correct, given your non-uniform matrix.

The wiki remarks on CFrames are statements that hold for uniform matrices, which is 99.9% of the use-cases since most people don’t perform non-standard transformations. I don’t think it should be adjusted for that reason.

The matrix I was making was from the cross product of a vector that I unitized and the lookVector, which since it stated it was a unit vector, I decided not to waste the extra calculation before throwing it into the mash of cross products. Cross products will return a unit vector if they are given two unit vectors, and that being the case, my matrix never should have been corrupted in the first place, but since lookVector was not actually a unit vector like the wiki stated, the size of the lookVector crept over time, further corrupting the matrix since I didn’t unitize it first in my calculations.

No, I don’t think it’s Roblox’s responsibility to make sure it’s in unit form, but since they said it was a unit vector, that led to some false assumptions that caused an error.

|A| x |B| = |C|, is a unit vector if both A and B are unit. C is also at 90* from both A and B, making it possible to form a matrix from three vectors.

I think you got something wrong there, look at the mathematical definition. The magnitude of the result is an indication of the angle between the two vectors:

A = Vector3.new(1, 0, 0).unit --> a unit vector
B = Vector3.new(0.707, 0, 0.707).unit --> a unit vector
C = A:Cross(B)
print(C) --> 0, -0.707106829, 0
print(C.magnitude) --> 0.70710682868958

If A and B are unit vectors, it means the magnitude is equal to sin(theta), theta being the angle between the vectors.

It’s only a unit vector if theta = 90 degrees. If it’s not exactly 90 degrees (basically always) then you still have to do .unit or you’ll get ever so slight creep. (So do it all the time any way)