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.
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.
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.
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.