Data Saving Issues

The script I have is there to save a player’s tools/weapons when they leave and come back. The problem is, it works like 95% of the time, but there’s still a lot of reports of data loss. I can’t replicate it consistently, but it seems to be a problem stemming from Data throttling. I looked through the rest of my game for unnecessary calls of SetAsync, GetAsync, and UpdateAsync, and I’ve trimmed it down to about as low as I can get, and there’s still issues with data loss.

What else can I try?

This is wrapped in a PlayerRemoving function:

local savedtools = {}

for i, v in pairs(p.StarterGear:GetChildren()) do
	table.insert(savedtools, v.Name)
end

toolStore:SetAsync(key, savedtools)

Considerations


Consider using this method, pcalls are important.

I’ve tried using UpdateAsync as well, it it suffered from the same issues.

Do you know if the data loss is happening when you shut down your servers?

Oh yeah, try game:BindToClose().

This single line of code is not enough to determine the source of your issue, there is nothing wrong with it. Please provide all scenarios in which you make a DataStore call (gets and sets) as well as the frequency of their calls.


@Operatik

Neither pcalls or BindToClose will resolve throttling.

1 Like

What is the nature of this data loss? Is player data simply not saving when they leave, or is their data entirely lost, and they start with new data?

Some considerations:

  • In the circumstance that DataStore:GetAsync fails too many times or has no retries, you might be creating new data and saving that instead of continuing attempts to retain the player’s previous data.
    This might be where this whole :UpdateAsync argument is coming from, since it requires the player’s old data to be loaded in before being able to save it. This might require a different kind of set-up too, I would think.

  • if :SetAsync fails too many times, the whole operation may be skipped, even if it’s binded to game:BindToClose(), which leads to data loss if there is no autosave function in place.

It is probably better to retry data stores indefinitely while still accounting for data store throttles, as long as the error code is something along the lines of the data store itself failing, and not the connection to the data store.
I think you are able to get this from the first 5 lines of the message returned on failure. The most common error I have gotten is 403, but there are many others. It is mostly based on the structure of HTTP errors, but there is no knowing how many of them are actually used by the DataStore's API there is a page about this on the dev wiki.

I recommend that you use datastore2, as it has never lost a singular ounce of data since its making, and is also made and constantly updated by a lead top contributor here:

Keep in mind that datastore2 was not designed to keep server-specific or game-specific data, only player-specific stuff.

1 Like