Hello,
In most all of my projects, I handle Guis on the server.
So I was handling stats, like Hunger, Thirst, Stamina and etc, no client, just full control from server. And now I think that it isn’t good for server.
I want to know is that bad idea to handle Guis and such of things on the Server?
In general, all UI should be handled by the client rather than the server.
If you want to display stats, I would recommend having IntValues (or number values) somewhere that the client can view (e.g. replicated storage), then update the values in these IntValues from the server. Then, you can have the client listen for the .Changed event of these objects in order to detect when the value is changed, so that the UI can then be updated to the value
Usually handling UI on the server is a big no no, and its best to handle it via the client.
Not only is it good for performance, but Im pretty sure it gives you access to a bunch of other options that you dont have with the server, but dont quote me on that lol
That does mean youll have to use remote events if you need something to happen on the server, but it’ll be worth it in the long run.
I cant really think of a good example, but usually the less the server has to run the better, this way there wont be as much lag for the players.
ye ye
What precisely are you doing on the server? If you are doing stuff like keeping track of the players’ hunger, and then the client retrieves it in some way, and displays it, then that’s fine. But if you are making the guis on the server, and sending them to the client, to then display it, then that is not ideal
It is possible to clone gui directly into Player.PlayerGui, and it can be fine for some stuff. Perhaps avoid updating values in there too often from the server
It never should be handled on server, and I mean never.
When you change some property of GuiObject on server, it has to replicate to every single player within that server, so others might see the stats you have. And with this replication, you lose reponsive UI updates
Tweening, changing text, creating frames and etc.
You didn’t understand correctly. Frames, ScrollFrames and such of things that should be handled on the client, were handled by the server, how I did in this situation.
I would recommend all your GUI scripts to be client-side scripts. Having server-side GUI scripts could probably overload the servers, especially if multiple players are in the same server.
If any of the functions you use to render health, stamina, etc. can only be done using server-side scripts you may want to use RemoteFunctions or RemoteEvents to return them.
Player.PlayerGui is a special container, as updates to stuff inside only replicates to that player. It’s a trick used to replicate (random) stuff only to some users
Changing text imo is fine, you replace a RemoteEvent firing with automatic replication. Tweens and creating frames and stuff, not great. Creating the frames can put more load on the server (if it is done often). Tweens will cause the gui object to replicate constantly while the tween is running, and the tween might be choppy on the client because of ping (unless tween has an internal optimization to handle replication better, idk)
Killfeed being laggy is surprising to me as it looks like a simple text update (unless it is more than that?). A simple text update should not be laggy
I also hope that you aren’t handling button clicks and stuff on the server, that would be quite bad
You should avoid creating ui from the server, but there are cases where doing so isn’t terrible
then why am i able to see other people initialized playerguis?
I swear to god you were able to see other PlayerGuis a year or two ago, they mustve updated this
The rule of thumb is that UI should always be handled by the Client, and if you need communication with the Server you can use Remotes.
You can use the Server for UI, but you need to be absolutely sure you understand the implications. An example of this would be iterating all the players to set the state of a UI instead of relying on a remote, as that would decrease the amount of connections and networking required. In that case, you’d have to be absolutely sure your code can handle edge cases like the Player not being completely loaded in, the player leaving, or that UI not existing in their PlayerGui at that time. It’s really a big headache for almost no gain.
pcall should NEVER be used on non async networking tasks.
There is no other way to make sure this runs safely and reliably, you have no guarantees that anything exists or that the player isn’t leaving at that moment. This is why I explicitly advised against doing UI on the server…
So did I lol?
Yelding on server or on client will do the same thing, if the child does not exist then return instead of pcalling
local function forAllPlayers(func: (index: number, player: Player) -> ())
for index, player in next, Players:GetPlayers() do
task.spawn(func, index, player)
end
end
forAllPlayers(function(index, plr)
local GameUI = plr.PlayerGui:WaitForChild("GameGui")
if GameGui then
GameGui.StatusText.Text = text
end
end)
you only use pcall when you are not the one in control of the response and result, when you are the one passing callbacks, you can safely end the function if the GUI does not exist. and pcalling is not needed
so i think it’s bad to handle guis on server, lol.
Should use FindFirstChild(), or WaitForChild() but with a timeout. Currently, in your example code, the is statement “if GameGui then” is redundant because it’ll always run since WaitForChild() will yield, potentially forever, until it finds GameGui. WaitForChild() without a timeout will never return nil
But yes, pcalls should not be used here because the behaviour can easily be handled with FindFirstChild(), or WaitForChild() with a timeout
In @Ransomwavee’s code, it’ll error if plr.PlayerGui is nil (idk if it can be nil?), but if GameGui is nil, then it wont error, it will instead yield infinity (if the player left and the guis were removed), halting the loop in the process, and the function that called forAllPlayers()
If that situation can indeed happen, that is a nasty bug
Regardless, the example was to show to end your functions manually if you can to avoid pcall
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.