Although, you cant control other characters (which are obviously unanchored) since those are client-server replicated.
I’m sorry to hear that. You can possibly negate the damage caused from place copying by placing items the client doesn’t need to access in ServerStorage and Server modules in ServerScriptService.
2 Likes
Nah, its fine. Most of the assets I use are server scripts and cant be copied, so if somebody copies a car of mine all they have is a wacky car with no scripts (and the joints/welds/springs/etc are fake and handled via scripts, so bonus up yours)
1 Like
I could use that advantage as a honeypot.
Actually they cant, even if its in workspace it will show up as an empty script to them
So on the topic of keeping your maps safe here is what I personally recommend although it only works on some types of games, what I personally recommend is loading your game in chunks… heres how this can work.
So, lets say your game is an RP game and you have 5 different maps the size of a size of one baseplate, lets break that baseplate up into 4 chunks.
Now, with these 4 chunks (blue dot is player, blue circle is the load radius) the client will be able to see what is within that blue radius and that’s the only parts on the client they’ll be able to see.
Now, lets say they were in quadrant 4.
Okay… but how do we accomplish this? My personal recommendation is first understanding how remotes work and then you will be able to accomplish something like this by using a RemoteFunction (Client → Server → Client)
Please note this is not a set fix for something like this as someone who truly wanted your map could fetch just the parts of it they wanted although it keeps you slightly safer from complete map saving.
2 Likes
Amazing explanation! This is a good way to secure most of a map, but this could cause massive server lag if you prefer unions over messages, and sudden executions of any scripts (if disabled and re-enabled upon loading). That is something to look out for. I will add you to the post!
1 Like
smol edit (new noteable replies)
This is different than property changes because its physics which is entirely different than other replication.
But, there’s a legitimate exception, which is descendants of a player’s character. All descendants of a player’s character can be deleted on the client, and this change will replicate to the server (the result is identical to setting instance.Parent = nil on the server).
This is how what’s usually called “FE god mode” works, exploiters will remove a player’s Humanoid instance (immediately inserting a local copy on their client), which means there’s no Humanoid to take damage. (Kinda funny, and it makes a lot of sense if you think about it)
What many people don’t know is that this applies to everything in the character. Tools, descendants of those tools, joints, meshes, clothing instances, etc can all be deleted by an exploiter, and these changes will go to the server.
This is also exactly how exploiters create “FE parts”, by deleting the mesh and joints of their own hats, which they can then control because they will have automatic network ownership.
This is unfortunately pretty difficult to solve if not impossible for us devs, but, things like FE god mode can be mitigated by simply replacing the Humanoid, which used to have some delay since you couldn’t reparent an instance during an AncestryChanged event.
Luckily this can now be solved better with the task library so the instance can be reparented instantly:
-- In server code, when humanoid removed (e.g. AncestryChanged)
task.defer(function()
humanoid.Parent = character
end)
vs this which causes a warning:
-- In server code, when humanoid removed (e.g. AncestryChanged)
humanoid.Parent = character -- Something unexpectedly tried to set the parent of Humanoid to Hexcede while trying to set the parent of Humanoid. Current parent is NULL.
8 Likes
Thanks for the explanation! I’ll add you to the noteable replies.
1 Like
gonna have to do the le bump, i made a CRITICAL CHANGE regarding avatars
1 Like
†: TopBagon(Profile - TopBagon - DevForum | Roblox) mentioned that if you have things like an IntValue or a BoolValue in your character, hackers can remove it and server scripts could break, read his post here
I don’t think that’s true, they can only destroy their replicated values, server won’t be affected
Also, player characters are known to need a lot of checks before replicating and/or removing, so after all if you have :findfirstchild and nil checks you are alr (in a local script because server scripts wont be affected)
1 Like
Things in your character replicate to the server, thats how the scripts could break, if a hacker deletes a vital item and the server cant find it then it go BREK (thats what pcall is for kids)
1 Like
oh right I forgot that they could delete it on join lol
2 Likes
what about if i, from a server script, call instance.new(“value”), set the parent to the character? in that case its replicated from server to client so there’s no issue right?
1 Like
That would not work, because the client can delete anything in its character. No workarounds. Checks must be placed on the server before calling anything in the client.
1 Like
the client can delete anything in its character, but it will only be deleted for him
1 Like
Anything the hacker deletes in his character is replicated in the server. Stop please
1 Like
CRITICAL EDIT: info on local scripts and module scripts
1 Like
Exploiters can read and delete server scripts if it in player’s character. You can test this in Studio - delete healing script, and you won’t heal anymore.
2 Likes