Currently I’m working on a pretty basic inventory system, however, when I attempted to get into tables/metatables, it got confusing very fast. So at the time, I made it so collecting an item stored the item inside the players PlayerGui as a physical object/model. And I wanted to know if there were any drawbacks to using this method?
In short, here’s how it should be;
You click an apple, the apple sends an event to the server, saving it to the players inventory table in the code.
And here’s how I made mine;
You click the apple, the apple fires a module to insert itself into your playergui, and is stored there in physical form, instead of a table.
Are there any drawbacks to storing objects in this manner besides saving it as a datastore? Does this slow down the game? Is it more secure? Etc, etc.
The only possible drawback I could think of is it’s harder to save player data, and that chests/a lot of players could impact performance if they all have items, but even then the items are stored in the gui of the player, so there not rendered, meaning it technically shouldn’t cause any issues.
TL;DR
Items are stored in the gui of a player, rather than a table/metatable. Is this okay?
Thanks to anyone who can help.
I think storing items in a table would be a lot simpler. You can do it like this
local inventories = {-- contains all of the player in the server's inventory
["Playername"] = { --Name of player
["Wood_Log"] = { -- Item
Amount = 64 -- Item Properties
ImageId = "69696969"
};
};
}
In the future I’ll probably change it, but for now it only uses the physical object to display it in a viewport frame, the actual count of the objects stack and what not is handled by a module.
If we use the tables, it will be easier to save and this would cause lag for the player, when a player plays a game, this one loads scripts, objects or other, it will be preferable to use the tables anyway , but otherwise, the use of physical object sela becomes a real headache, it all depends on if the player can leave and join with the same tool to physically record, then the more the player will have of objects the more the calculations will consume on the computer, so at this exact moment the player is going to lag at the start of the load, but depending on the usage, for example if the script is still calculating the physical inventory or is being saved, it will make the game more heavier than with tables that load faster.
Nope! Less secure. Storing things on the client is never secure. You would want to store the “master copy” of the inventory on the server. But that can apply to either tables or folders.
Everything’s really just a table, even if it calls itself an “Instance”.
1. Don’t worry about metatables. Seriously. Most Roblox workflows shouldn’t need them, and I have a sneaking suspicion that that is where most of your confusion is stemming from. Concentrate on understanding basic tables, iterating through them, the differences between standard tables and dictionaries, and it should be good enough knowledge for 99% of your projects.
It would be difficult, and needlessly inefficient, to store player information without using a table.
How do you relate the item that you have (apples, swords, whatever) to its quantity?
How would you know that you have saved/loaded all player inventory data? You’d likely have to run through each item key, check if the value is nil, and load if not. This would dramatically increase loading and save times (1 get/write request to potentially hundreds).
You can not store instances (e.g. parts, models, etc.) as they are in datastores. You would have to store them as either a list of strings with a given value (see above for why that is a nightmare) or store the inventory as a table (the optimal solution).
BUT (and this is a big but)
It should be* okay to represent the inventory of the player as a collection of items in the UI on the player’s end. I mean, that’s how the backpack works (objects are parented to the Backpack, or the player’s character when equipped). Sure, it may be better to have just a table representation on that end (and it could be added as a bonus), but you save on having to clone the object when equipping the item.
As of right now, the inventory functions no different to a standard one using tables.
Items are stored based on their name, and are put into a viewportframe on the inventory. Inside that frame is a number value where it stores the stack amount/quantity of said item.
I have a module that goes through and can sort out items, drop them, move them, even equip them.
And saving isn’t added yet, but I was planning on just using a crude loop to go through each slot and mark down what’s in it and the amount, and put that info in a table to save as a datastore.
Needless to say, tables are 100% better, I just don’t want to rework my inventory system to be entirely honest. Anywho! Thanks for the information. I’ll just mark this as the “solution” as its the latest reply as of now.