Hello! I’ve been playing with serialization, but i’m still having these warnings as new people join the servers. Any thoughts? The data is being loaded after a little bit, but i just wana make sure this isnt gonna cause me a problem.
1 Like
Serialising and requests being added to the queue are unrelated. This is typically an issue when you have too many DataStores operating at one time and the amount of requests pile up past the budget - that which I’m assuming based on the warnings issued in the console.
There’s no code so other than reading the warnings, it’s difficult to determine a source for your error. The only assumption I have is that you’re using too many DataStores and by the format, that’s DataStore2. Exactly how many DataStores are you opening per player?
There are currently 6 datastores and i’d like to if possible keep them seperated if there is a solution to this. The stores are as follows:
- DailyRewardsStore
- CharacterInfoStore
- InventoryStore
- MagicValuesStore – This is all the values regarding magic and power levels and magic color and stuff
- SpellsStore – all the individual spells and levels of each spell
- NPC_Info_Store
So, you by your comment i assume you are familiar with datastore2? If so, would combining the stores with datastore2’s api help?
6 stores is too many. With added consideration to the way DataStore2 fetches data at 2 requests per DataStore (OrderedDataStore → GlobalDataStore), that’s 12 requests per player for fetching alone. 12 is 2 requests over the per-player grant (10x where x is the number of players) and eats into the base budget (60). All according to DataStore server limits.
I’m not particularly familiar with DataStore2 since I like to write my own code, but what I know is that DS2 is meant to facilitate various DataStore processes for you, so any practice tip in working with regular DataStores most likely also applies to DataStore2.
Consolidation of DataStores is the answer here, meaning you need to bring that number down from 6 to something closer to 1 if at all possible. Are you able to provide a template or explanation of what you save to each DataStore?
1 Like
Yes.
DailyRewardStore: Saves the time that the player last claimed a daily reward(Could be consilidated into the characterstore)
CharacterStore: Information regarding the character; the char name, description, amount of money, and all of the rthro scalling features aswell as equipped items and such.
InventoryStore: Saves all the item data. Within each item in the dictionary is another dictionary filled with values regarding the item such as the worth(which may varied from player to player according to upgrades) and the character slot(If its an item equipped to the player) or the toolbar slot(or if its an item equipable to the toolbar) aswell as the amount the player has, and the items type and description.
MagicValuesStore: All the level values that effect the magic(the main system of combat and such and the basis of the game) There are many level values for 5 different mysticisms and chargeoutput and base power level. The color of the players magic, boosts etc.
SpellsStore: This is probably the largest store so far, it holds all of the spells, each spell is a bool value for whether or not the player has learned it or not, and then there is a corresponding value for TheSpell…“Master” which is the progress of each spell for the player, as you practice spells they get stronger.
NPC_Info_Store: Is all of the player to npc data, such as the amount of times you’ve met with maybe a story npc which catalogues what the npc will say to you, aswell as if the npc is in an active state to commence a story or not.
Ooh, that does look a little difficult to consolidate.
DailyRewardStore can definitely be moved to another DataStore. It seems like it’d be more appropriate to move it into CharacterStore since that seems to be the general data store (assuming this based off of the fact that the money amount is sent here). That would bring it down to 5 DataStores, 10 fetch requests.
Depending on how large MagicValuesStore is, you can move that to a slot in CharacterStore. If it doesn’t use arbitrary entries and there’s a definite amount of entries there, you can plug it into its own slot for CharacterStore. Make sure to bring data sizes down as much as possible to make room. If that can be done, 4 stores and 8 requests.
In terms of the NPC store, what generally do you need to save for future interactions? I usually don’t save any kind of NPC information in DataStores: I instead make their interactions based off of player circumstances. Usually it comes with some drawbacks for me such as hard-resetting quest progress but I find that a better gamble than to deal with potentially corrupted data.
I’m out of ideas beyond here so I can keep looking into it.
This is everything in the character info store:
CharInfoStore:GetTable({
CharName = "";
CharDesc = "";
Aires = 30;
["CurrentLand"] = "Bouldaron";
["Gender"] = "Male";
["Tool"] = "None";
["Skin Tone"] = {255, 204, 153};
["Face"] = "Man 1";
["Full_Set"] = "Violet Velvet Robes";
["Upper"] = "Default";
["Lower"] = "Peasent Pants";
["Hair"] = "Blonde Flowing Hair";
['Head Wear'] = "None";
["Back"] = "None";
["BodyTypeScale"] = .03;
["DepthScale"] = .8;
["HeadScale"] = 1;
["HeightScale"] = 1;
["WidthScale"] = .8;
})
This is everything in the Magic Values Store:
MagicValuesStore:GetTable({
Architype = "Lavender";
Power = 5;
Progress = 0;
Points = 8;
Energy = 400;
CurrentSpell = "None";
MaxEnergy = 400;
Sorcerer = 0;
Psychic = 0;
Druid = 0;
Imagineet = 0;
Necromancer = 0;
["MagicEnabled"] = true;
["Immunity"] = false
})
i’m working on getting a clear answer from the creator of datastore2 about whether or not the Combine function is the way to go to fix it, becuase datastore2 is made to hold a lot of stores
Here, read this and tell me what you make of it.
Oh, you can definitely put those two DataStores together into one, since it seems like all the needed values for the DataStore are present at the beginning. You’ll just have to make a bit of space within your DataStore to be able to save all that data and apply certain reduction techniques here.
-
Make sure the name and description fields are capped at a certain character limit. This is also good for UX, since it forces players to write little and focus more on playing. Others don’t want to read giant descriptions either.
-
Make sure to use ids. This allows you to make an associative system where a certain id corresponds to something. Id systems can vary between implementations but the goal is to associate only a few characters with a potentially larger value.
-
Example: Instead of Bouldaron, you can make this “11” (first 1 describes the customisation type, second 1 describes what the item is). When the data loads and your scripts are going through it, it can read CurrentLand as 11 then search a table where 11 corresponds to Bouldaron.
-
Another example: Instead of Male, use 1 and 2, so on as needed.
-
You can apply ids to the following: CurrentLand, Gender, Tool, Face, Full_Set, Upper, Lower, Hair, Head Wear and Back
-
-
Have a good way to separate each section of data from each other so they aren’t comingling or bothering you when it comes to maintenance. It can be as simple as two keys, A and B, where A is character information and B is magic. Data saving, as far as anyone is concerned, is an internal game process and convention only matters to you.
In terms of Combine as you mentioned below, I do believe this would get rid of the need for 6 DataStores as it’d save everything under one DataStore as a giant dictionary, but you may encounter issues when it comes to how large that DataStore becomes. Combining a few could work though, feel free to give it a try so long as you know it won’t affect data later.
I appreciate you taking the time to write all of this out for me. I’ll take a look at it.
My understanding of combined datastores is literally just taking the datastore keys that exist, say for instance the 6 previously listed, and putting them into a master key.
Another thing, i have all of the items as the names of the items in their folders and catagories and all that, how would you recommend i index all the values of these so that i don’t have to continuously add it to a table of keys… and because the use of the data is spread through many scripts using the aero game framework to keep organized. Could i just loop through all the relevant folders with GetDescendants upon the entry of the player? And it adds them to a dictionary with [“Pointy Hat”] = 45, for instance? That way when i wana get the key, whatever item is in question, it finds the dictionary value in the store and then applies it.
Or vise versa: 45 = “Pointy Hat”
fyi, i do have serializers in place…
Yeah, that’s exactly how combinations for DataStore2 work. It’ll get rid of your queueing requests at the very least but then the rest is up to you to resolve.
I’m not entirely sure what you’re asking within the second question. Are you able to clarify a bit as to what you’re thinking of doing? Is it in reference to the id system? As I said, that’d vary from implementation to implementation. Anything works as an id so long as you can link it back to a specific object.
Yes it was in context of the id’s, my issue is i have many scripts that will have to index those ids, and i just wana find a nice quick solution so that even when i add values later i don’t have to constantly add the new items into all of the scripts id lists
Ah. In that case, you’d be looking to have the id as the index and the actual item as a value for your identification list to determine what id corresponds to which asset. With an id system, you will have to do some hard-coding which just involves adding an id and an asset to a list.
Looping through with GetDescendants is acceptable. So long as you have a list of ids and what those ids are associated with, the rest of your scripts should have no issue in trying to index and get items. As an example scenario in some implementation, ids[player.data.hair.value] would return “Pointy Hat”.
I don’t think i fully understand quite yet the details you are trying to explain.
And with regard to the putting the ids in the list… i would just loop through the items list which has layers of folders, and use the item number in the list as the id… put that into a dictionary as the name of the item it looped through… and its id value.
Oh, you mean to say you want your script to automate ids by a descendants for-loop and using the i variable as the I’d in a dictionary? For sure, you can, but you’ll need to run a few tests in regards to that. Order is never guaranteed and you may run into some issues with IDs not being consistent, if done at run time.
What would YOU do then? because i have a lot of data that is to come aswell, and a lot of places i have to indentify the data… and atleast 9 different scripts i’ll have to go through to add the ids, and when items or values are added, i’d deed to go through all of them again and add them.
Me personally? I’d hard-code all the ids into their respective lists with the index as the id and the value as the actual item. That way, when it comes to data manipulation I’m only working with ids rather than long strings. In the case of needing to access something, I just have the script look through an id table with the index being the queried id. That returns the actual item for use.
Doesn’t matter how many scripts there are, they all follow the same process of accessing and reading data. There isn’t a sudden workflow change just because several scripts need to access something. They always work in ids with the value of the id being the literal object.