The devs told us they would increase this is we found a reason to

Feature Requests Engine Features
#1

The maximum limit for datastore:

60+(game.Players.NumPlayers*10)

Why do I want this? Well right now I have a 15 player game, I plan on increasing it to 50 when its finished, but even now I need more space, why?

limit = 60+(15*10) = 210

Now, Its for my city game, so I need furniture to auto-save 4 times a minute (I shutdown frequently so auto-save is the only option, if I do anything less than 15 seconds people can lose significant amounts of furniture placed down).

total = 4*15 = 60

That is already a problem, the fact that Im 1/4 there and all I did was save some simple furniture (all furniture is saved into one string, and just used as one slot in the datastore). Now, lets say Im going to save something like… lets say the inventory.

We are going to save this 4 times a minute as well (shutdowns can be rage inducing because they don’t save data):

total = 60+60 = 120

Now, I have the inventory saved, which is 500 items. I`m now over 1/2 to my limit. Now I need to save their in-game friends list so they can chat, as well as their in-game group. I can squeeze these two into one store, so lets see again now:

total = 120+60 = 180

I am now at over 3/4 to my limit. But I still need to save their tools and potentially weapons! (not the same thing as inventory. Inventory is used to save things like furniture which isn’t placed down. This is for the purpose of trading, a soon to come feature) So once again I must save 4 times a minute…

total = 180+60 = 240

I have now gone 30 over my limit, without considering the fact that someone may leave the server after their 4th save of the minute and take up another 4-5 extra total. I also have not considered the fact that players have save-slots in case they want multiple apartments to edit. This will take up at max 5 apartments, meaning that I have to check if they have 5 save slots, which is literally another 5 stores being used every time someone enters, on top of the other 4-5 needed to load their data.

My proposition?

limit = 20*numPlayers

Why? Well with some simple math we can see that:

10 Players: 200
10 Players (Old): 160

50 Players: 1000 (this is very reasonable for a full 50 player server!)
50 Players: (Old): 560 (What)

I would really appreciate even the slightest bump up, maybe 60+(15*numPlayers) if you can’t sacrifice performance or something. But I know I`m now the only developer who needs such saving, if you don’t believe that a game can load so much data, take a look here: Grand City of Robloxia - Roblox

Please consider my request, and thank you for reading!

#2

Soup port, the data limit is pretty damn tight ATM.

#3

Game.OnClose = funtion() SaveStuff() end ???

I do agree though; higher limits would be nice. [size=2]And a service that’s available more than half the time…[/size]

#4

Game.OnClose = funtion() SaveStuff() end ???

I do agree though; higher limits would be nice. [size=2]And a service that’s available more than half the time…[/size][/quote]

Game.OnClose is fired when the Server is shut down, not the client. So if a person was to switch servers, this would cause problems.

#5

Nick, tell me more about this secrecy… suppose I “Shutdown All” button’d and I wanted the server to save everyones data.

Suppose that this is the only code I need to be run before it shuts down:

for i,v in pairs(game.Players:GetChildren()) do
save(player, player.Money.Value, apartment)
end

?

#6

It works when servers are manually shutdown.

#7

Does it work every time, 100%? So theoretically I could tune down auto saving to one minute?

#8

100%? Ehhh, nothing on Roblox works 100%. If the server crashes, then it won’t work. But it should work most of the time :slight_smile:

#9

Crashes?! How often? Would it be safe for me to turn auto saving down from 4 times a minute to just once?

#10

“Does it work every time, 100%?”

Yes, the only time it won’t work is when the server crashes, which is exceedingly rare these days. You just have to make sure that it completes within ~30 seconds, or else the server say “time’s up!” and shut down anyways. (This means that you should save all your data in parallel in there, rather than sequentially, otherwise you could end up taking so long. So, Spawn() off a save for each player rather than just “for each player do player:SaveStuff() end” ing)

Also, may I suggest using the PlayerDataStore module that I made (Or looking at how it works at least, and adapting your own code to use similar techniques) It handles all the complexities of managing the request limit and saving on leave / server shutdown etc for you. It also packs all of the data for a given player into a single key, so that it only takes one request / user / save to save all of a user’s data: Documentation - Roblox Creator Hub

#11

You should be logging the information, then saving it after so-long.

#12

You’ve got to be kidding me, whole servers crash for no raisin often for me and I’m not the only one. Same with studio “oh there’s less crashing now” nope, that autocomplete likes to give studio the smackdown.

#13

You’ve got to be kidding me, whole servers crash for no raisin often for me and I’m not the only one. Same with studio “oh there’s less crashing now” nope, that autocomplete likes to give studio the smackdown.[/quote]

I have had neither of those problems…

#14

Don’t have any crashing problems but…

I’m all in for increasing the data request limit. Full support.

Yes, the devs think that the current request limit is more than enough to save simple kills, deaths, cash, points, checkpoint progress, unlocks, ect.

But when game developers like me want to expand the range of possibilities for players, we want to be able to save far more information and I’m already cramming around 15 different values in each table to save a ton of things.

For my case, my examples are:

  • the usual player stats (kills, deaths, assists, captures, points, cash, rank)
  • individual # of gun kills with each gun (I have at least 40 different guns in my game)
  • individual # of headshot kills, longshot kills, ect PER gun
  • total # of headshot kills, longshot kills, ect
  • tables of weapons that are unlocked
  • tables of attachments unlocked for each gun
  • tables of camo skins unlocked for each gun
  • table of current loadout
  • table of 8 separate tables for each custom class slot files that can be unlocked, purchased, saved and loaded
  • recording in-game purchases, keeping track of purchases that can expire (double exp bonus)
    and potentially even more to come when I need to expand

Not to mention I must retrieve all of this data and update it constantly as the game progresses.

The data request limit is currently limiting me from fulfilling these tasks

#15

I’m working on an MMO and I wouldn’t mind more space :slight_smile:

#16

“and I’m already cramming around 15 different values in each table to save a ton of things.”

There’s nothing “cramming” about it, you should be doing it that way, that’s the intended way to do things under the system: Storing a lot of data under single keys, and only using separate keys for pieces of data where there is actually a good reason to.

And also: Increasing the request limit is not a solution. I’ve spent a lot of time thinking about this problem, and I cannot come up with any cases that increasing the limit would actually fix other than allowing slighly more sloppy coding. All of the cases and techniques I can think of would either require piles more requests, due to the lack of table-joins and stuff like that, or would work under the current limitations if you’re clever enough.

That is, suppose that we increase the current limit by 3x: This would not actually solve anything. Doing any sort of join-like request (For instance, having a “friends list” in one key, and getting the list of friend names by looking up the name name for each friend’s ID from a separate table), would still be equally impossible as it is now. And any non-join like request would not be any more possible because you could just have been storing all the data in one key before as opposed to in multiple keys. The only case it would make a difference in is where you were nearing the key-size limit of 64K, which you probably aren’t on any non-large scale data that would have trouble fitting no matter how many requests you had).

#17

[quote]
And also: Increasing the request limit is not a solution. I’ve spent a lot of time thinking about this problem, and I cannot come up with any cases that increasing the limit would actually fix [/quote]

So this current request limit is final and unarguable?

I have no problem with storing a ton of data in a single table, but that isn’t the problem I have.

The problem I have is constantly retrieving updating these tables and being able to save it every time it updates, as opposed to a timed auto-save which would be prone to data loss if the player left before the saving occurred. And since there are many values that are constantly updating, the request limit to save the data is more apparent.

Maybe I missed something, but I don’t see why that relates to what you said of how storing a bunch of different keys would make increasing the request limit unhelpful or related to how I should be saving every time the values update.

EDIT: This may not be the case for the OP, who does actually go with an auto-save schedule. And as the OP noted, we already are saving a ton of data using a single table for each key, which I take your answer is to basically tell us to take all of these already large data tables and store it just under a single key.

#18

data serialization

from the middle out!

#19

Well there’s your problem! You should be queuing all your data and saving all the data every minute. Instead of DataStore requests, use a bindablefunction to server script that grabs the data when the player ends and autosaves every minute, with or without the player ingame. Just have it locally hold all datastore values and update the real datastore at some interval.

#20

“The problem I have is constantly retrieving updating these tables and being able to save it every time it updates,”

Yes, this is the problem. You should really take a look at my PlayerDataStore module and see how it handles the problem. You can both store everything in one big table for the most part and also only make one request every minute or whatever for autosave. If you do both the current request limit is easily high enough for everything except for things that still wouldn’t be possible even with triple or even more over the current request limit.

And that isn’t a “hack” or something like that: That’s the way real software works. No real game-server is saving to a datastore every single time that someone gets a KO, they do the same caching and batched requests that I’m suggesting that you use.

I’m not saying that the current request limit is “final” in any way, but I am saying that any increases to it will not actually fix the problem like you think they will.