No problem!
To explain further, we want to ability for developers to be able to integrate scripts on the server side and provide a simpler use of StarterGui (for example, a server side script under a TextButton would be able to directly listen to a MouseClick) for all developers new and/or experienced. Note that this is an addition to what we provide to all developers now; we aren’t taking the current capabilities away! The only way to do that is to have the server in sync with the client. Therefore, the server manages the StarterGui descendants instead of the client.
1 Like
I see that is very neat, so you are saying that instead of using LocalScripts for GUI manipulation we can now use Scripts instead?
But I thought that you couldn’t use a Script to detect player input in any case (such as Cloning a Gui into PlayerGui with a Script), it also doesn’t have Players.LocalPlayer which (kinda) indicates that it’s not suppose to run for Client stuff.
UserInputService
ContextActionService
Currently, the feature is being rolled out, so not all clients supports this.
Your observation is correct, after the feature is completely rolled out, you could have server scripts in starterGui elements, and those scripts will run on the server-side and can modify each individual GUI.
Also as a part of the observation, there is no concept of Players.LocalPlayer on the server side; however, the scripts which are parented into a TextButton should be able to detect clicks when the feature is completely rolled out to all clients, though again, your observation stands true. The server side script will not have a concept of Players.LocalPlayer nor it will run client side services. They are only meant for server to detect interactions simpler. (Note: that you could have a localscript - running client side things and a script - detecting clicks or running anything that the server needs)
Following is an example where once rollout completes, server side can detect a click without a RemoteEvent
Within the script:
2 Likes
I just wanted to double check, was there any resolution to this? I just tested it again in Studio and it still seems to cause the same issue - from reading above, the first thought I gathered is that we are just recommended to parent them once from ReplicatedStorage instead?
Also, does the fact that this is ResetOnSpawn for each individual ScreenGui rather than StarterGui.ResetPlayerGuiOnSpawn have an impact (from what I was skimming above it seemed to be mainly focused on the latter)
This issue overall isn’t really major to me personally as it was just for organisational purposes, but I just wanted to see what the outcome was
The issue we are discussing above is actually unrelated to your original issue. Your original issue is not a new problem unlike the other stuff we were discussing in the thread. It is hard to solve because it’s not really clear what behaviour would be expected by the developer. The top level folder would be reset so it might be confusing for a developer if the ScreenGuis in that folder did not get reset. I think in an ideal world the default behaviour would be to reset nothing and we would only reset ScreenGuis that had ResetOnSpawn = true.
1 Like
With this new feature with the server being able to detect clicks + other features, will a “Player” parameter be passed down so we know who clicked the button?
(Sorry this might be a bit off-topic)
Hi @NottGuesty!
Unfortunately, on the server-side, there is currently no direct concept of which Player the click was detected from, the detection can only be in context of the Script which is listening to the event.
