But if the direction is where you click, won’t it just be aiming at a point on the barrier instead of whatever is betond the barrier? I’ll try and make a place to demonstrate what I mean.
Direction is a direction, not a position. It is relative to the origin and doesn’t change depending on if there is or isn’t a target. It’s a unit ray, so the direction always has a length of 1.
Ah, okay. I didn’t realize mouse.UnitRay started from the camera. For some reason I was visualizing it starting from the person. But do all the mouse properties use the same way of calculating where the mouse.Hit position is, it just can’t take a table for TargetFilter.
Slightly more on-topic, the suggestion to remove TargetFilter would make Mouse.Hit annoying to work with, since you would have to define all instances you want to be able to click on, instead of just putting the few you didn’t want to be able to click on in a folder.
Not sure what you’re asking
I’m saying if Mouse.Hit just works the same way as raycasting does, why not use that? It’s simpler.
Because it doesn’t work the same way. Raycasting has an ignore list. The suggestion is to make it work the same way, which is pointless when there is an existing API that is more powerful than the mouse could ever be.
Mouse.Hit can ignore one object and it’s descendants just not a list, which is strange. Anyways I thought the suggestion was to make it work with the opposite of an ignore list, it just ignores everything unless you define it as something it can target.
Edit: The documentation for Mouse.UnitRay says “If this ray was extended it would eventually reach the point of Hit.” which makes me think that Mouse.Hit does the exact same thing as :FindPartOnRay().
I have a Mouse module that behaves similar to the original Mouse object. I use it as a replacement for the deprecated Mouse. It allows you to set a table of instances to ignore.
Take a look at the Project method. It uses raycasting to get information that the old mouse object would spit out. What’s nice about this is that it only raycasts on demand. When you’re not asking it to project, no raycasting will occur.
Here’s the code:
This link is not working anymore.
I, like many others, suffer from the
deprecated discouraged by Roblox. I prefer raycasting to Mouse, because it gives more customization. You can use
UserInputService:GetMouseLocation() to get the mouse position,
Camera:ViewportPointToRay() to get a Ray from the mouse position, and
workspace:Raycast() to raycast from that ray. That way you can use RaycastParams to have specific parts to ignore, like
Mouse.TargetFilter is supposed to do.
EDIT: Here is the code:
local mouseRaycastParams = RaycastParams.new() local function getMouseHit() local mousePos = userInputServ:GetMouseLocation() local unitRay = camera:ViewportPointToRay(mousePos.X, mousePos.Y) return workspace:Raycast(unitRay.Origin, unitRay.Direction * 250, mouseRaycastParams) end
Sorry, but so far, nothing is mentioned in the official documentation that Mouse is deprecated. Is it deprecated?
As noted above, it’s not deprecated, but it’s discouraged. Consider what happens when the person playing your game is on a Phone for instance (which a very large portion of Roblox’ player base does): What should
mouse.Target do then? Using
Raycast you can design exactly the behavior you want rather than the Mouse instance trying to hack together some behavior for you that makes touch input still kind-of work.