I was reading about saving player data and how it is safer to store player’s data in somewhere such as replicatedStorage or ServerStorage because sometimes the player can get destroyed before the data saving script is finished, therefore breaking the script and not saving the players data.
Is it safe to store the all of the player’s data in replicated storage?
I know that hackers can access replicated storage, so if they change other players data, will it affect the player, or just the hacker since it is client based?
I have scripted the data so that when the player joins a folder is created for them in a folder called PlayerData which is located in ReplicatedStorage.
Yes, its safe to do so, Exploiters cannot change anything server-sided unless through a remote or other vulnerabilities. You can do it, but i don’t know why you should? The player instance will always be in Players and wont go anywhere until they leave the game.
So far what I have done (and this is something common that I see in YouTube tutorials) where they store the players data as values in the player, and then when the player leaves, it takes the values and saves them in the datastore.
game.Players.PlayerAdded:Connect(function(player)
local leaderstats = Instance.new('Folder')
leaderstats.Name = "leaderstats"
leaderstats.Parent = player
local Kills = Instance.new('NumberValue')
Kills.Name = "Kills"
Kills.Value = 0 -- set this to the saved amount in the data store
Kills.Parent = leaderstats
end)
Be careful to not send requests to data stores too often. Requests on a data store key are placed in a queue and, if the queue fills up, additional requests will be dropped.
A common mistake may be updating a player’s gold data every time they collect a gold piece. Instead, store the player’s gold in a variable and only update the data store occasionally, such as with a periodic auto-save and/or when the player leaves the game.
This is what the Roblox Developer page says about it.
How so? It’s a server sided script which can’t be edited by the client. If there is a remote event that changes these values, then obviously its a vulnerability. Other than that, its completely safe. Also, you can’t really spam out the data store to update values, that would be too many requests and would eventually break the script or delay it.
Hey! I would personally store those in a Datastore. You can also put them inside the player because no clientside exploit will have access to them unless you update them with a remote event. (Actually it really depends. I have used the player too)
It is good to avoid mass usage of ReplicatedStorage. From what I’ve heard it uses more memory and causes lag.
Adding to this, remote events are safe as well, and you can use it to update the values, BUT make sure to have some checks in the server so they dont spam the remote and make them get a lot of whatever. Yes, store it in a data store obviously so you can retrieve your data when you rejoin. But store your session data in your player instance so it can be used.
Indeed, sanity checks and other checks will make it secure to use a remote to update. I actually checked my own game and I store the values in the player and save them with datastore.
Storing player data anywhere is “safe”. When it comes to value objects, whatever is changed by client will not be replicated to the server. In that sense, yes, it is safe to store it in ReplicatedStorage.
However, there are some, reasons why you don’t want to store it in ReplicatedStorage. 1 is simply because you don’t have to. It’s much better to create a Module to handle data and info like this. If everything is kept server side then those value changes will not be replicated to the client improving performance.
Also, depending on the type of game players would be able to view other people’s stats. If you want that then that’s fine. But sometimes you don’t want people to know what somebody has in their inventory.
Really it all just comes down to this: To use your logic and judgement to decide whether or not you want to have it completely server sided or replicated to client.
Also, anything in the character can be deleted by client.
If this is something you’re worried about, then you’re probably not implementing the best system. As long as you have a reference to the values in a script, the values will always be there (provided the reference is still being used) and can be manipulated even though you have destroyed it manually with :Destroy() or automatically (when the player leaves). As long as you have a reference to the object you can still edit it:
game:GetService("Players").PlayerRemoving:Connect(function(Player)
local leaderstats = Player.leaderstats --> This folder will not be "destroyed" completely, and still can be edited
print(leaderstats) --> "leaderstats"
--> save leaderstats
-- assuming there are no more references to this folder anywhere else in the game, the "leaderstats" folder will now be completely destroyed
end)
Here’s a really good post about how garbage collection works on Roblox (which is what I’m talking about):
Yes, it is safe (as long as you’re on the server editing the data, with sanity checks in place).
It will not affect anyone else, but the hacker in question. Anything done on the client will never replicate to the server (with some exceptions like character movement, character animations, character humanoid, etc.).
This is fine to do. Just make sure you’re deleting the folder when the player leaves so it doesn’t stay in the game forever.
Storing it like that is fine, nothing is wrong with leaving them there.
The true vulnerability is if you rely upon the client information to award coins & wins, then thats bad. Don’t know why people here saying leaving data there is bad, also I understand the queue thing with datastore and this definitely works to prevent over-queue I would imagine.
I believe datastore2 also has its way of prevent over queue within itself without needing to make external objects like that.
you just have to make sure to destroy the folder when player leaves and data saves.
