"Could not render chunk ... for some reason. This is likely a render primitive option error."

[grimfabel]

Recently The-Minecraft-Overviewer has not been working at all for me. It just grinds to a halt after giving a few errors like:

ERROR:root:Could not render chunk 25,-27 for some reason. This is likely a render primitive option error.
...
OverflowError: Python integer -8924955784983347200 out of bounds for uint64

I think the problem (or the reason it even worked before) is that numpy.asarray(long_array, dtype=numpy.uint64) silently casted sint64 to uint64. But not any more. Of course the long_array should contain uint64 values to begin with. Here is a patch to fix that:

diff --git a/overviewer_core/nbt.py b/overviewer_core/nbt.py
index 8461fbc..a5f2478 100644
--- a/overviewer_core/nbt.py
+++ b/overviewer_core/nbt.py
@@ -153,7 +153,7 @@ class NBTFileReader(object):
     def _read_tag_long_array(self):
         length = self._uint.unpack(self._file.read(4))[0]
         long_bytes = self._file.read(length * 8)
-        return struct.unpack(">%iq" % length, long_bytes)
+        return struct.unpack(">%iQ" % length, long_bytes)
 
     def _read_tag_string(self):
         length = self._ushort.unpack(self._file.read(2))[0]

[stwalkerster]

Are you able to provide a region file or similar so we can attempt to reproduce this?

[greatmastermario]

@stwalkerster Do you just need the individual region file or the whole world save? I can provide either, but I need a suggestion where to upload it. Not sure how big of a file or ZIP archive I can attach to this ticket.

[JoshuaMarti]

@greatmastermario Are you having the same issue as grimfabel?

[greatmastermario]

Yes, I am. I started seeing it after one of the recent game drops. I discovered it while doing a refactor to remove distutils, which is deprecated in higher Python versions. I have a small sample world with the issue which can illustrate the issue. I have a feeling it is due to assigning those variables as uint instead of signed ints, but I am not sure what the appropriate fix would be.

…

-Andrew Thomas

On Sat, Nov 22, 2025, 9:33 AM JoshuaMarti ***@***.***> wrote: *JoshuaMarti* left a comment (GregoryAM-SP/The-Minecraft-Overviewer#92) <#92 (comment)> @greatmastermario <https://github.com/greatmastermario> Are you having the same issue as grimfabel? — Reply to this email directly, view it on GitHub <#92 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD6TON2UAKPCT6QEX4EJDEL36CF6NAVCNFSM6AAAAACDGMSOBWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNRWHA3DIOJZGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[grimfabel]

@greatmastermario Doesn't my patch solve the problem for you (for me it does)?

[FastLizard4]

So, I ran into this myself and did some digging, debugging, and testing.

Turns out that the proximate cause is likely using NumPy v2 instead of v1 as called for in requirements.txt. NumPy v1 will automatically cast sint64 to uint64, for example:

>>> import struct, numpy
>>> b = numpy.asarray([-8993688455858880512], dtype=numpy.uint64)
<stdin>:1: DeprecationWarning: NumPy will stop allowing conversion of out-of-bound Python integers to integer arrays.  The conversion of -8993688455858880512 to uint64 will fail in the future.
For the old behavior, usually:
    np.array(value).astype(dtype)
will give the desired result (the cast overflows).
>>> b
array([9453055617850671104], dtype=uint64)

As noted in the deprecation warning, this fails in NumPy v2, and results in the error given in this issue.

struct.unpack(), of course, has similar behavior when unpacking a signed long as an unsigned long:

>>> blob = struct.pack('>q', -8993688455858880512)
>>> blob
b'\x830\x00\x00\x00\x00\x00\x00'
>>> struct.unpack('>q', blob)
(-8993688455858880512,)
>>> struct.unpack('>Q', blob)
(9453055617850671104,)

So the patch as given in the OP "fixes" the issue, in that the same input will result in the same output. But, arguably, both the original behavior and the "fix" are both incorrect.

The relevant code in nbt.py, _read_tag_long_array(), is associated with NBT type ID 12, as seen in NBTFileReader.__init__() in nbt.py:

self._read_tagmap = {
    0: self._read_tag_end,
    1: self._read_tag_byte,
    2: self._read_tag_short,
    3: self._read_tag_int,
    4: self._read_tag_long,
    5: self._read_tag_float,
    6: self._read_tag_double,
    7: self._read_tag_byte_array,
    8: self._read_tag_string,
    9: self._read_tag_list,
    10: self._read_tag_compound,
    11: self._read_tag_int_array,
    12: self._read_tag_long_array,

Per the NBT tag definition as seen on the Minecraft wiki, type 12 (TAG_Long_Array) is defined as an array of TAG_Long elements, which themselves are "64 bits, signed, big endian". So, Overviewer strictly has incorrect behavior, whether the casting is done in the numpy.asarray() call or the struct.unpack() call. It seems like the only reason this works, at least in my case, is that RegionSet._packed_longarray_to_shorts_v116(), where this is being done, breaks that output long array into an array of unsigned short ints anyway, so it doesn't really matter what the input type is as long as it is (correctly) known.

[grimfabel]

As the tag long array type is never treated as a signed number (instead the individual bits are read) I though it made more sense to treat it as unsigned longs all the way through. But you are right, this is technically incorrect. Negative numbers might be used for something in the future. So here is a new patch which explicitly tells new numpy to cast int64 into uint64 on the relevant places to restore the behavior of old numpy.

diff --git a/overviewer_core/world.py b/overviewer_core/world.py
index 1df921b..657df00 100644
--- a/overviewer_core/world.py
+++ b/overviewer_core/world.py
@@ -2020,7 +2020,7 @@ class RegionSet(object):
         # num_palette_entries must be >= 2, if 0 or 1 all biomedata is palette[0] anyway.
         bits_per_value = 32 - (32 - ((num_palette_entries-1).bit_length()))
 
-        b = numpy.asarray(long_array, dtype=numpy.uint64)
+        b = numpy.asarray(numpy.array(long_array, dtype=numpy.int64), dtype=numpy.uint64)
         result = numpy.zeros((n,), dtype=numpy.uint16)
         shorts_per_long = 64 // bits_per_value
         mask = (1 << bits_per_value) - 1
@@ -2094,7 +2094,7 @@ class RegionSet(object):
         bits_per_value = (len(long_array) * 64) / n
         if bits_per_value < 4 or 12 < bits_per_value:
             raise nbt.CorruptChunkError()
-        b = numpy.frombuffer(numpy.asarray(long_array, dtype=numpy.uint64), dtype=numpy.uint8)
+        b = numpy.frombuffer(numpy.asarray(numpy.array(long_array, dtype=numpy.int64), dtype=numpy.uint64), dtype=numpy.uint8)
         # give room for work, later
         b = b.astype(numpy.uint16)
         if bits_per_value == 8:
@@ -2160,7 +2160,7 @@ class RegionSet(object):
     def _packed_longarray_to_shorts_v116(self, long_array, n, num_palette):
         bits_per_value = max(4, (len(long_array) * 64) // n)
 
-        b = numpy.asarray(long_array, dtype=numpy.uint64)
+        b = numpy.asarray(numpy.array(long_array, dtype=numpy.int64), dtype=numpy.uint64)
         result = numpy.zeros((n,), dtype=numpy.uint16)
         shorts_per_long = 64 // bits_per_value
         mask = (1 << bits_per_value) - 1

It might be a good idea to only use numpy arrays all the way. This way of casting copies the values two times. While numpy can change the datatype of an array without copying (using the view() method). Since the overviewer can take days to run on large maps such an otherwise insignificant optimization might actually save significant time in this case. But I actually have no idea how big an impact this has.

[stwalkerster]

@grimfabel - Are you happy to open a PR for this patch?

[grimfabel]

@stwalkerster If I already had the code in a public repo I would. But I consider it way overkill to set that up for this tiny tiny patch.