DataStore Script prone to adding/removing values

[willow sundial]

I've been researching an algorithm for a ds script that is easy to modify for adding or removing values to player statistics. I've recieved a proposition from an (don't leave yet please) AI model that says tables will solve the issue in given manner:

local DataStoreService = game:GetService("DataStoreService")
local playerDataStore = DataStoreService:GetDataStore("PlayerData")

game.Players.PlayerAdded:Connect(function(player)
    local data = playerDataStore:GetAsync(player.UserId) or {}

    -- Create a folder to store player stats
    local statsFolder = Instance.new("Folder")
    statsFolder.Name = "PlayerStats"
    statsFolder.Parent = player

    -- Define default stats
    local defaultStats = {
        Strength = 0,
        Kills = 0,
        Coins = 0,
        -- Add new stats here as needed
    }

    -- Load existing data or set defaults
    for statName, defaultValue in pairs(defaultStats) do
        local statValue = Instance.new("IntValue")
        statValue.Name = statName
        statValue.Value = data[statName] or defaultValue
        statValue.Parent = statsFolder
    end
end)

Should I go with this?
-# As in fully explore this idea

Okay well, except this fuckup at the bottom in the for loop.

[iron rover]

1. GetAsync really needs to be wrapped in a pcall, as it can fail.
2. Creating a new defaultStats table every time a player gets added is a little silly. This table can be made once.
3. I hope every value you could have will be an integer

[willow sundial]

Forgot to mention but I won't be using this script, it is to visualize the idea.

And for 3, I already have solutions to how I will handle the value types of all the data.

[iron rover]

Okay, then that's fine

[willow sundial]

I just wanted to know if I should go with this idea in general.

Obviously it requires tweaks

[iron rover]

I mean I'd probably just go with something like ProfileStore instead of making my own system, but it's fine as an idea

[willow sundial]

Eh

[proper cloak]

looks fine, go with it for now, but later on you'll probably want to add session locking. profileservice is a jack of trades but the roblox template Plant has a good showcase for the full session locking pattern, among other things.

for reference profileservice is a 3rd party datastore lib you can find easy on google not a roblox service

[willow sundial]

I am familiar with it

[proper cloak]

the for loop at the bottom is very common for the instance-value technique

[willow sundial]

Yeah I've just learnt that luau accepts strings in the brackets.

very cool function

[proper cloak]

normally this pattern is written to make int/etc-values in the leaderstats folder, generic playerstats works too for anything you need to share globally from datastore

[willow sundial]

The context to my needs is I have a playerstats folder and playerconfiguration config object and I want to solve the hastle of adjusting the script that handles those everytime i add or remove a setting or a value from the playerstats

[proper cloak]

only thing i'd change is putting statsFolder.Parent = player at the very end of the function to make it function atomically.

[willow sundial]

As mentioned before, this script is for display purposes only.

[proper cloak]

yeah the instance-value technique is extremely convenient, and conveniently extremely parallel safe

[willow sundial]

But thanks

[willow sundial]

It's the data[statsName] part yeah?

[proper cloak]

you mean working with tables?

[willow sundial]

The thing I've just mentioned

Thought that was an impossible scenario

data[statsNmae] where statsName is a string and not a number

[proper cloak]

statValue.Value = data[statName] or defaultValue statName is "Strength", "Kills", "Coins"

[willow sundial]

So that means its actually a searching algorithm with filtring

[proper cloak]

ohh, yeah so lua tables are very powerful. it is reasonable to consider literally everything in lua is a table. tables can be arrays, or dictionaries

dicts are string-indexed tables

like table["muffins"]. totally fine there

[willow sundial]

Never thought about that

Mainly due to me starting scripting in c++

[proper cloak]

hash table if i'm not mistaken, it has O(1) lookup

[willow sundial]

thats not possible there

well, not in that manner

for what i know

[proper cloak]

LuaJIT (Just-In-Time), the lua compiler, is not something i have researched but may interest you if you're looking under the hood

[willow sundial]

Sure, also where should i research about the instance-value technique

Im confused what thats supposed to mean

[proper cloak]

oh that's just an apt name i gave to the design pattern, where you use a bunch of intvalues, stringvalues, boolvalues etc, to store and replicate arbitrary data like that, you can use folders too as if they were tables, and then on the receiving end or any other location you can waitforchild the data root folder and listen for childadded/childremoved for changes in a folder (table-like structure) and getpropertychangedsignal("value"), etc. instances are extremely versatile and inherently parallel safe

as opposed to storing that data in a table in a modulescript, which is inherently parallel un-safe

or at least, much more difficult to work with. instances are easier

[willow sundial]

mhm

cool, thanks for the explenation and feedback

[proper cloak]

if you're serial only it doesnt matter, but good practice is easier to start early instead of finding out later why it should probably be a good practice

[willow sundial]

I like debugging to the point where I debug issues that don't exist yet.

Fits the saying better safe than sorry.

[proper cloak]

hot take: leaderstats should never be directly tied to datastores. they should be display only, and rely on other data for what their display-only-value is.

even if that means replicating the same data twice.

[willow sundial]

So basically like

[proper cloak]

roblox has a number abbreviator up to 1B, it breaks at 1T and shows 1,000B instead. it is display-only

[willow sundial]

DataStore = professional server room
leaderstats = sandbox

[proper cloak]

datastore is savedata, treat with care

[willow sundial]

Yeah that I know

[proper cloak]

leaderstats is what appears on screen, so it should be treated like a gui

unless you override it entirely ;p

[willow sundial]

Nah I just do anything thats optimizied but changes the leaderstats succesfuly even if forcefully

[proper cloak]

maybe u want emojis in your leaderstats names, who knows, bit awakward to have emojis saved as a key in a table in your datastore ;p

[willow sundial]

Unless theyre ascii

[proper cloak]

anyway yes you should fully explore this if you want to learn scripting, yes go with that for now. there's a lot of ways to build on it and many different directions, but this is where you have to start