I’m trying to update a value for a player every second, and the game has 50 max players per server. I keep getting throttled error, how do I fix this?
1 Like
DataStore 2 and profileservice
1 Like
Or maybe just not update the value every second?
4 Likes
I’m not sure what you’re doing, but if it’s to communicate between servers, you’ll want to use the MemoryStoreService instead.
1 Like
Maybe he would want to cache data so datastore won’t throttle.
if he dosent want to not make it save every second
1 Like
Maybe I should update it when player leaves? It isn’t that important.
Yes, almost every game does this. You should also save every player’s data when game:BindToClose() as it saves every player’s data when the server shutdowns.
Imagine this, a player leaves a running server, joins another server, where’s his data?
I believe bindtoclose is bad but player removed is ok.
What do you mean by where’s his data? His data is still saved.
Also, Roblox recommends that you use BindToClose.
https://developer.roblox.com/en-us/api-reference/function/DataModel/BindToClose
You also gave just one (false) reason and you’re saying it’s bad, please do more research before replying.
every second… You know that data stores have rate limits… right?
BindToClose fires when the server shut down, what i meant is like theres a 5 player server, right? and he leaves that server to join another one.
BindToClose only fires when the server actually shuts down. It doesn’t fire when a single player leaves or even the entire player list leaves, it only fires when the server shuts down. For example, when Roblox shuts down the server for maintenance, that’s when it fires BindToClose.
… why use it then? i dont see the benefit now
You use it so that if Roblox shuts down the server, every person’s data gets saved. PlayerRemoving doesn’t fire when the server shuts down therefore player’s data will be lost if you don’t use BindToClose when the server shuts down.
The basic answer is to just save less often, but also save at the right times.
These are the limits, and if you hit any of them, data will get throttled. Take a look at the picture below. Notice the section below “Cooldown”: there must be at least 6 seconds before you write to the same key again. I had this issue in my game and I fixed it by saving less frequently and I instead decided to save at more important moments instead of saving every second.
From Data Stores | Roblox Creator Documentation :
But just saving less often is a bad idea, as you would only have 110 Set requests available per minute with your 50-player player count, meaning you would only be able to save data about once every 30 seconds for every player. You need save data at important times. Important things can happen in that 30 seconds, such as a player buying a dev product that increases how much money they have, and then Roblox decides to crash on their device (PlayerRemoving is not fired for players who “leave” the game like this), causing the money they purchased to never save and also causing them to have wasted Robux on nothing. I’m not a datastore wiz, but I have done a fair share of searching and this is what people consider as good practice:
-
Save data using .PlayerRemoving, this will save the player’s data if they leave the game, such as
voluntarily leaving or getting kicked. PlayerRemoving does NOT happen if Roblox crashes on that player’s device while playing your game (This is quite common on mobile devices). -
Use BindToClose() to kick every player in order to save player data when the server shuts down because kicking them will fire PlayerRemoving. Also take note that servers will stay open for up to 30 seconds, but if that time is up and it’s still saving data, the server will just close and not finish saving data. I have seen it be recommended to use a spawn() to save each player’s data at the same time instead of one after the other.
-
Save data any time a purchase is made. If a player buys two or more things before the 6-second cooldown is over, the save request for that key will be added to a queue (I believe this is also a form of throttling). I’m not certain what to do about this except just let it happen.
-
Save data periodically. This is a precautionary measure in case the Roblox Datastores stop working while a player is still playing your game or if Roblox crashes on that player’s device. (People can’t seem to agree on how often periodically should be though, but I used three minutes in my game)
-
Use UpdateAsync(). Here’s some advice I was given from the Theme Park Tycoon 2 dev (Den_S) on how to effectively use UpdateAsync:
generally you should never use setasync unless you are absolutely entirely certain that the data there hasn’t ever been set before (i.e. is nil)
it offers no conflict resolution techniques at all
the easiest way to fully prevent any data conflicts (and good enough in most cases IMO) is to store a revision index in your datastore value
when you GetAsync on join, you’ll get this revision id in the data as well
when you save, use UpdateAsync, then make sure that the previous revision id is the same as the one you got with the original GetAsync
if they differ → something else updated the data so you’re out of sync, then do not save and reload the player data
if they’re the same → increment this revision id by 1 and continue happily
would generally recommend to think about players being in two servers at the same time and what could go wrong there
you’ll run into a lot of such potential conflicts then, which you should handle properly
easy to test by joining via studio and in a live server at the same time too
this will immediately cover all sorts of cases where datastores may return slightly out of data too
I didn’t realize it at the time, but I believe this Tutorial by ForeverHD tells you exactly how to do what Den_S told me to do: Stop using SetAsync() to save player data
If you are wondering where to put the data after you get it, some people like to use ModuleScripts. I do not know if this is considered good practice or not yet. Storing player data in game - #3 by Quoteory
3 Likes