


UpdateAsync has no use for people who save data separately. If you’re not doing that, learn how to do that before thing to understand this. If you didn’t notice already, you should be saving data with tables and making everything save under one key, if it’s related data. …but it doesn’t seem to do much different. compare past data, get stuff from it, etc.įrom this call, you have to return back the data you wanna save, in case you return nil, it will keep the data as is, and not save and not do any write requests.ĭataStore:UpdateAsync(player.UserId, function(pastData) 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.ĭs:UpdateAsync("userId", function(pastData) UpdateAsync is a smart Get-Set combo as stated by colbert in the replies of FHD’s topic.Ī UpdateAsync call will accept a key, and a function. This post has a lot of already existing opinions and it does share a lot of what I am gonna say, however I’ll try packing in more updated and more specific details.įirst of all, UpdateAsync will try to re-run calls if the set call is done after another set call happened, until every UpdateAsync call was done in order. This thread is reasonably outdated whereas a resource like ProfileService is actively maintained by It covers scenarios you might not typically account for such as preventing the duplication of items when trading with session-locking. If you want to setup reliable datastores quickly and without having to worry about all the quirks which come with the datastore API, definitely check out ProfileService. Stop using SetAsync() to save player data Community Resources
