In the case that the CameraType is anything but Custom or Scriptable and the Camera is being CFramed every step, the ray will be a ray of where the fixed(or whatever camera type you were using) camera would be at
http://wiki.roblox.com/index.php?title=API:Class/Camera/ScreenPointToRay does not mention this as a requirement for the ray to work, so I assume this is a bug. (No, I was not the person who made the code that had a CameraType that was illogical for CFraming the camera manually, but it’s still unexpected for the ray to be something other than a screen ray of the camera’s rendered CFrame. This caused some pretty difficult debugging problems for me.)
tested using Studio’s PlaySolo and Start Server, appeared to have the unusual behavior in both
I think it would be helpful to see an example of this in action. Do you have a sample place we could take a look at that shows this behavior (like just a baseplate with the code you are talking about)?
Here you go: MouseRayBugRepro.rbxl (11.4 KB)
Bonus points: try pressing A and D while testing
Any updates on this? This behaviour is still occurring.
As an additional explanation, changing the depth of the ray change’s the ray’s origin, not it’s length. This means the ray is always at its default length (1 stud).
Might as well bump – I have encountered this issue again. Finding the temporary solution was a waste of my time.
The code provided in the wiki article does not work (as expected):
For anyone else having the issue, currently the way to circumvent this issue is create a new ray using the values returned from the ray from this method:
local Ray1 = Camera:ScreenPointToRay(X, Y)
local Ray2 = Ray.new(Ray1. Origin, Ray1.Direction * Length)
Ran into this issue yesterday and spent almost an hour debugging. Thanks for that fix
The ray length is always 1. The Depth property refers to how far away from the camera the ray starts, not the ray length. The code snippet has a comment that refers to this property but does not explain it in any way.
--This will create a cube facing centered at the origin of the [[Ray]] returned and facing in the same direction. The center of the cube will be one stud in front of the camera.
The reader is required to draw a connection between the magic number
1 in the code and the one stud mentioned in the comment in order to infer this functionality, since it isn’t mentioned.
This thread should be moved to the wiki section if this bug is the one referred to by the OP.