Across multiple servers: no.
It could be done with caching (ex. ProfileService) but it may be too much data to save.
2 Likes
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.
5 Likes
Use a table for this. You don’t need support for color3.
6 Likes
It’s been forever since I’ve seen a good use of Legacy Data Persistence in use. I’m happy it’s being dropped for DataStore v1.1.
The new data storage features sound pretty cool, hopefully these will be stable on release, and if so, I’ll be very happy ^-^
3 Likes
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)
6 Likes
Will we see any way to save instances?
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.
What is the current stance on this?
14 Likes
I had no clue these were even functional nowadays, I haven’t seen anyone mention them since 2014. Are there any games that use DP and have a player base?
3 Likes
I never used Data Persistence, but about a week ago I was curious to learn about it. I experimented with player:SaveInstance() and was so surprised to actually see it could save entire models.
I have a slight suspicion that someone at Roblox saw me using it last week and made the decision to remove it. 
8 Likes
It would be nice if instead of completely deprecating these functions, it would automatically make a DataStore call instead, because I actually do have an old game that uses lots of data persistence calls. The only trouble is that these calls are in scripts that I have copied and pasted over and over again, and converting to data stores isn’t exactly trivial because of caching.
If this doesn’t happen, people’s games just won’t save which tbh isn’t the worst thing in the world for my game, but it would be nice if there were still a failsafe.
17 Likes
@jmkd3v
Roblox has already responded on this, and said that there are many reasons they won’t be doing this. For one, it is inefficient, as it is unlikely that you will need all of the properties to be saved. Also, Roblox said that in the backend, it would be impossible and not something they would be interested in doing, as long as they use JSON storage (which I doubt is being changed)
Most people don’t have the need to save entire instances and rather save the properties that need to be saved. However, if this is really neccisary, you can use something like InstanceDataStore . I already did a source code check and is optimized to not save properties that are default to save storage space, making the 4 million byte limit not too much of a worry.
Perhaps instead of doing this, it could make a “fake” request, where instead of writing and reading from Roblox’s datastores, it would simply cache it in the server’s memory. This would however mean that data would not save cross play-session, but it will at least stop games from completely breaking and stop functioning.
Basically it would save the data on the server rather than on a backend data server, which defeats the purpose of data saving, but is a better alternative to removing all functionality of it since it will allow old games to still work. Also, the fact it doesn’t save cross-session discourages the use of the function, which is what Roblox is trying to accomplish here.
3 Likes
I mainly just want to know what Roblox’s stance is on this. I at least think there should be a way to generate rbxm binaries and load rbxm binaries from lua code separate from the file system, because, that’d open up more use cases and would allow for people to easily save and load instances from data stores, plus the performance benefits, plus the storage benefits.
It’s good that a library exists for this. I still think it shouldn’t be up to the user to use hacky solutions and external APIs though, and, the ability to load scripts is still not there, which, wouldn’t benefit me but would be incredibly useful.
In my game it would actually be significantly more performant to be able to load instances in-engine, I’d be saving/loading the entire map in the game which contains hundreds of thousands of instances. That could hit the 4 million byte limit in datastores in no time even with this optimization, and, I just can’t afford creating that many instances and then setting that many properties, the performance cost is too great.
I could avoid my size issue by storing the instances by a reference to their model type and if I really want to preserve small changes I can preserve those too. That’s what I’d likely end up doing, but, again, that severely limits me due to performance, based on some benchmarks I did it’d take upwards of 30 seconds of straight CPU time with minimal yields before execution time errors to load a medium sized map for me. That would cause disconnects if I don’t space out that usage enough, meaning in reality it might be closer to 40 or longer, which, is an incredibly long time for users to wait for a server to start up.
The thing with compression is properties that are default would really only have to occur one time when saved in a really really big list of instances so the amount of data that could be saved with something like LZ4 is still massive not to mention the fact that I’d be saving on any repeat properties and things. Considering most of the stuff I’m saving is made up of lots of the same instances just with small differences having access to Roblox’s binary format for instances would result in tiny file sizes relatively speaking.
This is definitely getting into feature request territory since my use case here doesn’t exist with Player:SaveInstance() but its still worthy to note that this is the last native feature that can do this afaik.
7 Likes
Aww, it was fun while it lasted. I’ve personally never used datapersistence, but some people have, and I feel like this just adds to the general variety roblox offers. Personally, I prefer a LOT of APIs even if some of them aren’t as shiny new as they used to be instead of just a few APIs that work and are kept maintained. In my opinion, it’s quantity over quality.
Can it save instances too(Without you serializing them)? If yes, that will be a time saver!
Does any new game even use the legacy Data Persistance system?
Reading through these comments are making me feel old for knowing what Data Persistence is, and when it was used while many haven’t even heard of it lol.
2 Likes
RIP the games I grinded 10 years ago.
Any particular reasons for removing them alltogether? To save data/money?
Won’t bother me much with my development, but sure, some memories and data will be gone from some old games.
3 Likes
I will be honest, I didn’t even know those existed. I haven’t seen anyone use nor talk about those. Although I’m sure not many games will break.
1 Like
I thought for a while now that they returned at most what the code would expect to be returned, and saving was disabled already, too?
I had a game use it (very long time ago) and it didn’t save data nor load it at all. I wonder though, in my use case it’d be amazing to have the ability to export said data before it was deleted if we are the place owner, or at least have that option to do so? In my specific case, a friend gave me his game to actively maintain and the data from his place in theory due to this would still exist. I have ported it over to datastores however, so no worries there. Although, the DP APIs do not save nor load data as mentioned before already, at least to my knowledge.
I hope the various improvements to Datastore mentioned here will improve data consistency and performance!
It doesn’t actually save in LZ4 format. It still saves in the oldschool rbxmx format that it was initially implemented with
It’s good to see that Roblox is slowly retiring old, unused services. Can’t wait for the next generation, DataStore v1.1
:SaveInstance() doesn’t save in the LZ4 format? That’s interesting. It makes sense, its been deprecated for a longgg time so it probably never got upgraded to the new format.
I still think there should be a better way to interact with the rbxm format, I’m going to create a feature request.
1 Like