Note that the DevHub has been updated since this topic was posted, and this function is no longer written as deprecated, however it is clear that the desire is to someday deprecate it. The feature request for CFrame.lookAt() is still relevant.
According to DevHub documentation, this constructor was deprecated quietly somewhere within a year and a half ago AFAIK. The documentation says This constructor has been deprecated in favor of using CFrame.fromMatrix(), to create a lookVector. However, this is unreasonable, because the code the DevHub provides to do this using that function is too complex for most developers to be able to write without looking it up every single time first.
The lookat constructor is extremely widely used as a convenience tool since this is an operation that developers need to do very very frequently, and in the majority of cases the inability to specify the upvector is not a problem at all. The primary and only advantage this code has over the lookat constructor is that it allows you to specify an upvector, while the disadvantages include being much more complicated and annoying to deal with, and slightly slower.
The obvious thing to do here is either undeprecate and add a third Vector3 argument for upvector to the lookat constructor, or fully deprecate the constructor and make a new helper function: CFrame.lookAt(Vector3 pos, Vector3 target, Vector3 upvector = 0,1,0)
This constructor should not be considered deprecated or written as deprecated in the documentation until this happens because this causes unnecessary confusion and encourages developers to bloat their code with a slower helper function they may never end up replacing. Also, it currently doesnât appear to be hidden from intellisense in Studio, but that better not change until an alternative exists.
Absolutely agree. I do not see why you would deprecate such a widely-known and used constructor, for something much harder to understand - especially for newer developers.
Worst part is the arguments are in reverse so the look at position goes first then the origin of the cframe
and apparently according to this post it has edge cases where a returned CFrame could be invalid:
which is even more confusing.
I literally need to save a file of this script but modified so it accounts for these so I can use it as a module in my games. I shouldnât have to do that.
I mean, Roblox overloaded the CFrame.new constructor so much, it has around 6 overloads. Nonetheless we should at least get a brand new one that isnât an overload like the request proposes:
By the way, this is what was supposed to happen, and why the constructor was marked as deprecated. It got held up thanks to there being some internal discussion at the time on what our standard constructor casing convention should actually be (lookAt vs LookAt).
The documentation has been updated to not say deprecated anymore until someone gets to doing this.
I agree for camelCase and itâll fit consistently since there is CFrame.fromOrientation and CFrame.fromEulerYXZ which camel case. Seeing how lookAt is separately two words just like some of those function names, it fits the camel case.
You might expect CFrame.Angles but no one expects CFrame.FromOrientation so it feels natural to camel case lookAt as well.
I should have specified: Weâre not going and changing the casing. That function in particular was just the point where we stopped and made an explicit decision on how new constructors should be cased going forwards (it will be lowerCamelCase) seeing as there were existing examples of both casings.
As part of that youâll notice that as of recently thereâs now a lowercase constructor for everything including things like Vector3.fromNormalId that were previously only in uppercase.
