So recently I found out you can change PlayerGUI’s from the server because PlayerGUI’s replicate to the server.
I’ve also seen people say you “shouldn’t edit UI from the server instead fire remotes”
My question is why? the PlayerGui is getting replicated to the server anyway, why waste more Network on firing remotes.
Plus depending on the situation it can be a lot more convenient to edit from server script (if the player just bought an item and you want to display a UI you can do it right there from the script instead of making a local script and hooking up remote events)
I agree with you, but I would use LocalScripts to change a UI, if it isn’t an important one that if exploited can cause problems; also, RemoteEvents are util when you need to send informations between client and server and really, I don’t understand why people say to use them just to change a UI when you can easely manage it by a server script.
(Unsure but) If you handle the Gui’s Events on the server side, I’m pretty sure they won’t be replicated across the client side (Maybe if you print them, but it’ll result as a server-sided print)
I understand the waste that RemoteEvents can give sometimes, but you still should implement the sanity checks on the server to confirm that something truly works or not
Adding on to this, it wouldn’t make any difference if you changed the UI’s from the server or client side (As long as it’s not something serious like a Admin Gui), if it’s something like a simple “Stats” frame that shows the Player’s Stats then that’s fine, even if a exploiter were to change their stats with that Frame, their changes would only be made to the client & you can easily implement sanity checks on the server
Yes I know, I’m not usual to use a server script to manage a gui if it isn’t an important gui like ban/unban gui even if you use a local script to manage it you can always check on the server if the sender of the action is an administrator listed inside of a table.
I’m not talking about trusting any of the gui’s or information from the client, simply to update the client UI to changes in PlayerData and things.where
Like the example I gave
-- server script
-- remote event that fires BuyBanana
-- server checks if they can buy banana
-- they can buy banana
-- server then goes into the PlayerGui and changes banana quantity frame from 0 to 1
-- now the client will see that they have another banana
or something like the player being able to name things. I can easily check on the server if a Textbox.Text changed and then run it through TextFilter or do whatever I want then display a success or fail UI. Instead of firing a remote when text changes on the client, picking it up on the server, send back if it was a success, display success/fail UI on the client.
Now that I look at it, you don’t even need local scripts. Because things like MouseButton1Click fire on the server. So you could make a shop that is solely server scripts.
There really is no difference between whether you detect the change on the server and utilize it the way you want it to vs detecting it on the client and telling the server it happened.
However,
The way you’re implying the scalability of it does not make much sense. All network runs under the same pipeline and any changes that the client makes to their screen gui will replicate if the server can see it as well. But don’t you think that the server being able to see all of those changes, all the frames turning visible and invisible, the text changes, position changes, all of that doesn’t come at a cost?
The problem is that the server is able to see those changes. It knows of its existence and will spend networking just to know what’s going on. You’re not going to be utilizing all of those changes from the server’s perspective, so it doesn’t make sense to establish this sync in this first place.
The best way to set up your UI is to locally connect it (have a local script in starter player scripts that parents the UI locally), and then have remotes tell the server what the player wants it to do.
Because you can easily add a UI if the player buys something, without having to send RemoteFunction information back to then client, then do it on the client. Or even see if Text in a Textbox changes and react accordingly on the server.
That doesn’t prove your point still. UI should still be always handled on the client, just because it’s easier to use a bad practice doesn’t mean you should.
How do u then get the player from the server
What if u need the player who specifically clicked something
Don’t you still have to fire a remote to get that player
So what is the use
It’s bad practice because you would be replicating the UI change to everyone, which ma affect network and doesn’t make sense since UI change should be local to the player, not to everyone even if they can’t see it.
It’s better to replicate a change for one player for an UI change rather fir everyone.
