Apparently the gzip stream can be malformed in a way where it
does read it, but then throws an EOFError when it abruptly ends.
Catch this so we don't error out.
Apparently this is a status sometimes seen with worlds converted from
1.12 to 1.14. From the sample I have, it looks like they're properly
populated with light and terrain data, so hopefully this doesn't break
anything.
Possibly fixes#1630.
python3-imaging doesn't exist but python3-pil does, which
python3-pillow is aliased to. It also includes the necessary headers.
Add a note about pip missing the headers and warn of ABI mismatches if
people do weird things.
While dicking around with the tests I noticed that you could make
them fail if you ran them twice. Many hours were spent investigating,
and it turns out that Overviewer's config stuff has global state that
gets modified by having parsed configurations actually modify the
default config values. Not good!
We can fix this by having settingsDefinition return a dict of the
defaults, instead of assigning it to module-level names.
We can also get rid of test_all.py, because what it would do with
pytest is run all tests *twice*. Instead, do the module path stuff
in __init__.py. Also, instead of throwing a non-specific Exception
if exmaple isn't checked out, just skip the test thank you very much.
This is the weirdest rabbit hole I've ever gone down and I haven't
slept in about 30 hours. I'm going to push this commit, and if it
breaks anything, I'll be blissfully asleep as the unwashed masses
begin to riot over exception this traceback that.
CamelCase does not bode well in Python land, so it's best we rename
these ill-named files before the Guidoists get us and throw us into
a damp dungeon.
This adds:
- mossy stone brick stairs
- mossy cobblestone stairs
- mossy stone brick walls
We also add another block class for walls, and while we're at it,
clean up the stairs texture function to not have a huge sprawling
elif mess for loading textures, but instead to a cheeky dictionary
lookup.
In case you're wondering, yes I am just as disgusted by this code as
you are.
genPOI needs this for groupby, and since we can now throw cropped
regionsets into genPOI we definitely need this too.
Probably also fixes rotated regionsets with multiple genPOI filters.
Use CroppedRegionSets to generate markers, which should only affect
handleEntities. I have not yet checked whether this generates
dupicate players and manualpois for maps with multiple crop zones,
but that's a fire to put out for another day.
Fixes#1574.
If the first texture loaded was not in the pack, i.e. we fell back
on system textures, then the pack was ignored altogether for the
remainder of the render.
Here we fix this by using an OrderedDict instead of the split jars
and jarpath nonsense, and then always checking the custom textures
first and opening them if they are not already open, and putting
the jar file handle at the start of the OrderedDict.
We also switch around some logic to avoid unnecessary isdir calls
when we're using a resource pack.
Sometimes a texture pack is not complete, but system textures are
available to make up the difference. In that case, we should load
those.
Current caveat is that we might not notice texture names changing
with newer minecraft clients because we have old ones installed.
I'll have to think some more about that one.
If loading the grass and foliage biome colour fails, Overviewer doesn't
necessarily crash, it just renders everything gray, apart from one small
issue: in trying to call base_finish, it'd crash trying to decrease the
reference of a null pointer.
This option allows you to specify your own initial center for a
tileset, which is useful if your map is extremely asymmetric or
you don't really care about what's around the spawn.
Future work needs to be done on the JS side in order to fix the
fromWorldToLatLng and friends, as they're currently off by -24 in X
and +24 in Z direction.
Closes#1350.
find_file contained a lot of code for searching textures in ways that
haven't been relevant for years. For example, it had workarounds for
MCPatcher, a tool that hasn't been updated since 2015.
Instead of searching in multiple paths that will never succeed in a
resource pack and Minecraft version that actually work, just look
for the filename that the block functions ask for.
Also, if we already have a manually specified resource pack open,
we shouldn't repeatedly re-open it. Furthermore, it's best if
the very first thing find_file does is try to find the file in
the resource pack or client jar we've already opened previously.
We can now also remove chest.png, ender.png, foliage.png, grass.png
and normal_double.png because Minecraft ships them, so we don't
need to ship them ourselves too. Us shipping them actually hid the
whole find_file garbagefire.
Concerns issue #1604.
Previously, textures that couldn't be found the first time around
would not have this fact cached, so we'd run through the whole
slow path of find_file with each blockid and data entry.
This is what caused the chests texture generation function to take
almost 12 seconds on my system, as it is looking for "normal.png"
that hasn't existed in Minecraft textures for ages.
Shoving the exception, if one is encountered, into the cache, and
then re-raising it if we load it from the texture cache brings this
number down to about 2 seconds. That's six times as fast!
Concerns issue #1604.
We can try each jar in descending order of versions until we actually
find one that works. This fixes#1328.
Future work might move the "if self.jar is not None" higher up in the
function so that we don't keep re-checking the overviewer dir and texture
path for files that we will then not use at all for some reason.
Somebody reported that genPOI was throwing an exception in two
different places related to trying to read bytes as a string.
I personally could not reproduce (possibly needs some special player
names or something?) but I think this change should fix it either way.
So turns out genPOI wants to use sorted() so it can use itertools.groupby.
Python 2 somehow just... sorted objects so that groupby (which is basically
the UNIX uniq) could group them properly. Python 3 no longer does this,
so as comparison method let's just compare regiondir strings since that
gives us the desired result.
Fixes#1597.
If you're using CentOS/RHEL 6, you probably already can't run
Overviewer due to our dependency on argparse breaking python2.6
compatibility. However, if you somehow managed to get python2.7
working on CentOS 6, you now get a nice warning telling you to
finally get off your butt and use something else.
This warning can be dropped once we move to Python 3, which is why
this code was added in the first place: CentOS 6 has no Python 3
package that is still supported by upstream, not even in EPEL.
Apparently not even chunks of that data version can be relied upon
to have that flag mean anything at all, as the --forceUpgrade and
--eraseCache switches result in a world where chunks are flagged
as not being lit but seemingly do have SkyLight and BlockLight keys.
Concerns #1570.
Minecraft notes various stages of fetal development that chunks are
in, with the complete ones being "full". Previously, we'd check
against a list of states that are not full to skip a chunk, which
is obviously not future proof, and broke as Mojang updated their
possible range of values for the status field. It's better to
just bail if the status is anything other than "full".
Additionally, a key called "isLightOn" is in the chunk now. This
seemingly determines whether a chunk has been lit. We're also going
to check for this, and bail if it's not. In my tests, I have not yet
seen a single "full" chunk that does not have "isLightOn" set.
Fixes#1558.
This is a new directory added in 1.14 which contains .mca files too.
Since we scan for directories with .mca files to use as RegionSets,
and we don't know how to handle these, just skip them.
Fixes some warnings during rendering.
Sorry for the noise in mc_id.h, but somebody decided they want DOS
line endings and I couldn't allow that to happen. When not doing that
put the whole thing into diff, I decided to just fix the indentation
too while I was at it.
Needed bugfixing of some overlooked unsigned char usages for block IDs,
as otherwise the lighting would be scuffed.
Concerns issue #1486.
Concerns issue #1486.
Inner/outer corners apparently have their data from ancil data instead
of Minecraft's stuff, so we might need to fix that in the future.
I've had to fight rst a lot to get this right, somehow the code
block after the last bullet point breaks if you explicitly number
the enumerated list instead of using auto-enumeration. Like legit,
change `#.` to `12.` and it'll break. No clue why.
I've adjusted the macOS instructions slightly to be more general,
e.g. do not advise symlinking a specific Python executable of a
specific version, just tell people they should make sure it's in
their environment.
And yes, on Windows, python.exe is whatever version you have installed,
so if you install Python 3, python.exe is going to be Python 3.
I've removed the FreeBSD instructions because they only talk about
working around ports potentially using Python 2.6, which is no longer
relevant. If somebody here uses FreeBSD and has anything to add to the
instructions not already covered by the Linux instructions, let me know.
Python 3.7 requires using the xenial images in Travis-CI. It appears
that they do not yet have newer distro version images available, so
that's the best we can get for now.
There's some stuff left to do, like properly do the functools.partial
stuff, and check that the uuidcache is actually working. But hey,
player markers work at least, and so does --skip-scan.
Still needs a port to argparse though.
