So when you spawn in you have a value created inside your character. Its not done just something basic. How easily can this code be exploited? The extra script just loop checks if the value == true
I just dont want to build a game off this system only for it to be exploited instantly.
1 Like
Clients can’t directly modify things on the server. If they try, the changes will only be visible on their own screen
You should be worrying more about exploiters abusing things like remote events to trick the server into modifying the values in malicious ways
4 Likes
You should instead put them under ServerStorage, named something like this: Player123_IsSick
2 Likes
Very easily exploitable, I would recommend storing all players in _G or in a module script as a dictionary, and have player.IsSick = to true or false
1 Like
You could try setting an attribute to the character for checking instead of a bool value
Player.Character:SetAttribute("IsSick", false)
Then for getting the value, you can just do Player.Character:GetAttribute("IsSick")
I’m not sure of how easily Attributes could be exploited, but maybe this could work.
1 Like
In addition, you should set the attribute to the player. And when the player respawns, set it back to false (since it seems you want that behavior).
1 Like
Client changes to Instances created by the server do not replicate.
game:GetService ("Players").PlayerAdded:Connect (function (player)
local character = player.Character or player.CharacterAdded:Wait ()
local Bool = Instance.new ("BoolValue")
Bool.Value = false
Bool.Changed:Connect (function (newValue)
print ("Value changed to " .. newValue)
end)
Bool.Parent = character
end)
Or just add the attribute to the player’s character, that way it’ll be reset each time the player’s character is spawned/loaded etc.
1 Like
Due to very old legacy reasons most descendants of a local character can be reparented to nil and it will replicate
In this specific use case Attributes are much better and you only need to connect a function to GetAttributeChangedSignal as opposed to looping
2 Likes
Do not confuse network ownership with replication
That’s exactly what he’s disproving? Did you even see what he changed?
Ok maybe I need to elaborate:
Nothing performed on the client directly replicates to the server, unless the server expressly permits the replication. Expressly permitted replication includes network ownership, which is responsible for physics replication, and it does replicate to the server assuming that the player in question was given network ownership. In this case, each player was given network ownership over their own characters.
Properties themselves do not replicate. You might think that it does if you change things like .Walkspeed and .HipHeight, but that’s because the change is applying to the client physics engine responsible for the character which is in turn being replicated. The property doesn’t actually change on the server, but it’s treated as such by network ownership
1 Like
Ah right, I completely forgot. Thanks for reminding me.
Would not suggest _G. Creates lag in comparison to Modules
This code itself would not be exploitable to some use, no