Not sure what this means. LocalScripts don’t execute in workspace unless they’re a descendant of a physics assembly that has network ownership to a client. The approach I had suggested would be to bind to Humanoid.Seated from a LocalScript in StarterCharacterScripts. The only issue is validating that currentSeatPart is actually a rocket seat.
did he ever say he put the local script in workspace and not the rocket?
GUI’s are inherently client sided things. There’s nothing preventing an exploiter from just manually opening the GUI themselves. There’s no avenue of attack opened up by letting a LocalScript show or hide a GUI. Server should act as a validation filter for any replicated side effects. Nothing is replicated in this situation as it’s just showing/hiding the GUI on the same client the logic is executing on.
I wonder what TCG will reply with
im curious
That literally just slipped my mind
OP, you should probably clone the GUI for better protection.
its a gui that teleports you to a diffeerent position. how much protection do i need?
why would you clone the gui just to enable or disable wtf…
It depends whether the location matters in the game.
not as much as TCG says you need
no. imagine rocket gets to the top of its flight. the gui teleports you back to spawn. literally nothing else
1 Like
??? He literally just said he parents the rocket to workspace. If the localscript is in the rocket then that means it’s becoming a descendant of workspace. Please stop replying if all you’re going to contribute is arguing about total non-issues.
This is for enhanced security. If you put the panel in, say, ServerStorage, the client can’t access it. Imagine an Admin Panel; you wouldn’t want someone to gain access to it
I didn’t know the local script was in the rocket
also I’m not purposefully arguing
Oh, alright. It shouldn’t matter then, enabling/disabling is fine.
Infact, it’ll make it easier if you just handle things on the client like @InfinityDesign said
There’s no real point to doing this. An exploiter seeing a gui or not does not cause replication of side effects to other clients. Failing to server sanity check any replicated side effects triggered from remote events in this GUI will allow exploiters to cause problems on other clients no matter if the GUI is hidden or not.
Well, as OP stated, the GUI doesn’t really matter.
You should be handling the repositioning of the character on the server regardless. A button click in the GUI should fire a remote event requesting that the server teleport the character to wherever it needs to. The server should verify this character exists and is allowed to be teleported. One check could be to make sure they’re currently sitting in a rocket seat, Humanoid.SeatPart is a good way of doing that.