Global Leaderboard Issue

[colbert2677 (ImagineerColbert)]

A minor pet peeve; try not to use the parent argument of Instance.new. Make it a habit to set properties first before the parent as well. Your objects should already be all set up before being dropped into the DataModel.

---

You have indeed stumbled across incorrect syntax. You’ve made an awkward error wherein you try indexing “savedvalue” in leaderstats, despite it not existing as a child of the leaderstats. See farizarps’ post for the correction. Remember to review your code carefully, as you can meet with unfortunate oversights like this.

---

@wevetments

@wevetments

It could be possible that the your player removing function is not getting the player object.

No, it definitely does. The Player instance is parented to nil but it’s not destroyed or garbage collected until everything associated with it is gone. There’s a reason why PlayerRemoving functions pass a Player argument.

@wevetments

plr.useId is supposed to be plr.UserId

Won’t cause an error. userId was deprecated in favour of UserId and keeping a consistent PascalCase naming convention for properties. The most it might do is throw a warning to use UserId instead. This is a non-problem.

@wevetments

Your SetAsync and GetAsync must be wrapped in a pcall

They do not have to be, but it’s good practice to do so. Anything that is internally a web call should always be wrapped in a pcall in the instance that it throws an error or fails to function. It also allows you to handle failures using the success boolean returned from a pcall.

---

@12904

@12904

Why use the Table though? If you are just setting a datastore to a value of the KO’s, just set the value straight to it like datastore:SetAsync(Key, savevalue.Value). This has worked for all of the leaderboard’s I’ve done, and its more simple then going through a table.

I’m not sure why this is being raised as a concern since it’s not relevant to OP, but to address it anyway, a table can be used if you want to hold several items of data to be fetched or updated. Using a table is fine, even if it’s single-entry. As well, there is no “simplicity” difference between using what value type is fetched from a DataStore.

@12904

Also, its better to use value.Changed instead of game.Players.PlayerRemoving because it does not save it the player crashes, the .Changed will just do it whenever the value it changed.

No it’s not, at all. Changed is an excellent way to exhaust your DataStore budget which is very limited. This is also bad practice in general. You should only save as in when it’s necessary. That means coercing data after a certain circumstance has happened, when a player leaves or in an autosave interval running in the background. Other use cases applicable.

---

@CodeNinja16

@CodeNinja16

But this is a waste of resources (datastore calls are generally quite expensive network operations) and also you might even go over the max request limit.

I wouldn’t say they’re expensive. Even if they are, the expenses are handled in the backend and are relatively invisible to you as a developer.