I was just messing around with interfaces when I came across this strange behavior that I’d believe shouldn’t be happening.
I have this path set in the server; however, if I show you the code…
game.Players.PlayerAdded:Connect(function(Player)
local Leaderstats = Instance.new("Folder")
Leaderstats.Name = "leaderstats"
local newValue = Instance.new("IntValue")
newValue.Name = "Clicks"
newValue.Parent = Leaderstats
Leaderstats.Parent = Player
local newInterface = script.Interface:Clone()
newInterface.Parent = Player.PlayerGui
newInterface.TextButton.MouseButton1Up:Connect(function()
newValue.Value = newValue.Value + 1
end)
end)
As you can see, the interface is being replicated from the server to the PlayerGui. Sure, that’s normal; however, with this cloned interface I am able to access its descendants and interact with them through the server. As shown here, I have added a textbutton to the ScreenGui and been able to use a MouseButton1Up event to trigger a change in stats. A sample place can be seen here.
I have no need to, it’s just a simple MouseButton1Up. I’m just confused as to why I’m able to use it through the server. I’m also confused as to how noone has noticed this previously.
Yes but I wonder if this is a mistake with the way that they had done the gui signals like maybe they did it so you can’t connect on server for MouseButton1Down but I’m not to sure about up… But it’d be nice to see if their are any passed through arguments if a player object comes up I’m going to just assume that it would be something to do with a potential new update.
Tbh I would see if any other connected function that does roughly the same thing works as well.
Not a bug but not something you should do either. Regardless of whether this is intended or not, don’t do it - it’s bad practice.
The Gui exists on the server when you clone it and the method MouseButton1Up is not a client-only event. I would assume that the server being able to receive client input like this has to do with the Gui backend facilitating that interaction.
Yeah, it looks like filtering enabled is acting as expected. Server puts something in the client’s gui and both know about it. The unexpected bit is that the mouseButton1 event can fire from the client to server. It is probably made that way to make legacy gui continue working, or to allow billboard gui’s to work. It’s an odd feature that is secretly networked to be called from the client.
It is a bad practice. Listening to client events from the server is only done for backwards compatibility, and any place where you would use it in a server script would be better served with a more modern solution utilising remote events and/or local scripts.
The contents of the PlayerGui exist on the server now and get replicated to the client as of a change that happened a while ago. Several events on GuiObject are marked as replicating to the server (they only actually send if they’re hooked by server scripts). There are several events that do not currently replicate, like Activated, which will probably change in the future.
There’s no FE issue here - the objects are created on the server. If the client makes any local changes or adds or deletes objects, they won’t replicate back, as is normal for FE. The one exception is the user input events, which replicate from client to server. These events should be treated like any other RemoteEvent, in that they’re a potential vector for exploiters to break your gameplay mechanics or DoS your game, and that their parameters can be maliciously crafted by exploited clients.
Note that the UI will only replicate from the server to the client of the player who owns that PlayerGui. It will not replicate to the other players on the server.
