Which is preferred, server access of playergui, or remote events?

For instance a ‘message box’
I have always sent an event from server to client with the text data, and once the client received the data, it gets the gui from replicated storage, and fills in the text, then places it in playergui

However, while working on an inventory system, and having trouble with sending item instance references through the events (for use in ViewportFrames), I tried something different. I had the server find the player from Players service, then locate the playergui, pull the viewportframe from serverstorage, place the server side created item into the viewport frame, and then parent them to playergui.

So… for something simple such as a message box, which really only has the one gui and some text
is it better to use a remote event to send the text and have the client display the message box
or simply to have the server access the playergui and display the message box

I am asking for a friend… o.o No, but seriously, I am asking because I know that the remote events have data limits (not that I would ever come close to reaching those limits), but which would be the more … ‘correct’ … way of doing this?

3 Likes

I think it’s better for your client to create it, otherwise when it comes to closing the message box, you’d either have to send an event to the server asking it to remove it, resulting in a delay between clicking and seeing the box disappear, or you’ll get rid of it only on the client and the server would still think it’s there.

3 Likes

The client should always handle all UI related stuff. If an element or instance needs to be accessed by the client, it should be accessible to the client (ReplicatedStorage would be your best bet here). You’d be nowhere near the limits that RemoteEvents have, so you needn’t worry about them.

5 Likes

The client should be responsible for everything that is on their machine like managing all their Gui’s and input ect. The server shouldn’t get directly involved in this sort of stuff because it is a waste of server resources that are better spend doing more critical things. Using the server to directly handle the clients Gui’s is pointless because either way you do it the Guis are still exploitable.

The server should be the place where you do all your critical tasks in your game like saving data or verifying things that come from the client.

In your use case I think it would be best if you try and handle most of it on the client and only use the server as a place to verify things when needed. Remember anything on the client can be exploited no matter how much protection you put in place. If you want to edit a players gui from the server it is best to use a RemoteEvent rather than directly handling it from the server.

3 Likes

As for closing the gui, the gui element has its own local script included which handles closing (a simple non blocking message box, really doesn’t need to let the server know its being closed)

I would agree, it seems more logical for the client to handle its own things… however,
lets assume there are several gui elements needed to be displayed at various times in a game.
If they (or anything else for that matter) is put into replicated storage, does the client actually commit those things to memory as soon as it loads, and they remain in memory? Or does it only load replicated storage items when it needs to display, or use them?

Because I would think if replicated storage is committed to memory, even if you might not ever see the display, that would make having the server store the guis server side, and only pass them to the player gui when needed.

This would also be something to know for instances where scenery to be displayed on the client alone, should be all kept in replicated storage (the whole set of scenery) or kept in server storage, and only sent when needed.

1 Like

If something is going to be used on the client it is best to store that thing where the client can directly access it like ReplicatedStorage. Storing something in ServerStorage that is only going to be used on the client forces you do to unnecessary network calls wasting server resources.

The server also has memory so storing stuff there that is going to only be used on the client is wasting the servers memory. With performance and memory gains you need to have a happy balance between work-ability/readability and whether what you are doing is actually improving the performance by a noticeable amount.

For interface changes and changes specific to a single client you should only involve the server when it is absolutely necessary to do so. If something can be handled on the client like text changes then do so because these sorts of things don’t really matter if they are exploited. Once it is time for the server to do whatever it needs to do then do all the necessary checks.

1 Like

Really good advice. I appreciate the response.

1 Like