PlayerState: ProfileStore + Replica, Without the Headache

Resources Community Resources
187

Iā€™ll take a look soon and fix it, thanks!

188

np. Iā€™m pretty sure the same thing will happen on the Client too because of the same issue with PlayerStateServer

189

What are the benefits of using Replica over a networking library such as Blink or QuickNet? I donā€™t really see any conveniences of Replica over the latter for a datastore. Seems to me like setting up Replica and hooking up a networking library are about the same in terms of effort, and a networking library would be way faster in terms of performance/receive. Perhaps Iā€™m missing something?

190

Replica isnā€™t chosen because itā€™s the fastest net library. Itā€™s chosen because PlayerState is a replicated datastore, not a remote-event wrapper. If your game only needs lightweight custom sync, Blink/QuickNet is a valid path. If you want the client to hold a live copy of profile data with path-based change listeners and minimal custom glue, thatā€™s the convenience Replica gives and itā€™s already integrated so youā€™re not maintaining that layer yourself

Lmk if you got any questions, happy to help

2 Likes
191

hi, can i ask how multiple save slots can be handled with this system? it seems like the system is intended for the highest level of data on a certain key to be data relevant to the current play session (if thatā€™s a way to put it), and it doesnā€™t seem like the api allows you to have data on more than one key

192

Interestingly enough, I am looking to create an RPG with multiple saves and the user can load whichever one from the main menu. I am also wondering how this can be done in the cleanest way.

193

go to the server player state module and add a slot argument to the Init function, and then append the slot with .. "_" .. [argName] to the key it uses later in the function from the config. youā€™ll have to ctrl + alt + f all the other instances where playerstate uses the key in the config but that should work well enough

194

Hey! Sorry for the late reply.

I think thereā€™s some confusion around what session means in PlayerState, unless thatā€™s not what you were referencing.

The session table is not a save slot. Itā€™s temporary data for the current server visit only (like isChopping), and it doesnā€™t save when the player leaves.

You can still have as many keys as you want. Define them in DefaultData and use Set/Get, SetPath/GetPath, etc.

For multiple save slots, PlayerState doesnā€™t have a built-in slot system as of right now. The usual approach is storing them inside one profile:

-- DefaultData
Meta = { ActiveSlot = 1 },
Slots = {
    ["1"] = { Coins = 0, Level = 1 },
    ["2"] = { Coins = 0, Level = 1 },
},

-- Server
PlayerState.SetPath(player, "Meta.ActiveSlot", 2)
local slot = PlayerState.GetPath(player, "Meta.ActiveSlot")
PlayerState.SetPath(player, `Slots.{slot}.Coins`, 100)

I will take a look at adding better support/easy api support for it soon though. It is a good idea to have easy support for.

@ItsTechNose

1 Like