commands.getBlockInfos checks for >=4096, not >4096 when error-checking
Hex4dec opened this issue · 7 comments
Minecraft Version
1.20.x
Version
1.110.1
Details
Use commands.getBlockInfos on a 16x16x16 area. It will error with "Too many blocks", contradicting the documentation, and avoiding the nice round number of 16^3.
You know, it would be nice to just redesign commands.getBlockInfos
to be generally more sane. The data it returns is impossible to deal with because of the lack of documentation of the flattened yzx coordinate space. I have tried countless different ways of iterating over the table and none of them have worked successfully for me.
lack of documentation of the flattened yzx coordinate space.,
Quoting the documentation,
Blocks are traversed by ascending y level, followed by z and x - the returned table may be indexed using
x + z*width + y*depth*depth
.
Have you tried iterating using that?
for y = 1, ylimit do
for z = 1, zlimit do
for x = 1, xlimit do
local block = blocks[x + z*zlimit + y*ylimit*ylimit]
-- ...
end
end
end
I have. I may be doing something wrong but that just returns garbage not in the shape of the blocks scanned. I will try again to see if the gods have decided to make my code work again.
Seems like for the life of me, I cannot reproduce this, I assume this is just user error on my part. I'll close this (feel free to reopen if you want to track the documentation issue)
Also, shouldnt depth refer to the zlimit and width refer to the xlimit? (height for ylimit)
Have you even tested your code?
The following works. I don't want to know why and I don't want to make it cleaner. However this does not fix this issue:
local i = 0
for y = 1,ysize do
for z = 1,zsize do
for x = 1,xsize do
i = i + 1
blocks[i]...
end
end
end
Thanks for the report! Oh, that's very odd — the code definitely uses >
rather than >=
. so I'm not sure why it's not working. Could you provide an example call where this is failing — I've done a quick test, and it seems to be working fine for the few cases I've tested.
Ahh, sorry. That expression in the documentation is entirely wrong, it should be x + z*width + y*width*depth + 1
instead. I'll fix that up, and try to flesh it out with a proper example.