DataStores Migration Packages for the Berezaa Method and DataStore2 Module [Public Beta]

Updates Announcements
#22

It does not. It always saves player data to the same key, and relies on session locking to prevent data deletion/duplication

2 Likes
#23

Thank you for this! Though I’d prefer to wait until after the BETA stage, I don’t want to ruin my game lol. Keep us updated please!

Update, out of curiosity I play tested this on studio, it didn’t even load my data :grimacing:

3 Likes
#24

What was the thing that changed again regarding limits?

The requests per minute?

Or like, how much storage there can be for all players in an experience in total?? or like huh?

And does numPlayers scale with the amount of players in total within the experience?

2 Likes
#25

Hey! Please see this post for the specifics - DataStores Access and Storage Updates.

As a high-level summary:

  • #(Requests per minute) is now per-experience rather than per-server, and as a result both the base limit and per-active-player (across the entire experience) limit have been changed accordingly
  • There will be a total storage limit of 100 MB + 1 MB * Lifetime Players.
3 Likes
#26

To compare it with, what was the previous limit?

Oh…

image
image691×146 10.7 KB

 

So, should one assume that a good rule of thumb would be to have data styled so that it covers maximum 1 MB per player?

While the rest of the 100 MB, is for other Experience things?

Isn’t 100 MB + (1 MB * lifetime user count) a better way to read it?

 

Does DataStore even come with a built-in feature to measure that?

:thinking:

image
image873×216 14.4 KB

I guess the new DataStore manager thing.

2 Likes
#27

Oh, I didn’t realize that. Thanks!

2 Likes
#28

Alright, thanks! shoot me a ping or DM once you have an answer, I’d appreciate it a lot.

3 Likes
#29

If there is one player on a server, the CCU is 1, right?

So, if I look at this right, you can basically send a little bit more requests per minute.

 

Now, the total storage limit, is that per data store or all data stores in an experience?

Like, let’s say you have a Data Store named Store1 and then Store2.

Do both have a separate limit, or do they all share the same one?

 

Is it per experience or universe? Like the wording is correct, right?

2 Likes
#30

iirc it’s across all datastores.

2 Likes
#31

Forgive me, but I am going to answer these a bit out of order!

Is it per experience or universe? Like the wording is correct, right?

The new limits will all be per-experience. So yes, if you have multiple experiences, they will each have their own set of limits.

If there is one player on a server, the CCU is 1, right?

Yes, for the current request limits. An important distinction though is that in the future limits, since the request limits will be at an experience-level rather than server-level, “CCU” refers to the total number players across the experience rather than the number of players on a server.

Now, the total storage limit, is that per data store or all data stores in an experience?

Like, let’s say you have a Data Store named Store1 and then Store2.

Do both have a separate limit, or do they all share the same one?

For the total storage limit, all data stores within an experience will share the same pool. So, all Data Stores’ sizes within the experience will be summed and compared to the total storage limit.

3 Likes
#32

So what this essentially means is we’ll be using the Players UserIds as the Datastores to store their values rather than using regular datastore identifiers that have player userids as the values?
Like

Levels > PlayerId > {1,2,3}

to

PlayerId > Level: {1,2,3}?

2 Likes
#33

I’m not sure I quite follow, but I’ll try my best to clarify the migration process here, using your example of “levels” you provided above.

Before (“Berezaa Method”):

  • 1 Ordered Data Store and 1 Standard Data Store for every player, named something like “levels/”
  • The Ordered Data Store saves entries that have a key-value of <anything> : <version / timestamp>.
  • The Standard Data Store saves entries that have a key-value of <version / timestamp> : <level value>

After:

  • Only 1 standard data store for levels named “levels”.
  • The data is saved as a key-value pair of <player id> : <level value>

So with your format above, I believe it should be this instead:

Level > PlayerId: {1, 2, 3}

3 Likes
#34

Just for anyone planning on using this statistic, if the player deletes the badge from their inventory and re-joins; they’ll get the badge again and (at least the last time I checked, it could have changed since) the total awardee count will still increment again. Players can also do this multiple times which could unfortunately make the stat a bit less than reliable depending on your particular experience and how many people are deleting your badges.

A bit off topic to this, but I also wanted to comment on the 100 datastore max limit in order to display more metrics on the “data store manager”. I use a seperate datastore per-player for logging Robux transaction logs; this allows for easily listing a particular player’s transactions but it came with the cost of being over the 100 datastore limit. In-hindsight I should have probably used the UserId as a key prefix instead but I unfortunately didn’t at the time. Is this a limitation which is presumed to change in the future or do I need to plan an eventual data format migration if I want to make use of it?

2 Likes
#35

Im not 100% sure if this provides full feature parody but worth checking it out.

3 Likes
#36

Okay, wait I think I didn’t think this through well.

Experience can only be a Universe.

So, sub-places share and inherit the same thing.

To get 100 MB, you’d have to make a new experience and not sub-place, that’s probably a rare use case and a funny workaround to accomplish something.

I got confused with the words “Experience” and “Universe”, for a second.

 

I was probably once thinking about making a test game that focuses on cross-experience datastorage. I believe, I’ve seen a test game somewhere before related to some RCC Fast Flag. :person_shrugging:

Now, in the documentation there’s rccPlayer. Wonder what that exactly means. https://create.roblox.com/docs/cloud-services/data-stores/error-codes-and-limits#server-limits

 

But all of this makes me think whether there will be methods that return remaining space, that you can display in-game.

2 Likes
#37

won’t work forever, people are limited to 200 active experiences iirc

you’re better off asking for people to just donate to you because if your game actually needs tons of data because people build in it, it probably will have a dedicated enough playerbase to pay for storage

2 Likes
#38

So, i do have to do this at some point? and do i have to rewrite much code to use normal datastores?

2 Likes
#39

I think it’s some compressed way to reduce file scale

2 Likes
#40

I can run out of test games and bug reproduction games?

Whenever that happens, I will complain. :thinking:

They should merge the experience limit with the friends limit

All users are able to build as many experiences as they want, though accounts are limited to 200 public experiences (able to be played by others)

https://en.help.roblox.com/hc/en-us/articles/203313950-Creating-and-Making-Experiences-Public
hmm

 

It says “able to be played by others”, so maybe it doesn’t count for private experiences.

1 Like
#41

So basically you save everything in a single key, reverting to the buggy system Berezza had fixed?