I’m making an inventory Gui and when you click on it an item a Gui pops up telling you info. I’m trying to get the Gui to go to the mouse but its not working.
If the item that the player has to click on in the inventory gui happens to be a button (TextButton
or ImageButton
), you can use the GuiButton.Activated
event and then connect it to a function.
The first parameter that’s returned by that event is an InputObject
, which has a Position
property. The first two values of that (the X
and Y
coordinates) refer to the horizonal and vertical positions on the screen that the player clicked on.
As long as the ScreenGui
that is containing all of those GuiObjects has its IgnoreGuiInset
property turned off, you can set the offset values of the GuiObject.Position
for that “info” Frame / TextLabel / etc. to those X
and Y
coordinates.
Here’s a basic example which would work on an individual button (if you wanted it to work for multiple buttons, consider creating a loop that connects the Activated
event for each button to the function. Further changes would need to be made to ensure that it displays the correct info based on the button that was pressed, but again, this is just an example):
Example
-- Example LocalScript
local ScreenGui = script.Parent
local Frame = ScreenGui:WaitForChild("Frame")
local GuiButton = Frame:WaitForChild("TextButton")
local function createInfoFrame(inputObject)
local position = inputObject.Position
local touchPositionX = position.X
local touchPositionY = position.Y
print(position)
local exampleInfoFrame = Instance.new("Frame")
exampleInfoFrame.AnchorPoint = Vector2.new(0.5, 0.5)
exampleInfoFrame.Size = UDim2.new(0.05, 0, 0.05, 0)
exampleInfoFrame.BackgroundColor3 = Color3.new(0, 1, 0)
exampleInfoFrame.Position = UDim2.new(0, touchPositionX, 0, touchPositionY)
exampleInfoFrame.Parent = ScreenGui
end
GuiButton.Activated:Connect(createInfoFrame)
wouldn’t it just be simpler to do:
local Mouse = plr:GetMouse()
Button.Activated:Connect(function()
-- code code code
Button.Position = Mouse.Position
end)
i don’t really see as to why this wouldn’t work, correct me if i’m wrong though
There isn’t a Position
property for the Mouse
but there are X
and Y
properties that reference its current position; there’s also UserInputService:GetMouseLocation()
to retrieve the Vector2
that contains both of the coordinates simultaneously.
However, here’s what the documentation for the X
and Y
properties happens to recommend in adjacent situations where the mouse position needs to be referenced:
When detecting changes in the mouse’s position on-screen, it is recommended that you use ContextActionService:BindAction() with Enum.UserInputType.MouseMovement or UserInputService.InputChanged, which both describe the position of the mouse using the Position (a Vector3) of an InputObject, instead of using this and related properties.
(*I’m aware that is more in the context of detecting changes in the mouse position, which is not exactly the use case for OP, but notice how it’s referring to services, events, etc. that are more in line with supporting multiple input types instead of specifically a computer mouse.)
Although those are viable options, given that the InputObject
and the on-screen position where the input occurred are already provided through the event, it seems a bit wasteful to make an additional call to get the mouse and reference its Position
.
TL;DR
Either UserInputService:GetMouseLocation()
or retrieving the first two axes of InputObject.Position
would work for this use case at this current moment in time (even for other types of input, such as Touch
on touch-screens), but the latter is recommended because:
-
The
InputObject
is already provided by theActivated
event (so you might as well use it). -
It’s much more likely to remain compatible into the future with multiple
UserInputTypes
, given thatInputObjects
were designed around that, versus theMouse
object being originally designed to support computer mice in particular.
Even if it might be unlikely for the mouse-related properties and methods to be deprecated in the future, relying on the InputObject
better guarantees that work like this is future-proofed, given how the InputObject
is more versatile for supporting different types of inputs.
Sorry, but y’all came when I went to bed so I wasn’t able to reply. I found the issue though. I was setting the frames position whens its parent frame was only half of the screen.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.