Table error

Games
#1

What’s wrong with this table??

local planetNames = {
    0 = "Arena",
    1 = "Purpz-4658",
    2 = "Goldy-5269",
    3 = "Desert-1256",
    4 = "Grassy-3654",
    5 = "Cyany-3421",
    6 = "Earthy-1234",
    7 = "Rocky-4325",
    8 = "Ball-2436",
    9 = "Pinky-5451",
    10 = "Greeny-7266",
  }

I get this error:
e

#2

You cannot index arrays explicitly. Use a string key such as this and it will work. Or drop the index and just out commas between values.

Note that index 0 does not exist in lua.

local planetNames = {
    e1 = "Purpz-4658",
    e2 = "Goldy-5269",
    e3 = "Desert-1256",
    e4 = "Grassy-3654",
    e5 = "Cyany-3421",
    e6 = "Earthy-1234",
    e7 = "Rocky-4325",
    e8 = "Ball-2436",
    e9 = "Pinky-5451",
    e10 = "Greeny-7266"
}
print(planetNames.e1)

local planetNames = {
    "Purpz-4658",
    "Goldy-5269",
    "Desert-1256",
    "Grassy-3654",
    "Cyany-3421",
    "Earthy-1234",
    "Rocky-4325",
    "Ball-2436",
    "Pinky-5451",
    "Greeny-7266"
}
print(planetNames[1])
1 Like
#3

thanks! :smiley:

#4

Index 0 is fine, as are negative indexes

local array = {}
array[0] = 0
print(array[0])
1 Like
#5

Thats defining a key value pair. It’s no longer an array. You cannot use #array to get the length for instance. But you already know that @anon63346430

1 Like
#6

You can use #array, but lua doesn’t actually count the elements, it simply returns the last integer.

local array = {}
for i = 0, 10 do
  array[i] = math.random(1,10)
end
print(#array)  <-- prints 10 not 11

There is no such thing as an array in lua anyway - it’s all just tables. The OP wanted an index at 0 and I was pointing out this is entirely possible and in some cases needed.

I often use zero-based “arrays” in my code. For example, including some aggregate in index 0 that I don’t want to be used when iterating the “array”. Like returning TOP 100 from a table and also in index 0 returning the total number of rows (which will be more than 100) in a single call rather than requiring two remote db calls. This is just more efficient.

2 Likes
#7

For @ConveyedRex7592, you can also assign numbers via:

local planetNames = {
    [0] = "Arena",
    [1] = "Purpz-4658",
    [2] = "Goldy-5269",
    [3] = "Desert-1256",
    [4] = "Grassy-3654",
    [5] = "Cyany-3421",
    [6] = "Earthy-1234",
    [7] = "Rocky-4325",
    [8] = "Ball-2436",
    [9] = "Pinky-5451",
    [10] = "Greeny-7266",
  }

Or just leave the index out and it’ll work like tntwickey pointed out.

Also, like SGS already said, zeros and negative numbers can be used as indices, but Lua always starts adding to tables from index 1.

ipairs would ignore zeros and negative values, but there’s also an issue that both ipairs and # operator will only iterate until the first nil index in the table. In other words, if you were to comment out the line [1] = "Purpz-4658", then using ipairs or # would state that the length of the table is 0.

But, since you are in control of your code and you know what it needs to do, you could use for loops that start from zero or negative indices and there’d be no issues.

1 Like
#8

Not strictly true. I believe that “behind the scenes” Lua tables have an array component and a hash component - but that’s me being pedantic :slightly_smiling_face: . The only time I can think that this really causes any kind of issues is when you are json encoding a table. If it only contains numeric indices it will be encoded as an array, whereas if there are any string keys in the table it will encode it as a dictionary and turn all of the numeric keys in that table into strings.
Particularly annoying the first time you try to decode it back again and find that myTable[1] is nil, because it’s now myTable[“1”]

Similarly this isn’t entirely accurate:

You can use #array, but lua doesn’t actually count the elements, it simply returns the last integer.

It returns the last integer key before the first nil entry. So for this table:

local myTable = {
	[1] = 10,
	[2] = 20,
	[5] = 50
}

#myTable would return 2, not 5. Using table.maxn(myTable) would return 5 but I think that’s much slower.

(I realise you already know this SGS, but I thought it would be useful for the original poster)

1 Like