(Apologies on mobile)
Tutorial on Wiki: UserInputService | Documentation - Roblox Creator Hub
Lost the link to where they replied about this, but I’m sure you can search around.
You’re welcome to still use Mouse for now. But they are heavily discouraging this, hence why in the disclaimer they’re encouraging new developers to use this method.
Ah I see. ill try to use this. Thanks.
Edit: Ive checked it out and couldn’t find any other thing related to something like Mouse.Target, The closest thing ive found was :GetMouseLocation(), which looks up a Vector.2 value. Correct me if im wrong.
That code wouldn’t work because it’d always return true as all strings aren’t nil, you aren’t checking if the Mouse.Target’s name is said string, you’re checking if it exists, which it always will, so this is how you can fix it.
if Mouse.Target then
local Name = Mouse.Target.Name;
if Name == 'Plains' or Name == 'Mountains' or Name == Arctic then
-- do stuff
end
end
EDIT: You’re checking if the string exists, not the name, my bad.
Yeah, I think i’ve done that. Here’s a snippet.
--I broke it into few if statements.
while SelectMap == true then
if Mouse.Target then
if Mouse.Target == "Mountain" then --etc
--CODE
end
end
end
you get the idea.
I think this (your reply) makes things much simpler.
it should be
--I broke it into few if statements.
while SelectMap == true do
if Mouse.Target then
if Mouse.Target == "Mountain" then --etc
--CODE
end
end
end
Mouse.Target is just an object value of what the Player’s mouse is currently hovering over, or nil. You can’t compare it to a string such as ‘Mountain’ because once again, it isn’t a string, you should be using Mouse.Target.Name after checking if Mouse.Target exists.
here’s an actual snippet.
Why are you checking Mouse.Move? That’s an event.
Yeah, good point. But this would be only used once, but if it has something to do preformance wise then I need to recode it.
Take note: IM A MODERATE SCRIPTER REEEEEEe
I’d just remove it entirely. There’s really no point of it being there.
Alright ill try to do so. I think it does add performance wise. (Why did I even add it there, eh scripters makes mistakes.)
There’s still thing’s i didnt get here. Such as the smooth movement of the GUI to the mouse position and if I should use UIS like what @Clueless_Brick said , but as I said:
Correct me if I’m wrong.
I don’t see how UIS would help, have you tried Tweening the GUi?
As he said.
Ive tried but it keeps saying its an TweenInfo Value no idea. Here’s a qoute.
Why don’t you just use Frame:TweenPosition seeing as you aren’t tweening anything else?
Hm. Confused. I’ll still tween some menus and stuff, such as save slots n stuff. I don’t really know what you mean by that.
Apologies for the late reply. Wanted to clear some things up.
For general click, it’s a good idea to use UserInputService and not going through Mouse.Target because the staff have been heavily discouraging this.
Here’s how you would do it:
--Place this in a Localscript under a frame
local UserInputService = game:GetService("UserInputService")
local RunService = game:GetService("RunService")
local gui = script.Parent
local function moveGuiToMouse()
local mouseLocation = UserInputService:GetMouseLocation()
gui.Position = UDim2.fromOffset(mouseLocation.X, mouseLocation.Y)
end
RunService:BindToRenderStep("moveGuiToMouse", 1, moveGuiToMouse)
This will have a frame under your mouse at all times. Source from the Wiki, though be warned that the code there errors immediately when ran due to there only being 2 vectors and not 4 different ones as UDim2 implies. To fix this, replace one of the similar lines with:
gui.Position = Udim2.fromOffset(mouseLocation.X,mouseLocation.Y)
or just copy the code I typed in this reply. The only difference for this is offset.
Alright, now that we’ve got that out of the way: how do we define the target of the Mouse. To do that, we must create a ray to the mouse and whatever is inside the ray the mouse will pickup. In better words, here how @sjr04 explained it to me:
See further replies in the thread if you’re still confused by how this works. But here’s how I wrote my function:
-- InputChanged because the mouse is constantly going to be in movement, hence the conditional statement on the second line
UIS.InputChanged:Connect(function(input,gameProcessed)
if input.UserInputType == Enum.UserInputType.MouseMovement then
local mouse_location = UIS:GetMouseLocation()
local unscaled_ray = camera:ViewportPointToRay(mouse_location.X, mouse_location.Y - 36)
local result = workspace:Raycast(unscaled_ray.Origin, unscaled_ray.Direction*1000)
local target
if result then
target = result.Instance
-- Making sure your Client is alive and existent
if player ~= nil then
if player.Character:FindFirstChild("Humanoid").Health > 0 then
if target:IsA("BasePart") and target.Material == "Wood" then
--Make Gui do stuff by digging into the PlayerGui
end
end
end
end
end
end)
I’m not sure if this code is stable considering that there is no BindToRenderStep, but I’ll leave that up to the experts out there to correct me on this.
Wow this reply turned out way longer than I thought 
Whoa! that is pretty long, I didn’t know this would go more complex than what i thought. ill try to digest this.
I was pretty skeptical and amazed by the complexity on this as well.
I watched a few video tutorials on how to code UserInputService and read up the wiki on how Rays work: I recommend you do the same otherwise this probably won’t make sense.
Hm, I read the Post you brought up and as @sjr04 said, yes. it would be obsolete in the next few years, but i think i should wait until roblox would make this much simpler and better for UIS and I think i would stay with Mouse for now until roblox upgrades the system.