Not Understanding Tables Entirely?

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…

and here is what I mean by Clearence like table,

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.

Why indexed as “1” and not the name of the door?

Anyways, I’ll show any additional code if needed to better explain myself. Sorry for being a bit dumb lol.

1 Like

Can you show us the code where you define “TestDoor” please?

Basically I loop a folder containing the Doors,

for Doors, Door in pairs(workspace.Doors:GetChildren()) do

what determines where it goes in the global table?
The Clearence level. Which is either 0 through 4.
So, this is how that happens.

Does this help Elaborate, I hope it did.

Arrays are naturally ordered numerically; it is also done automatically when no keys are given for index declaration

local t = {'abc', 'def', 'ghi'}
--is the same as
local t = {
  [1] = 'abc',
  [2] = 'def',
  [3] = 'ghi',

What you did with your code is that you’re inserting the table Doorv into the subtable L1 in the Doors global. It looks a little like this:

_G.Doors = {
  L1 = {
    {Location = Door, Type = Door.Type.Value, IsOpened = false}

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

_G.Doors.L1 = Doorv

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.

Then you have to use the door name as the key for the index (instead of an array it’s a dictionary like everything else)

local doorName: string = ...
_G.Doors.L1[doorName] = {Location = Door, Type = Door.Type.Value, IsOpened = false}
1 Like

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.

1 Like

Thank you, this is exactly what I needed,

I’ve managed to simplify it to just this:

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}

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


You’re good, no worries, appreciate it for taking the time to tell me though.

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 ="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).

1 Like

What better way to define global tables?

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 :man_shrugging:
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.

1 Like

Appreciate the feedback, thanks man. I make great use of this knowledge.

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.

I’m aware, and taking into all of the things you guys have told me into account to do better. I appreciate it.

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.