There is now an article on this Module on the Wiki:
I must ask… any throttling limit?
Well, if you only call Get and Set then you never have to worry about any throttling limit, the module will make sure to stay under the limit.
However, as for Flush and Update calls, the module will have whatever the underlying DataStore has as a throttling limit, since that’s what it’s using in the backend.
[quote] Well, if you only call Get and Set then you never have to worry about any throttling limit, the module will make sure to stay under the limit.
However, as for Flush and Update calls, the module will have whatever the underlying DataStore has as a throttling limit, since that’s what it’s using in the backend. [/quote]
Awesome… wait, does :Flush() clear the catch? I am confused. 
Very cool! I probably won’t use as I prefer to make my own back-end (experience 
).
A question: what’s the best way (or a good way) to give teleport reason with DataStores. Like some sort of system that, when teleporting players, sets a value so the retrieving server knows why they were teleported and from where they came.
" what’s the best way (or a good way) to give teleport reason with DataStores."
By just… doing it? Once you have a system set up for storing data attached to a player (Like this one), then you can just use one of the player’s keys to store a teleport reason.
“wait, does :Flush() clear the catch? I am confused.”
The idea of this module is that it will not actually save to the data store right away when you set keys, but rather wait until a good time and save all of the fields that you changed all at once with a single data store call. Flush() will manually force it to do one of those saves, if for some reason you really want some important changes to be committed to the data store right away.
[quote] " what’s the best way (or a good way) to give teleport reason with DataStores."
By just… doing it? Once you have a system set up for storing data attached to a player (Like this one), then you can just use one of the player’s keys to store a teleport reason. [/quote]
But what about the cache? If I update a value on teleport is it going to be updated in the new server?
“But what about the cache? If I update a value on teleport is it going to be updated in the new server?”
The cache is per-game-server (it has to be, this is just a normal Lua module, I can’t do anything else). There are a couple of gotchas:
-
You should call a Flush() after writing the TeleportReason to the player but before you do the teleport, to make sure that the TeleportReason and other local data is actually saved to the main data store before the player arrives in the new server and their data is loaded in there.
-
If you have a large 50+ person “Lobby” server or something like that, then you should set the CACHE_EXPIRY_TIME to be a bit shorter on it. This is because if you teleport out to one of the other universe servers, and then teleport back to the same lobby server all within the CACHE_EXPIRY_TIME the changes in the other server will get lost, because the lobby server will “pick up” the cache entry that still exists on it. For normal games this scenario is almost impossible, but if you have one large lobby server and a lot of small game servers which you can exit back to the lobby from it can come up.
[quote]
2) If you have a large 50+ person “Lobby” server or something like that, then you should set the CACHE_EXPIRY_TIME to be a bit shorter on it. This is because if you teleport out to one of the other universe servers, and then teleport back to the same lobby server all within the CACHE_EXPIRY_TIME the changes in the other server will get lost, because the lobby server will “pick up” the cache entry that still exists on it. For normal games this scenario is almost impossible, but if you have one large lobby server and a lot of small game servers which you can exit back to the lobby from it can come up. [/quote]
Well, honestly, when a player leaves the lobby you should just erase his data from the cache, as it was just temporary.
“when a player leaves the lobby you should just erase his data from the cache, as it was just temporary.”
This is incorrect, if anything the time to erase data from the cache is when the player joins the server, not when they leave. Consider the case where you have a global leaderboard using this module: If you purge the player from the cache then they will be added back to the cache right away as soon as the leaderboard goes to update. The time you need to purge them from the cache is when the player enters the server.
I ment, on leave, flush the data, then get rid of the cached version.
Of course, like you said, force loading on join works also, unless the previous server didn’t save it yet.
Does one’s data get automatically flushed when leaving, or does a script need to manually do that?
Other than that question, it is cool. :DDD
Is it possible to call the PlayerDataStore module on a player that has not entered the server (Ex: Banning someone for hacking and stuff), or is a different system needed?
“Is it possible to call the PlayerDataStore module on a player that has not entered the server”
Yes, the system doesn’t care. You can use “:GetSaveDataById( id )” instead of “:GetSaveData( player )” to get the data for an arbitrary userId that may or may not actually be in the server at the time.
[quote] “Is it possible to call the PlayerDataStore module on a player that has not entered the server”
Yes, the system doesn’t care. You can use “:GetSaveDataById( id )” instead of “:GetSaveData( player )” to get the data for an arbitrary userId that may or may not actually be in the server at the time. [/quote]
Awesome, now I can get a legit ban system in place. 
This seems like a good place to ask this:
My game saves strings anywhere from 0 to 1,800,000 characters long (10s of thousands is for a small fort, 100s of thousands for a good city, and a million to 1.8 million for ridiculously detailed floating island cities.)
I use Data Persistence right now. I can save million-long strings at once. Cons: instability (as evident with the many instances of people’s DP getting wiped, roblox.)
Data Store seems to be limited at 65,500 characters long for both the key and the value combined. Pros: stable saves, accessible if they’re not even there. But that arbitrary limit does not bode well for the throttling.
Can this solve my issue Stravant? If not, what can I do?
You can only use DataPersistence for that. What you really need to do in that case is have some sort of blob-store (Which the DataPersistence actually is). The DataStoreService is not intended for storing that sort of big-data value. It’s meant for storing data attached to players and what not, various statistics, not for storing giant chunks of game-state.
On the other hand, you can ask yourself: Do I actually need to be storing that much data? Do you actually have a MB+ worth of data to store? Or are you actually only storing a few KB worth in a not very efficient way? I have a feeling that you could actually be storing quite a bit less data than you are.
If you are dealing with chunks of data that large, you should use HttpService and a remote database.
I can save a model with a bunch of different types of changes at about 150 characters per brick. That’s terrible, I know. But it is 17x better than DataPersistence saving Instances as DataCost for Instances is through the roof. (Speaking of which, .DataCost is a read-only value that is RobloxLocked… why.)
I can’t hope to match the compression rate of saved places (which is more than 10x better than what I have?). I’ll try this httpservice out… knowing nothing about the limitations. x-x
The only limitations you would have with HttpService are those of your server/site.
(And the amount of requests HttpService can do per minute, but that shouldn’t matter here)