Edited the previous post, should work now.
1 Like
What are the advantages of holding it in a script compared to instances?
Can you test it out?
Doing so now.
Just tested, it appears to not error but I don’t believe it’s saving.
Either it’s not saving or it’s not loading the data.
As I thought, you are saving the wrong variable. You should be proceed the for loop with the q variable.
Will try that now.
Hm, saving the q variable isn’t doing anything either.
There’s little difference in terms of performance/memory. Many developers prefer using tables over value-storing objects because they find the latter unnecessary and see it is as bad practice. If you find using value-storing objects easier, use value-storing objects.
1 Like
In addition, it is easy to possess this data (when in a table) and manipulate it when necessary.
1 Like
Hold that thought, I had the input value thing commented. Testing again.
Okay, the issue was that I was looping the guns children and not the guns colors children.
Everything works now and I thank you SO MUCH!
Working script:
function generateDataTable(player, folder, datastore, ifSkin) -- With the skins, we have skin colors for each guns so we need to loop twice. ifSkin will be true or false
local iTable = {}
local newTable = {}
for index,v in pairs(folder:GetChildren()) do
if ifSkin == true then
for index2, z in pairs(v:GetChildren()) do
print(v.Name, z.Name, z.Owned.Value)
newTable[z.Name] = z.Owned.Value
iTable[v.Name] = newTable[z.Name]
end
else
iTable[v.Name] = v:WaitForChild('Owned').Value
end
end
for i,v in pairs(iTable) do
print(i)
print(v)
end
return(iTable)
end
function saveDataForPlayer(player, folder, datastore, ifSkin)
local key = "uid_"..player.UserId
local data = generateDataTable(player, folder, datastore, ifSkin)
datastore:SetAsync(key, data)
end
function loadData(player, myFolder, datastore, folderToUse, ifSkin)
local key = "uid_"..player.UserId
local data = datastore:GetAsync(key)
inputDataToPlayer(player, data, myFolder, folderToUse, ifSkin)
end
function inputDataToPlayer(player, data, myFolder, folderToUse, ifSkin)
local f1 = folderToUse
if data ~= nil then
print('Uploading data')
for i,v in pairs(f1:GetChildren()) do
for _,mm in pairs(v:GetChildren()) do
local TableOfValues = {}
for e, q in pairs(data) do
if v.Name == e then
if ifSkin == true then
TableOfValues[tonumber(#TableOfValues+1)] = q
for nm, dw in pairs(TableOfValues) do
warn(dw)
warn(nm)
end
warn(v.Name, q) --q.Owned.Value)
mm:WaitForChild('Owned').Value = q
else
v:WaitForChild('Owned').Value = q
end
end
end
end
end
else
error('Data is nil')
end
end
Make sure to mark one of my posts as the answer then. 
1 Like
Already did!!
@Dandystan There are differences. Putting value object in the game incurs overheads and then make the data freely available to the whole game.
Using a table is preferable mainy because it does not take any additional processing (unless you are compressing it or have a need to save the data in a different way which can only be done on a save) meaning that you are making the save request as soon as possible. There are no additional tables which need to be created then discarded for the sole purpose of saving the data.
The second advantage is that your data can only be accessed in code. This means you can use some OOP to ensure the integrity of the data at this level instead of potentially having each script doing checks on if data can be set / is within what is expected.
I made a very quick example here:-
3 Likes
If you are doing it this way, you need to make sure you remember commas between each value. That dictionary layout would error.
local table = {
GunName = {
Color = true,
Color = false,
Color = false
}
}
Though I really don’t think that is the way you should do it. Much easier to use a table and have each gun with each value so like this.
local table = {
GunName = Texture/Color,
GunName2 = Texture2/Color2,
GunName3 = Texture3/Color3,
--Keep adding more values this way and loop through this table using the gun name values.
--Additionally, by doing it this way, you don't need every gun indexed, if let's say, it isn't unlocked.
}
1 Like
You don’t need a comma for the last value in the dictionary.
Notice how it says keep adding more values below, so I added one.
Yeah my bad about the comas, it was just for an example and I forgot them.
1 Like
I think you should be more ambiguous with your code, rather than explicit. Create one “super table” that would act as the data that is intended for saving. Then, while iterating through your data, convert folders to key FolderName value Table and ValueObjects to key Name value ValueObjectValue, then return that for saving.
Hey consider using this module script. Whenever I used to use folders for data before switching to Object Oritented Programming data I used this script here.
1 Like