The problem appears to be that virtualenv overrides the base_prefix
so distutils can no longer find the system python path when adding
linker args.
This adds an ugly hack to find the system python path, and adds it
to the linker flags on Windows. Yay, no more hardcoded paths.
This should also make win32 builds work, and avoid adding linker
args manually.
Sometimes, chunks don't have a sections key, but aren't pre-21w43a.
Fix this check to use DataVersion to determine whether it should be
applied.
Hopefully fixes#2010.
I don't really do enough on this project anymore to justify having
the sponsor button include me. I can cover the server costs fine,
and I feel uncomfortable asking for money. It in fact has caused
some stress for me as I feel bad whenever I think about overviewer
because I know there's so much code rot and big stuff that needs
to be done but I'd rather spend my time on different projects, and
when I'm asking for money it builds the expectation that I will
actually eventually get around to doing all those things, which
I realistically won't be.
Sorry for disappointing, I think it's better this way for both me
and the Overviewer community.
My previous fix worked with the version of sphinx I have locally,
but apparently not the one readTheDocs uses. Imagine my surprise!
Let's just use ``backticks`` for our backslash.
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.
Apparently my -O3 came from somewhere other than this script.
It's possible that there is some generic "use optimisations"
mechanism in setuptools/distutils/whateverthisis, but I don't feel
like opening up that can of worms so let's just add an -O3 extra
argument to the compiler invocation to make sure it always gets it.
Older versions apparently didn't have LANCZOS filtering for
resizing. In this case, just fall back to whatever the default is.
Will look marginally worse for those people but at least it works.
If one wishes to add debug output, they should use overviewer.utils.debug.
To see the output produced by that, set overviewerConfig.map.debug to true.
Fixes#1816.
Previously, walls were all numbered at 21000+. This is bad because
our blockmap is an array, so this caused our blockmap to take up
80 MiB of RAM in each worker process.
This commit changes the wall numbering, and exploits some bitmasking
to have the wall check run in constant time no matter how many walls
there are. This is done with a simple mask and xor to check the prefix.
RAM usage for the blockmap thus drops to like 44 MiB.
This is in preparation for adding more walls for 1.16.
Instead of trusting that Minecraft will only request up to index
num_palette_entries - 1, we'll assume Mojang occasionally produces
a weird file where it tries to request past that, up to the maximum
palette index it can based on the bits per value. To facilitate this,
this commit extends the translation palette array to this maximum size.
Such invalid palette picks will simply be replaced by ID 0 (aka air),
so it should cause minimal weirdness in the output.
Works around #1797.
Minecraft 1.16.1 loves writing these in singleplayer, and they
cause a whole bunch of corruption warnings if we don't handle them
in a special way like this.
using rem here is probably wrong because we want to be the height
of the line in the span we're inside of, not of some global thing.
Also, add a margin to the left.
After discussing this with the other folks on IRC, everyone seemed
to be cool with me adding myself to this. It makes it so people see
a little sponsor button that tells them how they can monetarily
support the project if they choose to do so.
Minecraft occasionally generates chunks which are not yet lit.
In the past, I'd have said to just make them not render, but these
can sometimes be large areas of the world.
Instead, render them with full bright SkyLight. This looks less bad
than whatever is stored in the SkyLight property in these cases.
Closes#1787, probably. Only one person bothered providing a sample file.
Nicolas F