A color guide pops up where you can choose your skin color.
Sadly, I don’t know anything about scripting, and the scripter that made this for me isn’t available.
THE PROBLEM:
This ‘change skin color’ button appears on every screen of every player in the server when someone enters a booth. I tried to look around on the developer forum, but, sadly, my English isn’t that good, and I’m having a pretty hard time using the right search terms.
Is there anyone who happens to know how to make this button appear only on the screen of the person stepping into the booth?
If you know nothing about scripting, then I can’t really tell you what to do
You probably won’t get this next part but
I assume the scripter who made it used a part with a .Touched event at the doors entrance and used a local script to connect to when it is touched. The problem is that if anything touches it, it would open the gui.
This could be fixed by having a server script detect touch, and when a player touches it, it could fire an RE to the client giving them the GUI. It could get the client with the hit argument from the touched event and use game:GetService(“Players”):GetPlayerFromCharacter(hit.Parent)
You can still use a LocalScript for this and verify that whatever touched the brick was a descendant of the LocalPlayer’s character. The point here is verification. The server shouldn’t be detecting for touch in this scenario at all, there’s no reason to get the server involved. The server has limited memory better spent doing other important tasks.
In the LocalScript, just add that same line of verification you proposed be done.
local Players = game:GetService("Players")
local LocalPlayer = Players.LocalPlayer
-- Part needs to be defined or changed to the long form somewhere
Part.Touched:Connect(function (hit)
local player = Players:GetPlayerFromCharacter(hit.Parent)
if player == LocalPlayer then
-- Do code
end
end)
I mean why use 50 client’s cpus for each event instead of 1 server’s
Pretty sure there was some RDC doc talking about how about 60% of users play on mobile, and if i’m not mistaken roblox servers are pretty good + new vm
@Deemsx That depends on what specifically you’re looking for. Are you looking only to show the Gui based on a player’s position - in or outside of the booth? I’d suggest changing up the strategy if this is the case as Touched wouldn’t exactly be reliable for it. I’m not sure of your specific use case.
If you’re looking to do player-position based interaction, a suitable alternative would be the use of Region3 and detecting if a player is within a certain hitbox of that region. You can then go ahead and set the visibility based on if the player is in or not.
@azahid1 I’m not sure what you’re meaning to say here. This is completely client-side iteraction. The server has no purpose getting involved. Using “50 client CPUs”, I don’t know what this means at all nor is it relevant. Server-Client interactions are one entity, not “50”. Clients can run things faster than the server in any circumstance and it’s not like other clients get bogged down by one’s connections.
The interactions are being handled by the client so all the connections should be connected there as well. When you get the server involved, you’re now introducing the server and remote traffic as a bottleneck to your code, instead of only the client’s computer itself. It’s also bad practice in a way. The server uses more memory to process physics and the like to register touches.
Any unimportant touches that are used for simple things, such as Guis, should be handled from the client. A new VM and better servers doesn’t mean the practice and performance problems go away; don’t bank on that as a fallback.
I explained this almost wholly in my post. The server has virtually no reason to get involved and spend memory computing when this is purely a client-side thing. In addition, you’re now involving network traffic by handling it from the server.
Handling the touch and Gui visibility completely on the client means that you aren’t presenting unnecessary overhead in your codebase. The server can spend time doing other tasks and the client can handle everything right there and then.
Don’t think of it collectively as clients versus the server. Think one client and one server. Who’s going to have the upper hand? The client, in all circumstances, unless your PC has terrible specs. Leaving clients in charge of things that only affect them is a better solution than involving the whole server.
The server only needs to compute touches in the case that there’s an important interaction that the client can’t be trusted with or that touch needs to be globally recognised. A touch brick that only serves to show a Gui does not need server involvement.
That’s unrelated to the point I’m making. I’m talking solely about showing the Gui, not about its actual functionality. Propagating changes to the server requires a remote, yes, but showing the Gui based on if a player touched a brick or is in range of an area does not.
