This works:

t = {}
t[1] = 'a'
t[2] = 'b'

print(t[1]) -- outputs "a"
print(t[2]) -- outputs "b"

whereas this does not:

t = {}
--t[1] = 'a'
t[2] = 'b'

print(t[1]) -- outputs "false"
print(t[2]) -- outputs "false" (expected: "b")

nor does this:

t = {}
t[1] = 'a'
--t[2] = 'b'
t[3] = 'c'

print(t[1]) -- outputs "a"
print(t[2]) -- outputs "false"
print(t[3]) -- outputs "false" (expected: "c")

So apparently if numbers are used as table indexes and they don't start at 1 and proceed contiguously, the rest of the table (after the break in continuity) behaves as if it's empty...or something.

It works as expected in normal Lua 5.2.3 btw

I think this has to do with the way the tables work behind the scenes. It seems like enough space is allocated for twice the "size" of the table, where "size" is the number of continuous elements. You'll notice that if you fill out the table to 17 elements, the table works sparsely up to 32 elements.

This is only the case for number indexes, though, so I've gotten around it using string indexes. It's probably still a bug though, so it might get fixed.

Just finished with this bug and it was nasty! There are points in the Lua code where numbers and integers are converted using casts, but an explicit conversion is needed when dealing with pico-8's 16.16 fixed point representation. I missed one of them, and the input to a hash function used for looking up key values was wrong, causing false negative matches.. sometimes. :-/

Anyway, fixed for 0.1.1. Thanks for the report.

Sounds like it was a tricky one to debug; thanks for the fix :)