So an example would be like:
— checking/loading data
if result then
— load data
else
— retry and stuffs
end
— saving data
local tableData = {
["Version"] = plr.leaderstats.Version.Value
— your data
}
DS:UpdateAsync(plr.UserId, function(pastData)
if pastData.Version ~= tableData["Version"] then
warn("Data Version is not the same.")
return nil
else
tableData["Version"] += 1
return tableData
end
end)Exactly! Only thing you would do differently here is not put the value inside leaderstats, I would just keep it in the player. (You probably know that already)
You mean I shouldn’t put the Version inside the leaderstats?
Yes, you should just keep it inside the player object, not leaderstats. Anything on leaderstats shows up to everyone on the playerlist so.
Thank you. This tutorial finally gave me a great clue on how to use UpdateAsync(). Thank you so much.
gonna bookmark this
One last question, if the version doesn’t match, what should I do before I return nil! Because if I just return nil after the player leaves the game and then I code it to save data on exit, the player will be mad that their data didn’t save… so how can I make sure?
If you’re auto saving, then I would kick the player. On player leaving, I would have just not tried saving.
Thing is, the data would probably have been already saved. If it was different, that very likely means that maybe it was saved already, that the data was written to in a way.
This line wont work if the past data is nil (player joins in for the first time), so it will always error.
Other thing for update async, generally I like to put in a check to see if their current value is greater than their previous. This means that if for some reason they have lost their data, it doesn’t get overridden
local success, err = DataStore:UpdateAsync(key, function(old)
if (not old) or (player.DataVersion.Value > old.DataVersion.Value)
return {player.DataVersion.Value};
else
warn("PlayerData update error");
return nil;
end
end)
I would also create some other datastore functions. One to reduce player data, and one to reset/set player data (with setAsync, That’s the point of set async)
Yes. That’s why it’s pseudo-code.
That’s just wrong… that tecnic is that you don’t overwrite data, you’re assuming the data is already overwritten? That’s pretty odd. This “tecnic” is mostly so that BindToClose() calls for example, don’t save twice from PlayerRemoving. The only thing way is to compare if it’s the same in this case.
This tutorial is not as informative, since tons of resources have explained how to properly use UpdateAsync, though it would be good for an beginner to understand how to properly save data. This tutorial also doesn’t explain how to efficiently load data with UpdateAsync, nor tells how it respects “incoming calls”. Instead this tutorial; Stop using SetAsync explains it all, this tutorial for the most part has no point or usefulness except the only thing you did was just re-phrase the old tutorial.
This function will be ran with the first argument being the data that is currently there, you can use that data for comparation, getting data from it… etc.
This is incorrect, the callback will always be called despite if there was no data for that key, it will only be not be called is when UpdateAsync fails.
This is incorrect, I didn’t say it wouldn’t run if data wasn’t there.
If data is nil, it’s still gonna get “passed as an argument” obviously.
I do, I don’t talk about it’s internal system or something, no one knows that but:
–
Anyways it’s supposed to be for beginners for basic use, and the post you linked is a big vague on how it works for anyone trying to understand. I still see A LOT of newer scripters NOT knowing where to use it, and blindly recommend it for random stuff.
Even so, when creating a tutorial try to show things to people. Even just the most basic of things like checking if the data is nil will make a difference for people trying to use the code on their own. (Last thing you want is people copying your code and they can’t figure out what’s wrong)
The tutorial you linked made sure to add the effort of checking for nil, you should do the same!
Why? It still wouldn’t override data if the data is the same, because I’m using greater than rather than greater than equal. All this is doing is adding an addition check to make sure player data doesn’t get overridden in the case where for instance datastore:GetAsync() doesn’t work when the player enters the game, but UpdateAsync() works when the player leaves the game.
Example:
Player joins, GetAsync() fails, so player’s coins are 0
Then player leaves the server a little while later, and UpdateAsync() works, setting the player’s coins to 0
Now when the player joins a new server expecting their 100million coins, they are so angry and quit because they always get 0 coins when they join the server
It doesn’t seem as if I’m saying that. I didn’t ever say it wouldn’t run if there wasn’t data.
I’m pretty sure Roblox doesn’t have even talk about this on the Wikia or even reference it. That’s about what there is to it. UpdateAsync will try to queue it’s calls in the order they were called. Do you want some DataStoreService code from their database? Yeah I don’t think I would be able to find something like that. You wouldn’t be able to find anything either. this topic is about how to use UpdateAsync in the right way, not about how DataStore’s calls work internally.
I’m pretty sure Roblox doesn’t have even talk about this on the Wikia or even reference it. That’s about what there is to it. UpdateAsync will try to queue it’s calls in the order they were called. Do you want some DataStoreService code from their database? Yeah I don’t think I would be able to find something like that. You wouldn’t be able to find anything either. this topic is about how to use UpdateAsync in the right way, not about how DataStore’s calls work internally.
This is well explained in many resources, therefore your point is invalid here. Infact, this is explained in the Roblox wiki page it self:
That has NOTHING to do with the queueing, stop spreading false information.
That has to do with queries, if you call UpdateAsync for a key and another UpdateAsync is being processed for that key, that UpdateAsync will be cancelled and queued to be called again after the one that is being processed is completed, this is clearly explained in the screen shot I showed you, I suggest you read it clearly before making bold accusations.
The tutorial explains the actual use of UpdateAsync() well and is beginner friendly. I believe it is useful and represents a firm step towards understanding of this method. Leaving aside how UpdateAsync works internally, the article has fulfilled its purpose. Good job.
This has been really helpful, I’ve seen and read through other updateasync “tutorials” but I’ve been kinda stumped on how it works and could be used in a more efficient way from setasync, and you explained it extremely well!
Thank god I found your topic because I was about to use updateasync with leaderboards because everyone on the devforum was saying it was the right thing to do.
