Is saving player data in replicated storage safe?

Sorry, I am not the best at datastore stuff.

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.

1 Like

this is why I wouldn’t save in Players?

Store it in a DataStoreService??

DataStoreService = game:GetService("DataStoreService")

Save it in the player.

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)

If you dont want it to show in the leaderboard, change the name of the leaderstats instance.

2 Likes

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.

1 Like

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.

Edit: link to the replicatedstorage thing ReplicatedStorage isn't memory efficient for many of its use cases - #2 by Automationeer

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.

1 Like

Yes and No.

It really depends.

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.

1 Like

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.

My bad, I think I misunderstood something a while ago which stuck with me. You’re completely right

Yea, it was when FilteringDisabled was around, super easy to manipulate everything on the client and the server. Now its fine.

My bad, I think I misunderstood something a while ago which stuck with me.
As long as it’s kept serverside it should be okay.

1 Like

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.

1 Like

Replicated storage is an environment, accessed by the client and server.
Replicated storage can be modified by all environments, but if a client does change to this environment, It will only stay like this for the client, and not anyone else. Meaning if Wins.Value = 5 and then a client change Wins.Value = 5000. Then for the server, it will stay as Wins.Value = 5. On the other hand, if the server does a change, this change will be replicated to all the clients, and updated to the new value. But the client cannot update a value without the value being changed through a remotevent or remotefunction. One concern with storing stuff in replicated storage is that other clients can see a player’s data, which might in some cases not be good. I would suggest you store temporarily player data in a module script.

Heres a tutorial for module scripts
https://education.roblox.com/en-us/resources/intro-to-module-scripts

1 Like

As they said:

Datastore is what they were doing, I believe.

I store my data in a similar way in ReplicatedStorage
image

And yes, as long as the data is read by the server, hackers cannot change/modify it.
Storing in ReplicatedStorage is a good option if you do not want to store the data in leaderstats or across players.

Also I suggest you name your player’s data-folders by their UserId just to make reading and writing data easier.

I know you said you were bad at datastores and I used to be (and still kinda am) bad at them too but I’d still definitely suggest using them over replicatedstorage and there’s a YouTube video that I used personally that worked for me and I think it would help you