Mouse:SetTargetList([Instance] i)

Feature Requests Engine Features
#1

Proposal: Instance Mouse.TargetList, Mouse:SetTargetList(Instance i)

Wouldn’t it make more sense to have Mouse.Target be a descendant of a Instance we can set with SetTargetList?

The constraints: The argument must be a Instance inside of workspace as a child or descendant
The behavior: Everything NOT descended from this instance (not including the instance itself) Is not targeted by the mouse for Mouse.Target. This may save on resources because it allows us to choose if we want a small list of parts to target, AND furthermore it allows us to ignore multiple instances (such as Instances inside the camera, and instances outside the camera, which allows us to ignore both client and server-replicated objects at the same time.)

This deprecates Mouse.TargetFilter, but it gives more functionality to the mouse itself

tl;dr
Remove TargetFilter
Add TargetList
Add :SetTargetList()

4 Likes
#2

Why do people still use Target/TargetFilter?

1 Like
#3

Isn’t the mouse deprecated?

#4

I use Mouse.TargetFilter 24/7 for my first person games where I want the mouse to ignore the arms and still want the arms to appear when zoomed in.

I also use it in games where I place furniture and want the mouse to ignore the furniture it’s placing and only see the ground it’s pointing at.

1 Like
#5

They’re faster than raycasting, right?

#6

For just one ray the difference is negligible.

Why not raycasting?

#7

And if you’re calculating 60 of them a second?

#8

Negligible. You greatly overestimate the performance impact of raycasting once per frame.

1 Like
#9

Because Mouse is so pretty and compact.

Mouse.TargetFilter

Mouse.Target

Mouse.Hit

Mouse.Hit.p

#10

A player in tiny tanks can be expected to be casting 20 bullet rays and 16 tank movement rays per frame. Then all the logic, collision detection, animation, interpolation, and other operations. Lots of people seem to be under the impression that doing a lot of work in lua will lend to performance hits when that’s simply not true. If you know how to write performant code then you can execute loads of operations every frame.

#11

My custom humanoids cast them about 120 times per second for each of the 45 (at most) characters.

On top of that this is done on the server end. Ping remains at 80-90 and there’s no performance hit, so I can confirm raycasting is super cheap.

#12

But wouldn’t it be FPS which is effected by client-side operations and not ping?

#13

The server doesn’t render anything. It just receives and sends data.

If the workload it was given was too heavy it’s send rate would suffer.

#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