How to check how much data is being used in a data store

Help and Feedback Scripting Support
#1

Post I referenced: Calculating how much data is used using datastores?

From what I can see on the devforum, this is how you would check the data being used:

local success, errormessage = pcall(function()
	data = Http:JSONDecode(MyDataStore:GetAsync(BuildsKey))
end)

print(string.len(Http:JSONEncode(data)))

The script prints 205,955 every time. Does this mean that it takes up 205,955 bytes? If not, how can I convert the length of the string into bytes so I can check the total amount of storage?

After looking it up online, there’s about 4 MB total in the datastore, and currently 2,259 parts in my game (i’m saving the position, orientation, and name of the part, and also the player’s UserId who placed the part)

Roblox Data Store Manager - Incorrect Usage
#2

A single datastore key can have a value of upto four megabytes in size assigned to it.

The script prints 205,955 every time. Does this mean that it takes up 205,955 bytes?

Yes, this is roughly accurate, all standard characters are represented by a single byte (numeric characters, alphabetic characters, punctuation characters etc.), the majority of characters that require 2-4 bytes to be stored are seldom used.

Would you mind sharing the current format/pattern of how data about a single part is stored?

3 Likes
#3

Sorry for the late response, this is how I am currently saving the parts with their information. I make a table of information about the part including the name, position, orientation, and UserId of the person who placed the part. Then, I put that table into one big table which stores the properties of all parts I want to save, and I use JSONEncode/JSONDecode to save and load the information to the datastore

	local PartsToSave = {}

	for i,v in pairs(workspace:GetChildren()) do
		if game.ReplicatedStorage.Builds:FindFirstChild(v.Name) then -- if the build can be saved then
			local PartProperties = {
				["Name"] = v.Name, -- name of the part
				["Position"] = {v.Position.X,v.Position.Y,v.Position.Z}, -- position of the part
				["Orientation"] = {v.Orientation.X,v.Orientation.Y,v.Orientation.Z}, -- orientation of the part
				["Placer"] = v.Placer.Value -- person who placed the part
			}

			table.insert(PartsToSave, PartProperties) -- add the "PartProperties" table to another table called "PartsToSave"
		end
	end

local BuildsKey = "builds_save"

	local success, errormesage = pcall(function()
		if CanSave == true then
			MyDataStore:SetAsync(BuildsKey, Http:JSONEncode(PartsToSave))
		end
	end)
#4

That’s fine, you could compress positional and rotational data by locking placed parts to a 1x1 grid with 90 degree rotations. I’d also recommend storing the player’s ID instead of their name as the former is static whereas the latter is dynamic, on a final note you could store parts with an index, i.e; 1 through ‘n’ where ‘n’ is the number of parts, as opposed to storing each part’s name.

#5

Right now, I am storing the player’s UserId so players won’t lose a build if they change their username

Locking the part on a 1x1 grid or 90 degree rotations wouldn’t be possible in my case because there is an option while building to disable snap to grid, and rotation increments are at 15 degrees

The reason I need to store the name is because I’m trying to find the type of build in the folder called “Builds” (showed in the image below) then I can clone the build from the folder to the workspace, and apply the position/orientation

image