-- Saves the sudio preferences.
AudioPrefDataStore = game:GetService("DataStoreService"):GetDataStore("AudioPreferences")
local players = game.Players
players.PlayerAdded:Connect(function(player)
local DatastoreKey = "id_"..player.userId
local AudioPref = AudioPrefDataStore:GetAsync(DatastoreKey)
if AudioPref == nil then
local defSettings = {
["Music"] = false;
["Effects"] = false
}
local succes, occouredError = pcall(function()
AudioPref:SetAsync(DatastoreKey, defSettings)
end)
if occouredError then
player:Kick("An error occoured during data connection, please rejoin."..occouredError)
end
end
local music = AudioPref["Music"]
local effects = AudioPref["Effects"]
player.Music.Value = music
player.Effects.Value = effects
end)
players.PlayerRemoving:Connect(function(player)
local DatastoreKey = "id_"..player.userId
local music = player.Music.Value
local effects = player.Effects.Value
local Settings = {
["Music"] = music;
["Effects"] = effects
}
AudioPrefDataStore:SetAsync(DatastoreKey, Settings)
end)
if game:GetService("RunService"):IsStudio() then
else
game:BindToClose(function()
for _, player in pairs(players) do
local DatastoreKey = "id_"..player.userId
local music = player.Music.Value
local effects = player.Effects.Value
local Settings = {
["Music"] = music;
["Effects"] = effects
}
AudioPrefDataStore:SetAsync(DatastoreKey, Settings)
end
end)
end
Yes, but that will not fix the error and the data will still fail to save.
You disable an optimization by deconstructing the function from Datastore:GetAsync to Datastore.GetAsync(Datastore). I would recommend to just wrap it in an anonymous function instead because I also think it makes more sense.
My practice says to just call one function rather than nesting, unless I am doing more than one action, like calling multiple functions. There isn’t really any optimization issue, just a different way to write it.
Sorry, I’m just really pedantic. While these two different syntaxes result in the same functionality, one of them (the :) is special behaviour that uses less table accesses than the other, and I just think Table:Function() looks better without the repetition and more “intended” than Table.Function(Table) or Table.Function, Table. That’s just my point of view.
Ok… But adding a pcall won’t fix the actual problem. The error would still be there, just hidden behind the pcall, and the data loss issue will still be present. Yes, it’s good to have a pcall around function calls that have a chance of erroring, but you should preface that adding one won’t make the entire system start working again with the data being correctly saved and retrieved.
Yeah. The error itself I am confused about, however the easiest way to work around it would be to kick the player from the server, or attempt calling Datastore:GetAsync() again.
I haven’t gotten error code 0 while working with datastores before.