Local scripts could take off some stress on the server. Although, global scripts are easier and won’t cause that many problems with the server as long as it is pretty simple. It honestly depends on what you’re doing.
To add onto that, I would make most of it local sided if you’d want to go the extra mile. Use remote events for global events, like buying an item.
There was even gui tween in the server script (so I think, its totaly ineffective).
Agreed with what @Twisted12Gaming is saying. Let the clients handle the shop GUI, and send any buy/sell requests through remote events. The server should then handle the actual transaction to prevent cheating.
It shouldn’t be that bad for the server and make it that laggy. Although, if the server is already stressed a lot from other game functions, then I would make the client handle most of the GUI.
This isn’t a 1-10 kind of question to begin with; and to answer it at all, no, it’s really not.
Related:
For GUIS you should use localscripts. No need to do a poll.
Scripts won’t work on a player’s PlayerGui. Also, if it’s something that has to do with clicking a button, it has to be the client sending a remote. The activated event on TextButtons only fire on the client, the client should also be handling stuff in the PlayerGui. Even though the server can see a player’s PlayerGui, the server should never ever be touching it.
Nope, scripts will work there as if every event will fire remote.
Server scripts only run if they are a descendant of the Workspace, ServerScriptService or a Backpack. If they do work in the PlayerGui, then that is most probably a bug, and will probably be fixed in the future.
You should only use Local scripts for guis no matter what. Server scripts are unnecessary. The only time a server script comes to play is through a remote event where the server communicates to a local script, but the server script would be located in the server script service or the workspace, never the starter gui.
It is not a bug. It’s intended. It’s been like this for a long time.
Hmm, interesting, it isn’t documented on the Roblox Developer Hub,
I think, that its because its not recomended, but roblox dont want to break old games. Personally, I didn’t know about it, until the guy used it.
Then it’s basically deprecated, and should not be used
Edit: also, if roblox goes against this, it’s probably for a good reason, they created the API and know the internals and what should and shouldn’t be done
It is a bug. StarterGui elements are cloned locally into PlayerGui, so a script is cloned locally. That shouldn’t even work lol
They aren’t cloned locally, they are cloned and can be seen by the server, however, changes the client makes don’t replicate, the server actually clones them.
Edit: I think they used to be cloned locally, but now, they are cloned on the server, I really don’t see a point in doing that if it would lead to bad practices, as you should never access the PlayerGui on the server
No, it is not proper use. GUIs are client-side and should ONLY use a LocalScript. Just because you can do something, doesn’t mean you should. Using RemoteEvents is not hard, and it’s something every single developer needs to be able to do in order to do anything.
Ik how to use remote events, I was just asking, bec I didnt saw it earlier and my friend want to rate his new scripter.
Using a server script in GUIs is so far the worst idea ever because first of all, there will be lots of vulnerabilities, especially in games that saves. Some exploiters might take advantage of the server scripts from the interface and they might even steal the code as well, leading to even huge problems.
I’d suggest he should use local scripts instead for the interfaces and the server scripts for the main functionality of the game into safe places, such as ServerScriptService. If you want to commute between them, simply use RemoteEvent or RemoteFunction, which is actually not that difficult after you get used to it.
I hope you two will do a really great job.
Good luck and have a nice day.