Can't compare the same value in two different tables.

[scissors61]

Hey guys, I'm making a language learning game, and I need help in dealing with a problem that kind of surprise me because according to the little I know about Lua, it shouldn't happen.

I have two tables, and in one of them a string value is considered as a string and in the other as a table, even though there are the same, so I can't compare them and continue building the game logic.

It was hard to identify the problem because the code was complicated and the problem is something simple that shouldn't happen.

Maybe I'm missing some basic knowledge of tables and strings in Lua, any help will be appreciated.

[bakpakin]

Rather than post your entire game in a .love file which people need to unzip, it would be helpful to just post a code snippet of where the problem is.

[raidho36]

Are you trying to compare tables? If it's not the very same table, the equation operation will always return false.

[scissors61]

@bakpakin I agree, but I can't find what the source of the problem is.
@raidho36 I'm trying to compare strings from tables, but when I identify the string location in one table, it shows as a table when it should be a string.

[raidho36]

You probably mis-identify it then.

[scissors61]

I displayed them in love.graphics, and there are the same.

[raidho36]

The "radicals" table is three levels deep, not two.

[scissors61]

I thought of doing this complexRadicals[43][#complexRadicals[43][1]] instead, but it's nil. Don't know how could I identify it, if that's the problem.

[zorg]

Apologies beforehand, this was mostly a train-of-thought type post on my part.

You know, it would be nice having a line number and file name where the issue happens.
Or at the very least, if it's really that complicated, then create a minimal project that also has this issue for us to check.

That said, i looked at the code. Apart from it being subjectively horrible, no offense, i'm trying to follow the logic of the construction of your tables.

the kanjis are indexed by... one kanji each, so they're strings, and their value is always one table with strings inside it (indexed numerically)
The components are again a flat numerically indexed table holding radicals, so strings.
The complexRadicals table, on the other hand, is a bit more complex, from the looks of it. Numerically indexed, each value a table containing one or more tables that contain one or more strings. Coherently indexing them must be hell.

You're also redefining love.mousepressed in your blocks.update... why. porque. 何で. miért.

And it seems you're always running createSelectedTable each update cycle as well... not sure whether that's what you want to do or not.

Anyway, the issue seems to be: The 43th entry in complexRadicals: {{ "一" , "亅" , "疔"},{"疔" }},
complexRadicals[43][#complexRadicals[43]] is your calling code, so let's figure out what will it result in:
complexRadicals[43][2] since there are two subtables in there, which means that it will be equal to
{"疔" }. A table. Now it might be love.graphics.print (along with printf too, i imagine) accepting a table as its text parameter as well, probably a side-effect of allowing colored text too... even though there's no color, so this shouldn't work.
This being my assumption. However it seems that others have noticed it as well, and when i tried [1] too, it gave back nil.

To be honest, i can't find the error either. And to be completely honest, it'd be faster for me to rewrite this completely, cleaner, than to find the error.

[scissors61]

I Appreciate the feedback zorg, by the level I am it's very helpful these kind of comments.
I tried to create a smaller project to post it here, but the problem didn't appear. Now I understand why, in the small project I created a one dimension table, so the problem didn't appear.

My code must be horrible. No offenses were taken lol. I have will and confidence, but I don't have skills nor discipline, so I just feel that I can come up with an aswer if I keep trying even though it will be awful, and they are, I hope that in the future it becomes less awful.

The complexRadicals table, on the other hand, is a bit more complex, from the looks of it. Numerically indexed, each value a table containing one or more tables that contain one or more strings. Coherently indexing them must be hell.

At first, this table was similar to the kanji table, having the main complexRadical as the key, but I made it only numerically indexed to see if I could solve the problem I have here. Before I was using the generic for loop, and I thought it was going to be more precise with a numeric for loop, but it didn't work.

You're also redefining love.mousepressed in your blocks.update... why. porque. 何で. miért.

Oh, just trying to have the code in modules to keep cleaned main.lua. It was love.mouse.isDown, but the function was always repeating, so I changed it to mousepressed.

And it seems you're always running createSelectedTable each update cycle as well... not sure whether that's what you want to do or not.

It creates a table based on the selected radicals when "space" is pressed. Because it is a conditional I thought that it should be in love.update

Anyway, the issue seems to be: The 43th entry in complexRadicals: {{ "一" , "亅" , "疔"},{"疔" }},
complexRadicals[43][#complexRadicals[43]] is your calling code, so let's figure out what will it result in:
complexRadicals[43][2] since there are two subtables in there, which means that it will be equal to
{"疔" }

Yes, that is what I want to do. To give the player different options to compose a complexRadical, even the option of not selecting the complexRadical itself but its components.

To be honest, I can't find the error either. And to be completely honest, it'd be faster for me to rewrite this completely, cleaner, than to find the error.

I've already written the logic of what will happen after you answer (press "space"), but it's complicated. A lot of things in that code are made with the intention of giving the player flexibility for selecting the radicals of a kanji. It includes the case of several complexRadicals appearing in a kanji. So don't know how much it can be rewriting while allowing that flexibility. But I'm stuck if I can't compare the strings from those two tables.