Mouse:SetTargetList([Instance] i)

Feature Requests Engine Features
#14

Why use raycasting to ignore things? Doesn’t the mouse ignore feature work just as well for his purpsoses?

#15

Oops, I misread sorry. I thought this was client side.

#16

Uh… no. That’s the whole point of this feature request. Raycasting currently supports an ignore list. No reason reinvent the wheel, right?

#17

Exactly. We can just copy+paste that wheel into Mouse.TargetFilter :slight_smile:

#18

What is the benefit of using Target/TargetFilter over raycasting? There is no point in upgrading a weaker API just to put it on par with an existing API.

#19

I’m confused. Lets say I’m trying to put a part where the user clicked while ignoring a glass barrier between the location and the user. If you dont use targetfilter, the part gets placed on the glass itself instead of beyond it. The mouse instance can do that super easily and simply. How would you do it with raycasting? I’m not that great with rays so I’m genuinely interested.

#20 
hitPart, hitPoint = workspace:FindPartOnRayWithIgnoreList(
   Ray.new(
      mouse.UnitRay.Origin,
      mouse.UnitRay.Direction*999
   ),
   { ignorePart, ignoreModel, ignoreFolder, ignoreOtherThing, ... }
)

Raycasting can do what you want and more. There is no sense in upgrading an old API to put it on par with an existing API.

1 Like
#21

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.

#22

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.

#23

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.

#24

Not sure what you’re asking

#25

I’m saying if Mouse.Hit just works the same way as raycasting does, why not use that? It’s simpler.

#26

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.

#27

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().

#28

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:

https://github.com/Sleitnick/TeamCrazyGameFramework/blob/master/src/game/StarterPlayer/StarterPlayerScripts/Main.Controls.Mouse.module.lua

1 Like
Make Mouse.TargetFilter a list instead of a single Instance
#29

This link is not working anymore.
I, like many others, suffer from the Mouse.TargetFilter limitation.
Any workaround?

#30

Mouse is 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
#31

Sorry, but so far, nothing is mentioned in the official documentation that Mouse is deprecated. Is it deprecated?

#32

It’s not deprecated, but it has been superseded by other mouse methods.

image
image1101×380 33 KB

2 Likes
#33

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 UserInputService + 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.

4 Likes