Currently if a server adds a localscript to the PlayerGui and the client removes it the script will stay there on the server and the server won’t know it’s gone. The problem is that the client removes these scripts when it resets the PlayerGui and, because the scripts are gone, it has no way of notifying the server so that it can replace the script.
Isn’t that what’s supposed to happen? or are you saying that the client can add and it replicates, but it can’t remove and have it replicate, making a large amount of dead instances server side?
If the client removes something it doesn’t replicate. It should.
But if it replicated, that would break the whole point of Filtering enabled, PlayerGui is owned by the client, not the server, so you don’t ‘want’ it to replicate, otherwise hackers could delete everything in it/mess with it
Oh, I didn’t know about this.
The only reason why I run arbitrary local code on clients is so I can make things run smoothly on the original client with no latency (Such as a gun shooting an object), notify the server, then tell the other clients to make that same change (So that others can see where the gun shot, though with a 2-connection latency)
But at the same time, I think this behavior should be expected of FilteringEnabled. FE is simply doing its job by not replicating.
A good solution would be either to add it to Debris, or to make the script invoke to the server to delete itself.
[quote] Oh, I didn’t know about this.
The only reason why I run arbitrary local code on clients is so I can make things run smoothly on the original client with no latency (Such as a gun shooting an object), notify the server, then tell the other clients to make that same change (So that others can see where the gun shot, though with a 2-connection latency)
But at the same time, I think this behavior should be expected of FilteringEnabled. FE is simply doing its job by not replicating.
A good solution would be either to add it to Debris, or to make the script invoke to the server to delete itself. [/quote]
Best would be to use a remote, and to ask the server to delete it as well :DDD
A playergui is something that only affects a single client. The server can read from it but it can’t do anything with the server unless the server is intentionally using the data in there.
Alternatively, the PlayerGui could be fixed to reset on the server as well when the character respawns.
[quote] Oh, I didn’t know about this.
The only reason why I run arbitrary local code on clients is so I can make things run smoothly on the original client with no latency (Such as a gun shooting an object), notify the server, then tell the other clients to make that same change (So that others can see where the gun shot, though with a 2-connection latency)
But at the same time, I think this behavior should be expected of FilteringEnabled. FE is simply doing its job by not replicating.
A good solution would be either to add it to Debris, or to make the script invoke to the server to delete itself. [/quote]
Best would be to use a remote, and to ask the server to delete it as well :DDD[/quote]
That is not the best use because it requires the objects to exist on the server initially, which is unnecessary and bothersome, and as I said the scripts get reset so the server can’t know if they exist on the client or not without some ugly workaround.
The playergui only ever contains things that appear locally on that specific client. The client can remove these locally with FE on or off. I’m asking that removing be replicated to the server so that the behavior of the PlayerGui resetting on death can work properly.
I have to ask… why does the server need to know about anything in PlayerGui? I was just wondering because I’ve never needed/ran into this issue before, and I’ve scripted since I can remember being on roblox, and I have a huge FE game…?
I put a script into the playergui to render an effect locally
The character dies and the script disappears so the effect stops working
I need to replace the script but I can’t know that I need to do that because the server doesn’t know that the script is gone
Well I think that in general this is a bad practice. I personally don’t like any script cloning from server “to make something happen” either.
Why don’t you create a small module - possibly driven by events - which allows the server to call effects on the client. If the client finishes the effect, it will push an event to the server telling that it’s done.
Also, this behaviour is default for FE, and it should stay that way.
Use a module script and require it by the local script. They continue working even after the character has died, so you only need to require it once in a game. I don’t know if they continue to work after the module itself has been deleted, so it would be best to place it somewhere where it won’t.
Let’s think about what the PlayerGui is for. It’s for one client and the things inside it don’t affect the server in any way. Anything malicious that the client could do with that is already possible now because they only affect the client. If anything, allowing them to replicate would increase security because you would know when the client is removing your guis, scripts, etc…
You found your own solution. This is scriptable.
Even so, you can just have the server ping the client via remote to check if it’s still working correctly.
You found your own solution. This is scriptable.[/quote]
How would I know if the client hasn’t locally set ResetPlayerGuiOnSpawn?
And what script would return the ping? The one that got destroyed along with my effect script? Not to mention the second of the effects not existing.
I think the point Ethan is trying to make is that since the PlayerGui is a client thing, the client should have complete control over it just as it does character physics. That makes enough sense to me, regardless of whether it’s possible or not to script it on your own.
The issue is it breaks the whole FE model to allow the client to tell the server what to do, regardless if it affects other players or not, in my personal opinion, there’s no reason at all that the server should ever even care, or touch things inside PlayerGui, to the point I would support roblox making it a locked object on the Server, for FE enabled games
That being said, What you want to do is not best done by trying to break the FE model, you can probably find a way to use Remotes to accomplish the same feat in a much more elegant factor, and if your server’s behavior depends on knowing what is in the PlayerGui, it’s a security flaw to allow the client to tell the server what’s in the PlayerGui in the first place, as they could alter the behavior of the server to be what the exploiter wants.
That’s happening regardless of whether the server sees what’s in the PlayerGui or if you’re using remotes to tell it. Code that fires remote is local – it can be modified by the exploiter and they can fire the remotes whenever they want. Having items parented by the server to a PlayerGui isn’t any more of a security risk than using a GUI normally.
[quote=Weeve]The issue is it breaks the whole FE model to allow the client to tell the server what to do[/quote] The client isn’t telling the server to do anything – the only way that’s happening is if you tell your server script which monitors the PlayerGui to do something, because when the local script deletes the baseplate it certainly isn’t being replicated to everyone else. Again, this is no more of a security risk than conventional usage of GUIs.
There is absolutely zero security risk. The client already has full control over the PlayerGui. The server being aware of what it parents to the PlayerGui isn’t a security risk either – nothing is happening unless your server script wills it. And this isn’t “breaking the whole FE model” – the server already can see the objects it parents to the PlayerGui itself, and all that’s being done is ensuring that parent changes are replicated to the server – it’s no different than the client replicating parent changes of objects contained in the character (which it does currently).
It’s a risk because it’s assumed the reason he wants the server to know about what’s in the PlayerGui is because it will affect server behavior in some way, The reason Remotes are different is because remotes are designed to make it easy to cleanse input, being that one remote can only do one task, of course you can also do remotes stupidly, but there’s clear warnings against that, in the case of PlayerGui replicating, what will happen is that people will end up using it as an ‘easy’ way to talk back and forth to the server, without ‘having’ to use Remotes, and as there is no warnings on cleansing input, they will end up coding it in ways that are easy to exploit
I’m not sure how your games are coded, but I plan on all of my remotes being fireable at any time from the client, and with any values that a potential exploiter would inject into them, that’s why I have them do things like ‘SellUnit’ instead of ‘DeleteUnit’ and ‘GiveMoney’
If it were true that he wasn’t looking for an easy way around FE, then why not just follow the FE model of using remotes? breaking the FE model for the sake of ease of use can only be a bad thing, and introduce potential security issues, it’s better to just learn how to use FE properly, and do it the way it’s meant to be done.