1.18.1
folkertvanheusden opened this issue · 14 comments
Hi,
With minecraft 1.18.1 I only get completely transparent .png-files, e.g. with nothing visible.
Which version did you try? Current master does not support Minecraft >= 1.13 (I think), I suggest you first try my current but old pull request for 1.13 support #310 (edit: I did test it with an early version of 1.17 where it worked mostly)
I stopped working on it since it seems that no one was interested and I really wanted feedback on code quality and design approach.
Hi!
I tried the latest master.
A minute ago I tried it with #310 and got the same result:
./c10t -w ~/.minecraft/saves/test/ -o test2.png --no-alpha --striped-terrain
Alright then workshop time; I'll take a look and see what's going on
Well; now that I have installed 1.18.1 I'm able to reproduce this issue
Ok! It happens here with tiny maps (just created) and massive ones.
So building the region-inspect tool and running it on a mca-file suggest that the level nbt-compond object has been flattened, and if that is the only thing then this should be fairly easy to fix. edit: jinxed it, some stuff changed tag-name as well.
Managed to get the top-down rendering to work, the Y section indexing (which is used to compute the block height) is just broken now, I noted before that the deepslate was negative but now they all are and I need to figure out a way to normalize it since the computation expected them to start at zero and then increase.
Thanks, unfortunately it crashes here:
Program received signal SIGSEGV, Segmentation fault.
0x00005555555e8c8a in mc::register_byte (value=-5 '\373', name=..., C=0x7fffffffc570) at /usr/include/c++/11/bits/stl_iterator.h:1010
1010 __normal_iterator(const _Iterator& __i) _GLIBCXX_NOEXCEPT
(gdb) bt
#0 0x00005555555e8c8a in mc::register_byte (value=-5 '\373', name=..., C=0x7fffffffc570) at /usr/include/c++/11/bits/stl_iterator.h:1010
#1 mc::register_byte (C=0x7fffffffc570, name=..., value=<optimized out>) at /home/folkert/t/c10t/src/mc/level.cpp:824
#2 0x00005555555f15ff in nbt::Parser<mc::level_context>::parse (this=this@entry=0x7fffffffc6c0, file=...)
at /home/folkert/t/c10t/src/nbt/nbt.hpp:673
#3 0x00005555555ec57c in nbt::Parser<mc::level_context>::parse_buffer (size=<optimized out>, buffer=<optimized out>, this=0x7fffffffc6c0)
at /home/folkert/t/c10t/src/nbt/nbt.hpp:736
#4 mc::level::read (this=this@entry=0x555558016f00, buffer=...) at /home/folkert/t/c10t/src/mc/level.cpp:1157
#5 0x00005555555d5911 in generate_map (out=..., out_log=..., error=..., s=..., hints=std::vector of length 1, capacity 1 = {...},
world_path=..., output_path=...) at /home/folkert/t/c10t/src/generate_map.cpp:718
#6 0x0000555555595767 in main (argc=<optimized out>, argv=0x7fffffffdea8) at /home/folkert/t/c10t/src/main.cpp:439
Hmm that is at the Y-index decoding process c10t/src/mc/level.cpp:824
I cannot easily reproduce any crashes currently (I'm almost positive that if we did input fuzzing of map data that there will be crashes), I looked into one thing in the internal NBT library and have now pushed that. All my old test maps and new ones seems to be working for me regardless. @folkertvanheusden If it is still not working could you send me the offending map and maybe provide me with your compiler and library versions? Finally have you verified that it is not a ram-issue on your end?
Hi,
I don't think it is a ram issue:
memory usage: 2789 MB
memory limit: 8192 MB
I'm using gcc 11.2.0 but clang++ 13.0.0-2 gives the same problem.
Can I share the map with you without it being accessible for everyone? Can you send me your e-mail address so that I can send you the url? mail@vanheusden.com
Valgrind mentioned also all kinds of errors, see attached.
valgrind-err.txt
Excellent report; I was contemplating running Valgrind. For completeness sake here is my compiler and dependency versions; I have not tried using llvm.
sys-devel/gcc 11.2.0
sys-libs/glibc 2.33-r7
dev-libs/boost 1.77.0-r4
Got it! Sections need to be allocated before setting their Y-index. I should really write a few unit-tests for the level data parser to ensure that corner cases like this cannot happen again.
Thanks for all the work!
It indeed works.
Thanks again!