Hi, I want to make a datastore system in which I not just store the position of objects on the grid but also objects in the inventory. I’m not really sure on how to tackle something like this without creating a separate datastore which I want to avoid doing so as I already have one for something else.
The grills that the player has bought will be located in the inventory, and removed when the player has placed it.
I plan to save the CFrame of the object placed on the player’s grid in the database as well, and when the player joins another server and claims the plot, the object positions will be loaded in their grid and they would not have to replace everything.
Currently my idea is to basically insert a StringValue to the player for each grill in the database and perhaps save it all in some way afterwards when he/she leaves?
I’m not sure how I would save the objects that are in the player though as I can only account for the plot itself. There may be errors as well because I’m writing the script and haven’t been able to test its success yet.
You should be able to serialize the entire contents as basic data with a bit of extra setup and just repopulate the inventory and grid with the appropriate items from the single table already in use as needed.
So basic dataStore theory:
Items owned recorded something like table to define each items stats, table to name “itemID = item” for easy reference, another to the datastore for a list of itemIDs and quantity owned by the unique playerData.key. ~ Basics most people use the datastore for right so for you we add in an extra stage:
playerSaveData = ownedItemIDs + ownership of GridID(x) --to make it easy to transfer both from grid to grid and inventory to grid-- and then rather than attempting to have every itemID store where its been placed in Vector3 do it the other way around since your grid already records the item info!
Define smaller areas of the grids and have the datastore keep track of whats placed/removed:
PlayerDataKey:1234
Coins: X
ownedItemIDs: XX [all of which can be in inventory or grid but not both]
GridIDOwned: Z (easily changeable)
Space 1 = Vector3 = item is placed = true > itemID:1234
Space 2 etc
if the grids are smaller/larger in size simply add more numbers for the larger grids and prevent placement i.e. gridID:7 = Available Space 1, 75 and only populate those items.
Additionally all items owned by this player.Key if not recorded in Space 1, 100 = available in inventory as GUI icon.
It would have a constant record of whats in the inventory, whats on the ground, and where it’s positioned, if the player changes grids the items are still owned, and still in “space 1, space 2” and easily moved from server to server.
Thank you for taking the time to write such a constructive reply. Just to summarise what you’ve said to check:
I will apply serialisation to basically be able to return the array or table in this sense for my UpdateASync method
-As for the grid squares, I have a problem in which the size of the object may differ in which I was planning to use ToObjectSpace and WorldSpace in order to load them in correct positions and rotate them whenever necessary since the grids are fixed.
I have to trouble you for a further explanation on this.
For your suggestion, how would I approach grid squares in particular to address this differing size complication? Do I just divide the grid and use math.floor/ceil accordingly to segregate each space to respective squares? Wouldn’t I still have to track the Vector3 of said objects to identify which square they’re on too?
Yeah I was guessing how much detail you needed, assumed it was already probably in cubes with simple orientation and set item sizes but it should still work with extra variables, might have to organize in another manner.
So you say the grids are fixed and items just rotate, is that just a simple 4 face directional placement? The placement options you have on the grid now is it by and item rootPart to preset anchor spots and the items can just cover 1, 2, 3 as needed by size of the item or is it free placement?
Do you have the option for them to scale an item larger/smaller or just larger and smaller items?
The grids I intend to make them fixed and with the items just rotating, so yes it’s a simple 4 face direct placement. What I’m planning to do is when the object is placed, I’ll just anchor them on their spots and the items just cover according to their size.
My difficulty is for the tier 2 size though as you can see in the left in terms of setting fixed boxes for each oven, it’s a 3x3 version of the original oven size (the icey blue one at the right of the grid) so I was planning to just have CFrame with toobjectspace positions saved in DataStore and use toworldspace to move them to the correct place. For the grid squares, I was planning to make only two being allowed to be placed at a time for tier 2s and 6 for tier 1s?
So the area will not filled to the brim side by side stacked its only a handful of items potentially placed?
Simplest solution is make however many anchor spots around the grid you want for customization and designate for T1 / T2 only. Check item to anchor location still as the original example. Then you know this space is a T1/This one is T2 no chance of overlap and only have to say item>achorpoint>faceofitemisN.
Slightly less custom layout potential but I feel like it would save some performance/coding difficulty maybe?
I think I get what you mean. Can I trouble you to provide an example of what you mean by anchor points? Do you just mean invisible blocks that indicate where placement would be?
Yeah an indicator would help player side then hmm… maybe just create two weld constraints to each grill one center one toward front then part T1 centerweld1 can go here-here-orhere and make 5 grid welds in a + layout for the space to tell you which way forward is when it detects the forward facing weld.
local Part0 = --Reference to BasePart here.
local Part1 = --Reference to other BasePart here.
local Weld = Instance.new("WeldConstraint")
Weld.Part0 = Part0
Weld.Part1 = Part1
Weld.Parent = --You can referece to any object you want here.
Define the weld on the item by a unique ID and when weldItemID=weldspot1(center) & weldspot 2(front) you have your location and orientation.
Could just handle the center weld and detect front another way im just trying to picture how the layout for the datasave will be and it sounded easy to handle/read later but would take a little extra scripting for the grid spaces this way to define acceptable itemwelds/spot.
Not sure it’s the perfect way but I think it would work?
