Could using a different scope on a datastore be an alternative for making a completely different datastore?
Do you perhaps mean using a different key in the same data store is like, “creating a new data store”?
No.
No, I mean the scope. Not key. Is using a different scope of a datastore an equivalent to making a new datastore
The solution to that topic explains scope.
That’s the exact post that GOT me this question. It says that it’s like groups for a datastore, and compared them to folders on a computer. So, could this be equivalent to making a new datastore? If the scope is storing completely different information than other scopes.
Yes, it is the equivalent to making a new data store. Any information stored in one scope, will not replicate to another scope.
The implication of the folder analogy is that files you put into one folder are not present in another. By using a new name and/or the scope, you are creating new folders or subfolders to store items in. When you make a new folder, it doesn’t inherit the contents of another, so yes it is like creating a fresh store.
Scopes are often good for iterated testing when you need to differentiate between production and testing DataStores should live and testing places be present in the same game. Of course, this will depend on your use case, but with the storage limit increase you will have very little reason to be hard-partitioning with scopes unless you’re storing massive amounts of data (e.g. player builds or whole articles for a community content-driven game).
In short: use the scope if you want, or don’t. You probably won’t need it anymore due to the limit increase, though you may have a use case where you’re saving more than 4MB of player data even after compressing it. This is where you can use scope to define parts of data.
Even shorter in short: Name, scope and key are all options you can use to better organise your data, they have no real functional difference. You can also use the value to organise.
3 Likes