@LucasTutoriaisSaimo Just realized what you meant by 1.1 backups (I thought you were referring to some module named DataStore1.1, there’s been a few of those that have been sent to me).
Yes, it will be supported once I start to work on DataStore2 again, which will be when my next project needs data storing. I have no ETA on when that will be.
Oh yeah, DataStore 1.1 is the new DataStore update in beta. It includes features like:
Backups (that last 30 days)
Metadata, you can set meta data. Whatever you want;
You can list keys in a DataStore;
You can list DATASTORES themselves;
You can list versions (backups);
Also linking UserIds, which Roblox Staff said along the lines of “UserIds will in the future, support automatic data deletion if needed.” For like GPDR and stuff? I don’t remember the name of that action or whatever. But yeah, if a player demands their data be deleted from Data Stores, their plan is to automate this process using UserId key linking.
and a bit more.
I don’t think this is private info, as the functions are all like kind of slightly talked about already in the wiki-a so?
It’s kind of a OrderedBackups solution integrated into actual datastores.
I’ve used it, I got in the beta, and because of that I actually found that it’s not as expensive as making pointers to data in OrderedDataStores; It’s integrated. It basically uses a similar method as the DataStore2 Ordered Backups method. It keeps a bunch of backups, just gets the most recent.
Given that the Ordered Backups method is expensive anyway, these backups are basically not as expensive to integrate, or as hard.
It does seem whatsover, that older datastores, made before the 1.1 days, will NOT support these backups right away. They claim, that these will be added some time after it’s released or in-mid beta. Probably in mid-beta.
Would hope to have it sometime, as I need to have saving for stuff for the server. As for when the server shutdown, there is things such as guilds/servers/other stuff that can only be saved on the server. Would love to see this sometime in the future.
Also one more question, since some players report losing stats upon teleportation, I wonder if this is a good approach on saving before a teleport.
A Save RemoteEvent that calls :SaveAll() to save all stats
The teleportation script waits for the ConfirmSave to be fired, using :Wait()
A ConfirmSave RemoteEvent gets fired when :AfterSave() has been called. This is where the confusion is. Which of the keys do I associate :AfterSave() with since I got 5 keys under the MasterKey.
The teleportation script then proceeds to the teleport.
However, some players seem to get data loss issues despite this measure and in some cases, the key where :AfterSave() is associated with gets saved while the other 4 doesn’t. The main question is if this is an appropriate approach on saving before teleporting?
Kk thanks! I’ll just have to think about it then. Also, despite this approach, some people still report some data loss for other keys that don’t have the AfterSave method. Would putting a wait(), not the method but the built-in function, fix the issue than teleporting the player at an instant after ConfirmSave, (fired by AfterSave), was fired?
How would I go about doing a ordered data store for players xp?
I got the datastore working already. I have the value xp combined into “DATA” with all the other players data. Is their a way to make a global leaderboard with that or how would I go about that? If this question has already been answered just point me in the right direction please.
You should not use autosaving methods, instead update values as they change. DataStore2 is perfect for not worrying about autosave methods, also it is not efficient enough to autosave with a timer.
Yeah I guess so, however it might call that twice since the player ALSO leaves? I would go for it, if I were you. It probably shoudn’t throttle with the same key warning if you’re using the OrderedBackups method.
The Current DataStore2 script, unedited, removes functionality of Soft Shutdown scripts.
I’ve looked into the Code and it sets the player parent to nil, so .AncestryChanged gets fired.
The problem with that is, Guis get destroyed, Player can’t be selected. I had to remove that line.