I’ll cut straight to the chase.
What is my problem? Well it surely isn’t that easy to explain from my perspective, but I’ll try.
I’m looping through the workspace when the server starts, inserting doors (as instances) into a table based off of it’s level of required “Clearence” sort of like a keycard system, but with or as im attempting to, additional values such as…
However my problem is retrieving that Door from the global table when I needed it and checking and changing these values in the process. This is likely because of my horrible understanding of tables right now.
I believe what you meant to do is override the L1 index with Doorv. So instead of using table.insert (which is for arrays), you directly index for the value and set it with a statement
Well L1 is going to contain many doors, doorv is just everything related to that one specific door that had been looped put into the L1 doors category, to be used later.
I was just about to post something similar to this but @Prototrode beat me to it, what he’s put here will work @Nickaladormz, and will index your Doors by name rather than numerically.
for Doors, Door in pairs(workspace.Doors:GetChildren()) do
local DoorClearence = Door.Clearence.Value
local Doorname: string = Door.Name
_G.Doors["L"..DoorClearence][Doorname] = {Location = Door, Type = Door.Type.Value, IsOpened = false}
end
Now may I ask how exactly will I go about checking these values in the future if I need to?
Do I do something along the lines of like…
if _G.Doors["L"..DoorClearence][Doorname].IsOpened == false then
This thread has wrapped up so I won’t type anything long.
You should avoid using the global environment to store your values in a Roblox game, Luau optimizations (and packages [modules]) make _G essentially pointless and it just pollutes the namespace.
Another thing I wanted to add is you can also just use the Instance itself as the key in your table, such as;
local t = {}
local p = Instance.new("Part")
t[p] = true -- we can access this index through t[p] now.
This is a very common practice in larger games, and actually saves you processing in the long run (because if you store by name, you then need to search workspace for that door, which is extra code).
There are many _G alternatives available, but by far the most common one would be modulescripts.
You can do something like:
--inside modulescript
export type Door = {Name: string, Location: Part, Type: string, IsOpened: boolean}
local module: {[string]: Door} = {
L1 = {Name = 'a door (amazing)', Type = 'some random door idk', IsOpened = false},
L2 = {Name = 'a door (wow)', Type = 'very cool door', IsOpened = true},
L3 = {Name = 'a door (incredible)', Type = 'secret door', IsOpened = false}
}
return module
Although you definitely should endorse good programming practices, in your use case the Luau optimization is probably modest at best so it can be disregarded IMO. It only starts to matter when you’re doing a thousand table indices per frame or something, so deoptimization is negligible
Do what you prefer best. If you don’t believe using global tables would significantly impact your game’s performance, you can keep using them if you want. Especially if you think using alternatives is much more troublesome.
This is a reason in itself. Deoptimization concessionally is pointless, not negligible.
This again, is enforcing bad practices. Code should be designed more modularly if it is modern. _G is random pollution to the global namespace and a hassle to debugging. You can get turned away from commissions/work for using _G, it is outdated and bad practice on Roblox. You also don’t get any auto-complete.
Now using way better methods, I’ve completely disregarded the Global Defined variables and rather using Module scripts for this, and I will continue to do this from here on out with plenty of things as it is indeed more efficient, again thanks for the input.