## Highly-nested table is causing weird errors...

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Sky_Render
Prole
Posts: 12
Joined: Fri Jul 05, 2019 2:59 am

### Highly-nested table is causing weird errors...

So I have no idea if this is even something that can be dealt with... I have a table which is 4 levels deep. Any time I try to make a reference to a specific table index past 2 levels (ie. [3][1][1][1]), LOVE is throwing up a nil index error on the line of code before the code that is trying to access the table data. I know for a fact that the data in question exists because I am able to successfully reference it when it is loaded into memory. As soon as I'm out of the initialization function, however, the code seems to somehow "forget" that any layers exist past the second one. It's entirely inconsistent about it, however; it can load the values just fine as long as they're called within a for loop, which makes no sense. Anyone have any ideas on how I can get LOVE to accept my absurdly-nested table, or even why it's doing this? Thank you!

raidho36
Party member
Posts: 1992
Joined: Mon Jun 17, 2013 12:00 pm

### Re: Highly-nested table is causing weird errors...

Pretty sure you just have a bug in your code somewhere. No limit on nested depth exists because it's basically just a reference to a different table elsewhere in the memory. You can even have circular nested tables with effectively infinite nesting depth. I personally use nested tables with pretty significant depth and I never had any problems with it.

ivan
Party member
Posts: 1545
Joined: Fri Mar 07, 2008 1:39 pm
Contact:

### Re: Highly-nested table is causing weird errors...

This is not a LOVE-related issue.
Tables are just pure Lua programming so you have a problem somewhere in your code.
Generally speaking, I never need to use "highly nested" tables -
so you could possibly rethink your design and look for a simpler way to handle this.

deströyer
Prole
Posts: 27
Joined: Thu Jun 27, 2013 7:59 pm
Contact:

### Re: Highly-nested table is causing weird errors...

You cannot access [3][1][1][1] if [3][1][1] doesn't exist yet - I had this problem a lot when I was starting out with tables. This might mean that you are not building/nesting your tables correctly, and you end up missing some layers.

Code: Select all

assert( [3], "missing layer 1")
assert( [3][1], "missing layer 2")
assert( [3][1][1], "missing layer 3")

etc. which is a crude but effective way of finding out where your structure falls apart.

Also, remember that when you are building or accessing things there is this neat shortcut:

Code: Select all

table[1] = table[1] or { }
This will not do anything if table[1] already exists, but if it doesn't it will create an empty table which you can then start accessing with table[1][whatever]

Sky_Render
Prole
Posts: 12
Joined: Fri Jul 05, 2019 2:59 am

### Re: Highly-nested table is causing weird errors...

It turns out it's due to a fundamental flaw in Lua's logic. Lua does not allow tables to be referenced more than 2 layers deep for whatever reason unless you use metatables.

I think I'm going to have to move over to C#. Lua is just too limited for my needs. It's a shame because LOVE Is a fantastic extension to the language, but Lua is just too cumbersome to do advanced OOP in. I just need a language where object[index].attribute = value coding logic can be implemented without a massive amount of extra code to implement support for it...

Nelvin
Citizen
Posts: 98
Joined: Mon Sep 12, 2016 7:52 am
Location: Germany

### Re: Highly-nested table is causing weird errors...

That's pure nonesense, the bug is just on your side.

But that's just my two cents ah, I meant lines ... of code

local myTab = {{{{{{{{{{{{{{{{{{{{ 42 }}}}}}}}}}}}}}}}}}}}
print( myTab[1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1])

Sky_Render
Prole
Posts: 12
Joined: Fri Jul 05, 2019 2:59 am

### Re: Highly-nested table is causing weird errors...

I'm not really here to argue about this. I gave LOVE a fair shake, and it can't do what I need it to do easily, so I'm moving on to a different language. I really enjoyed my time with it, though. It's worlds ahead of GameMaker Studio, but it's still too limited for me. I guess I'm still an old-school C programmer at heart.

Nelvin
Citizen
Posts: 98
Joined: Mon Sep 12, 2016 7:52 am
Location: Germany

### Re: Highly-nested table is causing weird errors...

There's nothing to argue here, you made a bug (we all do, I got my first job in gamedev in 1996 and on any current day, if I write a serious amount of code I create bugs) but instead of trying to fix it/understand what you did wrong you're leaving with useless and wrong statements about Lua.

It's not hard to copy&paste two lines of code I posted to see you're wrong and it's probably as simple to find the issue in your code - but it doesn't seem you're interested in this at all ... with threads like these I sometimes wonder if this is some bizarre kind of guerilla marketing instead of an actual real question/issue.

zorg
Party member
Posts: 2745
Joined: Thu Dec 13, 2012 2:55 pm
Location: Absurdistan, Hungary
Contact:

### Re: Highly-nested table is causing weird errors...

Sky_Render wrote:
Sat Aug 31, 2019 2:10 pm
It turns out it's due to a fundamental flaw in Lua's logic. Lua does not allow tables to be referenced more than 2 layers deep for whatever reason unless you use metatables.

I think I'm going to have to move over to C#. Lua is just too limited for my needs. It's a shame because LOVE Is a fantastic extension to the language, but Lua is just too cumbersome to do advanced OOP in. I just need a language where object[index].attribute = value coding logic can be implemented without a massive amount of extra code to implement support for it...

Code: Select all

tableOne = {}
tableOne.tableTwo = {}
tableOne.tableTwo.tableThree = {}
tableOne.tableTwo.tableThree.str = "this works"
array = {}
array[1] = {}
array[1][1] = {}
array[1][1][1] = "this works too"
print(tableOne.tableTwo.tableThree.str)
print(_G["tableOne"]['tableTwo']["tableThree"]['str'])
print(array[1][1][1])
--printing like this goes to console, and on windows, you might need to set console to true in conf.lua, or run with lovec.exe
--... or you can just test this on lua's interactive demo online

If you don't want to argue, that's fine, but that doesn't invalidate the fact that you're wrong. If you dislike löve, then good luck with your future endeavors elsewhere, but at least don't spread incorrect information.

Also, the only thing lua doesn't allow without metatables is referencing nonexistent tables. (As deströyer already pointed out)

Code: Select all

-- This won't work
local t = {}
t[1][2] = "whatever"
-- because no one defined the first layer's table, no t[1] = {} anywhere

(As for the OOP needs, you could have checked out tons of OOP libs that already exist, and yes, most of them do use metatables, because they allow code to be more compact; e.g. without metatables, you'd need to have tons of references to methods in each instance, with metatables (and their index metamethod), methods are dynamically looked up in the class' method table itself... or at least, that's one way that can be implemented. object[index].attribute = value will work in lua as long as object[index] exists, which didn't for you, if you got an error...)

By the way, you never shared code, which probably would make things infinitely simpler to diagnose. More eyeballs on a thing does help.
Me and my stuff True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.

Sky_Render
Prole
Posts: 12
Joined: Fri Jul 05, 2019 2:59 am

### Re: Highly-nested table is causing weird errors...

I really do appreciate the attempts to help. It's heartening that this community is so supportive. Alas, my mind is made up. This old dog tried to learn a new trick, and discovered he liked his old tricks better. Keep on supporting the younger developers who need help, and thanks again for your efforts!

### Who is online

Users browsing this forum: Google [Bot] and 9 guests