复制lua表时不匹配

复制lua表时不匹配,lua,nested,compare,hex,lua-table,Lua,Nested,Compare,Hex,Lua Table,我正在使用Lua和Love2d编写一个游戏,但在处理嵌套表时遇到了一个障碍 我有一个函数,它运行在一个包含与墙、按钮等对应的数字的表中,并根据键打印彩色块。其中一个表的示例如下所示: map = { { 1, 1, 1, 1, 1, 1, 1, 1, 1 } { 1, 0, 0, 0, 0, 0, 0, 0, 1 } { 1, 0, 1, 1, 2, 0, 0, 0, 1 } { 1, 0, 0, 0, 0, 0, 0, 0, 1 } { 1, 1,

我正在使用Lua和Love2d编写一个游戏,但在处理嵌套表时遇到了一个障碍

我有一个函数,它运行在一个包含与墙、按钮等对应的数字的表中,并根据键打印彩色块。其中一个表的示例如下所示:

map = {
    { 1, 1, 1, 1, 1, 1, 1, 1, 1 }
    { 1, 0, 0, 0, 0, 0, 0, 0, 1 } 
    { 1, 0, 1, 1, 2, 0, 0, 0, 1 } 
    { 1, 0, 0, 0, 0, 0, 0, 0, 1 } 
    { 1, 1, 1, 1, 1, 1, 1, 1, 1 } 
}
    111111111
    100000001 
    101120001 
    100000001 
    111111111
这在渲染时效果很好。但是,当我尝试使用从文本文件中读取此数据的函数创建同一个表时,如下所示:

map = {
    { 1, 1, 1, 1, 1, 1, 1, 1, 1 }
    { 1, 0, 0, 0, 0, 0, 0, 0, 1 } 
    { 1, 0, 1, 1, 2, 0, 0, 0, 1 } 
    { 1, 0, 0, 0, 0, 0, 0, 0, 1 } 
    { 1, 1, 1, 1, 1, 1, 1, 1, 1 } 
}
    111111111
    100000001 
    101120001 
    100000001 
    111111111
它创建了一个看起来完全相同的表,但当我试图渲染它时,它根本不起作用

所以我试着用一些代码来调试,这些代码打印出表的内容,虽然内容相同,但描述嵌套表的十六进制代码却不同。例如:

读取映射文件的第一个嵌套表:

1   table: 0x106c5a720
1   1
2   1
3   1
4   1
5   1
6   1
7   1
8   1
9   1
读取手动创建的表的第一个嵌套表:

1   table: 0x106c64120
1   1
2   1
3   1
4   1
5   1
6   1
7   1
8   1
9   1
这是怎么回事?这些值都相同,但发生了一些奇怪的事情

编辑:以下是渲染地图以供参考的代码位:

for y=1, #map do
    for x=1, #map[y] do
      if map[y][x] == 1 then
        print("found a wall")
        love.graphics.rectangle("fill", x * 30, y * 30, 30, 30)
      elseif map[y][x] == 2 then
        print("found a button")
        love.graphics.setColor(255, 0, 0)
        love.graphics.rectangle("fill", x * 30, y * 30, 30, 30)
        love.graphics.setColor(0, 0, 255)
      end
    end
end

从文本文件读取数据时,您将获得字符串
在原始的
地图
表格中,您有数字
数字不等于字符串

assert(1 ~= '1')

你能说得更具体一点吗?你有错误吗?如果是,那是什么样的错误?至于描述中的十六进制位,它是表的内存地址(我猜,或者可能是ID/hash),因此两个不同的表将永远不会共享相同的ID,尽管内容相同。您是否尝试过使用IPAIR对这两个表进行迭代以查看它们是否完全相同?啊!谢谢你清理了这个妖术!这就解开了这个谜。至于一个错误,我一个也没有。游戏运行了,所有的一切,地图都无法渲染。如果您想看一下,我在上面添加了渲染代码。似乎“map[x][y]”永远不等于“1”。我试着打印出“map[x][y]”,它肯定等于“1”多次,这是应该的。另外,当我重复使用您提到的表时,它们看起来仍然相同。我怀疑问题在于您的文件读取例程。读取文件时,您会读取字符,即ASCII字符。所以当你测试一个元素时,元素是ASCII字符1,所以实际上它等于0x31,而不是1。尝试在每个读取字符上使用tonumber()。天哪!就这样!非常感谢汉克斯!原来是这样!你得出的结论与上面的W.B.相同。