If I make 2 different data stores if I spam one with requests will the other one be yielded aswell, I’m asking this cause I have a save system. To save objects but if a player was to spam save it would only effect them and not the other players. Any answers or replies would be greatly appreciated!
It shouldn’t be yielded unless you are storing them both under the same datastore/using a table.
This can affect other players data saving in your game if you have a big game. Too many requests can slow down the rate. So you might have to experiment with different ways to saving it such as :GetAsync, :SetAsync, :UpdateAsync, etc… Different ones will be able to handle more requests from the data.
I am saving using :SetAsync() is that bad in anyway?
I’ve heard update async takes the past value into consideration but set async don’t know why that really matters though
Not all. :SetAsync is one of the most popular ways to saving data. But when the player is added you will also have to use a method of loading it in.
It does. UpdateAsync allows you to look for the data currently saved under the datastore, and pull the data into use.
I know quite a bit about data stores I was just puzzled on that part.
posatta
July 8, 2020, 4:53am
#7
If you’re curious about why you might want to use UpdateAsync over SetAsync, there are a few topics people have already made about this:
SetAsync does just what it says – it sets the value of the datastore regardless of the original value. UpdateAsync takes its second parameter as a function, which allows for the old value to be taken into account (the function is called with the old value as input and is expected to return the new value).
If you’re not using the second parameter of UpdateAsync as a function, there’s no difference. If you don’t care about the old value, there’s no difference. This is only useful if you want to i…
pre-edit so colbert's post still makes sense UpdateAsync isn’t inherently a better function to use. You should only use it if you’re going to compare the old value to the new value. An example of this being useful is for values like levels and achievements that should never go down, only up. (This is assuming no rebirth system or similar; the exact examples of levels and achievements might not apply to your game.) You could compare the old value to make sure it’s less than the new value, and…
If you don’t want to use DataStore2 or an external database, there’s still some ways to make your system a bit more reliable.
If distance is always an increasing number, UpdateAsync could be helpful here – even if it’s not in the way ClientScripts said. The good thing about UpdateAsync is that it will use the previously saved value instead of just getting rid of it. That means if your initial GetAsync fails, by the time the player leaves you could be able to increment their old data instead of …
2 Likes