No need to call PlayerLeft. When the player leaves, it’d be automatically fired 
1 Like
I just wanted to edit one part of the code lol. Primarily a better way to kick a player from the game.
1 Like
Ok everyone is talking about this event and code inside in the event my question was how is the script built and the style.
game:BindToClose(function()
end)
Your LoadData function is dangerous. You pcall the GetAsync (good), but if it fails it just sets the player’s data to empty, and your SaveData function has no knowledge of whether or not the data its saving is their original data.
If data stores go down and people play your game, they will lose all their data.
Why do you have the loop? You should instead just make a BindableEvent and yield on it until all shutdown operations/saving finishes.
4 Likes
Ohhhhh, that is something that I have not thought of.
For shutting down a game I don’t recommend kicking the players, but teleport them to a reserved server (the same server, but really a private server) like this script that Merely did.
2 Likes
Well, we keep the most of the players that were in the game.
So yeah, that is why I made so it teleports them to the same game.
but yes it kicks them again xD
But if you teleport them to the same game you could get in a loop of where you teleport the player in a server that’s trying to shutdown that script teleports the player in a reserved server then after like 10 seconds teleports them back to the main servers.
Your usage of SetAsync is uncomfortable. In addition to what Kampf mentioned, I personally would not use SetAsync unless there’s a reason I need to force data to be a certain way. I’d prefer using UpdateAsync to minimise issues while updating data - it does exist for a reason, as the name states, UpdateAsync. I find that Set is more for setting when it’s needed (i.e. PlayerData doesn’t exist).
Your shutdown function isn’t going to do much. All you’re doing is teleporting players back to the game. This doesn’t give the game a chance to shutdown old servers, especially since you’re hooking functions to OnClose (which allows a maximum of 30 seconds to finish operations binded to it before finally closing the server) - servers can be kept alive and negate the purpose of this function.
@Shadrz Why? If you’re going to suggest something, elaborate on your idea. Don’t just tell someone not to do something and forego reasoning.
1 Like
I see this all the time when people use pcall. There is no need to wrap this in a function as pcall takes a function followed by any arguments to pass to that function.
pcall(function()
StatsData:SetAsync(Player.UserId,DataStoreModule.SaveData(Player.leaderstats));
end)
You can use
-- you need to pass the table as : is used
pcall(StatsData.SetAsync, StatsData, Player.UserId, DataStoreModule.SaveData(Player.leaderstats))
1 Like
What about this?
pcall(function()
StatsData1:SetAsync(Player.UserId,DataStoreModule.SaveData(Player.leaderstats));
StatsData2:SetAsync(Player.UserId,DataStoreModule.SaveData(Player.leaderstats1));
end)
You would want to use two pcalls as you do not want to duplicate the request if one fails.
2 Likes
So what I’m trying to say is that he should use metatables, I’m not great at them but you should definitely put them in a module.
Metatables are not going to help in this use case. Metatables are not an alternative to ValueObjects, they’re intended to run metamethods on tables for certain cases, including the following cases:
- If a member of the table is indexed or getting an extended index
- Deciding what is to be done when a new value is created
- Determining what should happen if a table variable is called like a function
- etc.
See the metamethods Developer Hub article for more information on metamethods (since that’s the only real part of metatables you need to know, metatables are as simple as setmetatable(table, metatable)).
A proper alternative to ValueObjects is ModuleScripts, which OP is using aside from the actual registration of data which is loaded out across ValueObjects. Depending on OP’s use case and preferences, this advice could hold no value to them.
2 Likes
Oh ok, that makes sense.
My recommendation is what I usually do: Cache the data in a table. When I write Data Store modules I try to make as little use of “the Async’s” as possible.
So how can i fix that?
Retrying a reasonable amount of times and if it still doesn’t work, leaving them with the default data but:
- Telling the player their data is a backup and warn them their data won’t be saved
- Not saving it under any circumstance
What if so I made BoolValue called DataLoaded if DataStore throws errors I won’t make the value true if it loads then I will set the value to true. When a player leaves it will check if DataLoaded value is set to true if it is set to true, then it will save the data if not then it won’t save it and the player will keep his old data. How does this sounds?
That sounds fine to me.
1 Like