During the first call to get_chunk, we can simply read the whole
region file into a BytesIO object. By then re-reading location
and timestamp data, we might make scrambled maps a lot less
likely.
Hopefully mitigates #1888.
Closes#1790.
If a chunk fails reading due to an underlying operating system
IO error, we can invoke the retry logic too. No clue what could
cause this to happen beyond hardware faults.
Also lower the sleep time to 0.25s down from 0.5s because half a
second of sleeping for each chunk this happens on seems incredibly
overkill.
Making the nbt code raise a CorruptChunkError in this case also means
that failing to read a chunk due to an IOError is not a fatal error
anymore, it'll simply skip it and move on.
Don't use .append(), we already know the final length. Instead,
have python initialise the list of a certain size and set the elements
in it.
Makes the function like 4% faster.
Many things work, some don't. Notably, genPOI doesn't work, and
there's some signedness comparison stuff going on in the C extension.
This also completely drops support for Python 2, as maintaining a C
extension for both Python 2 and 3 is a pain and not worth it for the
9 months that Python 2 is still going to be supported upstream.
The documentation needs to be adjusted as well.
All of the few tests we have pass, and rendering a map works, both
with a configuration file and without. We can also use optimizeimages.
Concerns #1528.
We're ignoring E221 and E741 since I disagree with them; I think extra
whitespace around operators to align repeated operations can aid
readability and help spot bugs.
This was mostly whitespace issues, e.g. trailing whitespace and
a single space on blank lines.
The NBT spec requires that all strings are UTF-8 encoded. However in
practice, non-UTF-8 data can get into a level.dat file (generally via
some weird user-supplied characters in signs. This results in the
following error:
CorruptNBTError: could not parse nbt: 'utf8' codec can't decode byte
0xc0 in position 3: invalid start byte
This happens often enough that we should just ignore this error by using
the 'replace' strategy to replace the invalid data
A common case is a corrupt (or empty) level.dat file. This condition
wasn't properly caught, yielding a less-than-useful stack trace. Even
more concerning is that this could happen when a user is just running
"overviewer.py" to get a world listing.
This has been fixed to improve the user experience
