Let’s think about what effect this change will have in your game. Do you insert things into the PlayerGui from the server then then alter your gameplay depending on whether or not those guis exist? If not then it won’t have any effect on you. I’m not asking for everything to be replicated, I’m just asking for removals, and only so that I can replace what’s been removed. Replacing what’s been removed seems more secure than allowing it to stay removed, imo.
Remotes aren’t inherently secure. You still have to sanitize everything that the remote receives, and you can easily apply that sanitization to whatever ugly method you want to use.
I fail to see how using remotes would solve my problem. The remotes and the scripts that handle them would still be removed when the player respawns.
Weeve. Weeve! Please take a moment to think this over.
Earth to Weeve. Even when PlayerGUI parent changes are replicated to the server, nothing changes until the server says so. We can “predict” what exploiters would do to the GUIs just as you do to those remotes, and who said anything about them being unsecure in the first place? Do you think we give someone 1,000,000 credits in-game because a GUI had its parent changed? In the past I’ve used it just to determine when to spawn someone – the first time they join the game, I give them a help GUI (that they can later pull up on their own, but that’s beside the point). Once they close it, I spawn them – it’d be much more convenient to just check for .Changed if gui.Parent == nil (it was destroyed) then spawn them instead of using a remote event.
Again, this isn’t breaking FE – characters already do this, and they’re less of a client thing than the PlayerGui is. Contemplate please.
Why not put the remote someone server side, so that it doesn’t get removed on respawn?
Perhaps I think about code differently than other people, and that this is indeed an opinion thing, in which case, I will cease to post, as I’m not good at all with opinions.
You can assume it. The server has to send over the LocalScripts in the first place, so it already knows what the client is supposed to be doing. If you don’t like assuming, then just ping the client. If the ping isn’t returned within an expected amount of time, then the server knows that something is wrong.
I personally think that UI (or any other core client script) with a persisting thread are cleaner, not to mention more reliable. [/quote]
I agree but this isn’t a viable solution for a free model.
In a free model, which there may be many instances of in a single game, assuming it isn’t a viable solution because then each instance of the model would insert its own script which is just as bad as replicating the effect itself. Pinging isn’t a good solution either because the script that returns the ping will have been destroyed, and even if it isn’t that’s x seconds of the effect not appearing, where x is the timeout.