Does this require me to still edit the DS slightly just like DS2 to make it capable of saving the data without using the players instance and instead using an id such as the players user ID?
Iâm confused about what you mean here?
This behaves very similarly to a NORMAL datastore. You can mess with values normally and except them to save as backups as well.
No no, with DS2 it users the player instance itself, i cant change this to player.UserId without editing the modules of DS2 itself, I was wondering if datastore+ provides support for this or if i would also have to edit the ds here too
Yes, itâs actually the only way. You need to think of it as a normal datastore. So you put your own key there.
You donât have to edit anything, just use it as a normal datastore, use your keys and stuff, thatâs it.
Update: I updated the module and added what I discussed above and more, if you DID use the Backups method, I would not update the module. If you need help, I can provide you with the older versions. I might make a back-catalog to older-versions. Donât get too excited though.
If you use this, please update the module, as your data is in risk if you donât. Mainly if you use Update() to session lock, and also get data, or something similar.
Update: Changed how the module works more internally. Expect some rewrites of some functions again.
As you can see, now the github is the main way to get the module and everything.
Really great, I like that you made it not have to rely on the player instance, it really makes it more flexible and more controllable, Iâll definitely look forward to seeing what else could be implemented to this module if so. Good job.
1 Like
In my experience, (might have been an implementation issue) DataStore2 has been prone to data loss, despite whatâs advertised. When a player launches an account from another device, or generally crashes, players in my games have reported data loss. I use data store2 in my game with the guidelines given and this issue seems to persist. At this point, Iâm just going to be writing my own data handler module rather than using data store 2.
1 Like
Yes! You can still have backups using this! One thing, DS2 only has the ordered data store for the listing, and then the one that keeps the backups.
It will try using the first version by using a pointer from ordered data stores. This has been proven to be able to cause problems in the past where they would unsync.
While it isnât hard per-se to make a UpdateAsync for that, having a main version, really helps on everything. Especially when Roblox restores datastores to a past stage;
Functions like UpdateAsync are mandatory if you wanna letâs say, add session locking.
One thing about DS2 is that DS2 does not use backups to load data at all. DataStore+ also doesnât. It can load the main version, and if that isnât found, it will try only to get the newest backup.
Thatâs intentional. You donât wanna use outdated data.
Backups are backups, so you have to use them when you have to use them. If anything happens, you can look through them, and restore one.
I have been able to implement session locking using this module. I used another module, I might share that.
The reason I mentioned session locking is:
Session-locking will lock data until the player data is saved. And also auto-save and everything. Kind of just because of how session locking, auto save is kind of required 
Profile Service helps you on that too, I find Profile Service a bit âhardâ to understand, but itâs good too. Has a lot of flexibility.
DataStore+ allows you to build your own data interface, kind of everything on top of it.
You can also technically make your own âMethodâ which introduces what you want.
How does it save backups? Does it use its own queue-logic or the default Roblox one?
I always use the default DS, donât see how DS2 is superior to the default one, if not more limiting.
Read the documentation but not enough data on backups and none about queue.
1 Like
Session locking doesnât guarantee data being saved before another server starts editing the data, that server can crash or even just fail to save the data or other problems may even arise.
Hm, queue? ⌠What do you mean by queue�
It saves backups like this:
Thereâs a main version. Any modifications to the main version will replicate and create a new backup. (Unless you say otherwise.)
If it canât get the main version, it might get the most recent backup.
If you wanna know a bit how the berezaa method works, this post shows how berezaa saves his data.
One thing, he used os.time() before, os.time() sucks. It can be unsynced between servers and etc. Weâve all heard it. DataStore+ and DataStore2 both do versioning. Meaning everytime it saves a backup, it saves the âindicatorâ for these backups to +1 higher than the last backup saved.
The good thing about DS2 and DS+ are the fact they even keep backups. It keeps every single version you ever saved. If ANYTHING happens, if some player loses his data, you can look through backups, and restore that playerâs data.
I might make some function, something go through backups. Maybe some plugin? I donât know. I forgot to add that to the Gotchas page. Iâm going to add that today.
I didnât have any of these problems, when you do session locking, you block the player from joining until itâs unlocked, and trust me on this, I had a fair amount of testing to make sure everything was alright with my version.
Session locking saves a timestamp, like os.time(), and compares that when getting data, if the data was AUTO saved recently, then maybe kick the player, and leave the data alone. Donât modify it. And then on saving, like PlayerRemoving, BindToClose, you save the data for the final time that session, and also reset the timestamp, so thatâs itâs unlocked.
I mean, just make so your datastore canât edit data if itâs locked. Not hard. Like, kick the player, donât mess with the data, etc. At least thatâs what you are supposed to be doing.
Well, thatâs not really controllable, thatâs on Robloxâs part, you can do retries, etc, whatever you can to save it. If it doesnât, the auto save is at least gonna have some data, and thereâs the backups like I said, if you used DS+ like I did.
One thing also,
That is not true.
No data was lost. Technically.
The thing with DS2 is that you can get the backups and roll them back. DS2 does try to make sure everythingâs fine, but in case anything goes wrong, you can go through backups, I believe DS2 has a âGetOrderedBackupsâ function on which I wanna add an alternative in DS+.
You clearly donât seem to get how it works, you donât block the player from joining but instead wait unless the session lock on their data is assumed dead or removed.
Well, you can also do that. Thatâs called âForceLoadâ on ProfileService. But you can also give up on it and for example, kick the player.
And even on ForceLoad, youâre not⌠Your point still doesnât make sense.
Thatâs something else on what profile service does, session locking is just not allowing a server to work with a players data if another server is currently saving it.
Yes I know profile service works with more than just session locking. In fact itâs the most recnogizable feature of it. That doesnât change the point, please donât drift the conversation.
How am I drifting the configuration? You clearly donât know how it works and assuming other off topic stuff.
Also, we are talking about session locking, not the functionality profile service provides with session locking. You are the one drifting the topic with profile service, please act mature and donât be subjective.
I only mentioned Profile Service because itâs the main way people do session-locking.