Data Persistence (DP) is the legacy data storage service offered by Roblox to save player data and has been deprecated since 2014. We have decided to sunset the system entirely by Tuesday 6/1/2021.
What does this mean for existing APIs?
The deprecated DP APIs, e.g. Player:SaveNumber(), and Player:LoadNumber(), can still be called, but will no longer have access to the actual backend data. All the write APIs such as Player:SaveNumber() will do nothing under the hood, and all the read APIs such as Player:LoadNumber() will return nil.
To make sure the change does not break any games, no error exceptions will be thrown, but you will see warning messages on both the Studio and developer console when calling the APIs. We’ll delete the data shortly afterwards for legal compliance reasons, and you don’t need to worry about handling GDPR requests for such data anymore!
Using the DataStores system
We encourage you to solely rely on DataStore service for persistent storage. The DataStore system is stable and we are also continually making improvements to it.
Currently the next generation DataStore v1.1 update is in private beta. It has a number of updates to support major improvements such as automatic versioning, attributes, listing, etc. We’ll let you know when they’re available for everyone! Stay tuned!
I completely understand why these APIs are being deprecated, although it’s still a little sad to see them go. Player:SaveInstance is still quite interesting, as it doesn’t really exist in modern datastore APIs. I’m sure it’s very niche, but I’d still like to see something like this become native.
The problem with that is that it’s too inefficient, storing full data of a given instance has a gigantic memory footprint, it’s always much better to take it into your own hands and store only what you need.
It’s good that you guys have given almost a month in advance, and even hand out warnings in the output; which allows devs who somehow still rely on it to know and make the change. Please keep up this trend
Remind me: Wasn’t SaveInstance() used for those old Personal Build Servers? Like preserving the placement of a model from the stamper tool for future visits.
On the one hand, I’m always for getting rid of old, unused systems that do nothing but hold the platform back. On the other hand, with this specific feature, it means effectively deleting all current and future data saving done by old games on the platform. All save data for any such games will be gone forever.
So this leads me to my question: What are the statistics on games that still use data persistence and also still get occasional players?
Also, I’m sure this was considered, but is there no chance for automatic migration of data stored with the data persistence API to the DataStore API for old games that still use the old system? Something relatively simple, like migrating all the data to a DataStore called “DataPersistenceEndOfLifeMigration”.
Just thought of that as well. There are quite a few old games that I join from time to time and they didn’t have any maintenance for years. This update will surely break them in one way or another.
Agreed. SaveInstance() would be beyond saving, no pun intended. However, as I understand it, this was fairly rarely used and wouldn’t result in much lost data.
As far as I am aware build mode actually published an update to the place. I don’t think SaveInstance was ever used in any of these. (Besides, that’d be player specific anyway so it’d only be able to be loaded for a specific player afaik)
Technically :SaveInstance is the only way to save instances, there is no way to do this in Roblox (without CoreScript access).
If we could create and update assets via our game scripts that’d give us a new way to save instances.
Alternatively DataStores could get support for some Roblox types like Instance if the backend service got switched over to using binary instead of JSON storage.
As far as I know I know of no existing libraries for storing instances exist, so, are there no plans to keep this behaviour anymore?
There is no way to compress data with lz4 unless someone ports it either (which hasn’t even been done for vanilla lua!) which means assuming you use an API dump tool, storing instances like this isn’t really as ideal as it could be either.
On top of that, if I recall correctly, SaveInstance supported scripts! That’s not going to be possible anymore if it ever was which means there will be no way for games to replace this behaviour and update.
What is the way most games save instances right now? I am really curious to know this because saving instances is something my game might end up needing to do for performance when loading and saving is done.
