LocalScripts can run in “nil” try it out yourself. Not many exploiters know how to access nil so it’s still a layer of protection.
I never mentioned scripts getting stolen or preventing that.
Some major exploiting tools have dedicated API and scripts to return scripts which have been script.nil
In fact a common major exploiting tool has that included by default when script scraping across the entire game (from the client POV). As mentioned by @SeemSuusy2, getnilinstances is such a function.
EDIT: Sample output of what these kinds of tools can export. This kind of output can be found in one of the major tools for free and thus can be expected to be used by a high range of users with such access.
(File referenced has been collected from alternate sources)
7 Likes
What are you talking about? I never said otherwise. I think you’re misunderstanding what I’m saying. LocalScripts CAN RUN inside the Character, Backpack, PlayerGui, PlayerScripts, etc. AND nil.
I only said it’s not know by every single one of them, didn’t call it impossible.
Seems like there is some misinformation in this thread, let me clear it up:
- Exploiters can access instances parented to
niland most of them do know how to do it - LocalScripts won’t “run” in
nil, but can reparent themselves there after running in a valid place first (which isn’t really any protection) - Exploiters can disconnect/pause
player.Changedevent, as well as change properties without invoking it or similar ones
As others have already mentioned, don’t put any UserId/Username checks on the client, unless for minor stuff like debug prints.
As for this
are you sure they didn’t execute their own admin script and gave themselves client-sided btools?
3 Likes
If you do this on the client, the localscripts or modulescripts will read it as the changed id or name, but the server would not change the player.
Ello. I have come to bring this back as I have found something new!
As a fellow exploiter, I have exploited games such as roanoke VA. When using a userid script I found out I can purchase cars that have a gamepass. When you join before the game completely loads you have access to those cars to buy. Once the game completely loads it blocks you from buying those gamepasses. If exploiters can trick the system with the userid script before the game loads, exploiters can buy ranks for groups that they don’t own. They could buy chairman and destroy a group.
Anyway my proposal is to store the userid once the player joins and when the userid changes from the client the stored id will change it back.
I wouldn’t advise admitting your an exploiter on an official roblox website, even white-hatting is still against rules 
1 Like
It was a old account but still
Well you did admit it on this account.
UserId can’t be changed server side. This is a bad suggestion because it doesn’t actually fix a problem, it band aids over a symptom of another one.
There should be no need to mess or check UserId if the proper gamepass checks are being done on the server.
3 Likes
1 - It won’t replicate to the server
2 - Even if you manage to do something about this, they can either delete the localscript or just disable the script’s LocalPlayer.Changed signal using an exploit function called getconnections
3 - you can’t really do something on clientside since they have level 6/7 access