✓ ANSWER ACCEPTED

Using GetMouse() instead of ClickDetector?

Asked May 2, 2016653 views2 answers

In the past I've had some trouble with ClickDetectors working correctly with filtering enabled. The problem I was having is that the function using the ClickDetector wasn't returning the player. Now this was about three months ago and I haven't touched a ClickDetector since. Here's what the script looked like from my memory,

game-->Workspace-->Part-->ClickDetector,Script

script.Parent.MouseClick:connect(function(plr)
    plr:FindFirstChild("Sound"):Play()--error
end)

Now let's say this works now, let me ask my question. Would using something like the following work?

--Local Script in starter pack,
local plr = game.Players.LocalPlayer
local mouse = plr:GetMouse()

mouse.Button1Down:connect(function()--Button1Down might be the wrong call, I don't remember. You get the point.
    local target = mouse.Target
    if not target then return end
    if target.Name == "PlaySound58360" then
        plr.PlaySound58360:Play()
    end
end)

Now sure this might be a bit more complicated, but it works the same. So my real question finally is, which one is better? Does getting the players mouse cause lag? Which one would be better and why.

Thank you.

AnonymousMay 2, 2016Edited May 2, 2016

2 answers

✓ Accepted answer

Circumstantial

This is probably more concerning the circumstance and personal preference of the developer, than efficiency.

Personal opinion

Now my personal opinion would be using mouse.Target instead of a click detector, just because I feel like there's more you can do with it. And to answer one of your questions, getting the player's mouse and/or working with it, will not result in any performance deficiencies.

"What about the input feedback ClickDetectors provide?"

As you've probably noticed, whenever you hover your mouse above an object with a ClickDetector inside, it'll display that icon replacing that of your default mouse's, with a hand pointing and finger (indicating selection).

This can be nice if you want the player to know if whatever object their mouse is over can register user input - or it could be bad if you decide you don't like the look of the icon.

Changing the mouse appearance?

This again brings me back to using the Target property of the mouse, instead of a click detector, since you can edit the appearance of the mouse using the Icon property. Here's an example:

local Player = game:GetService("Players")
local Mouse = Player:GetMouse()

-- Whenever the mouse moves, check to see if it's hovering over the object that can support user input.
Mouse.Move:connect(function()
	if Mouse.Target == Object then
		Mouse.Icon = "Selected icon image" -- Change the icon to it's selected state
	else
		Mouse.Icon = "Non-selected icon image" -- Change it to it's non-selected state
	end
end)

-- Continue to work with whatever happens when the button is clicked
Mouse.Button1Down:connect(function()
end)

And that's just my take on all this, but I just find working directly with the mouse easier. In terms of what's more efficient, it really doesn't matter. Hope this helped, let me know if you have any questions.

AnonymousMay 4, 2016Permalink

2 comments

Thank you.

AnonymousMay 4, 2016#

Great answer :3

AnonymousDec 16, 2016#

Because you are activating a sound contained on the client, I'd suggest using the click detector. When filtering is enabled and you use a click detector, it doesn't register on the server but it does register on the client side. However, this means that you need to specifically isolate the click detector on the client side. Here's an example:

local cd = game.Workspace:FindFirstChild("PlaySound58360"):WaitForChild("ClickDetector")

cd.MouseClick:connect(function(plr)
if plr == game.Players.LocalPlayer then
game.Players.LocalPlayer["PlaySound58360"]:Play()
end
end)

Most of this is just preference and convenience, it's ultimately up to you.

AnonymousMay 2, 2016Edited May 2, 2016Permalink

2 comments

Thanks for your input. I would still like to see the rest of the community's opinion as well. And I see what you're saying.

AnonymousMay 2, 2016#

Happy to assist! :)

AnonymousMay 2, 2016#

This discussion is preserved as it was. New answers, comments, and votes are closed.