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.
optparse is deprecated, and switching to argparse is mostly but not
entirely trivial. Nicely telling the user about shell quoting had
to be removed because I didn't see an easy way to do that with
argparse.
Apparently that comma had its reasons for being there because
Python2's print works in weird ways. We can do this better though
by using string concatenation.
A good sprinkling of PEP8 fixes. We're also getting rid of some
odd manual linebreaks in the output messages, and making sure to
end sentences with a period where appropriate. Help messages have
also been made more consistent, e.g. "Tries" -> "Try" and so forth.
Since Firefox 65 added support for WebP, users may be interested
in having maps that use WebP images. Support for this is added in
this commit, along with documentation for it.
A new option, "imglossless", controls whether we write out lossless
or lossy WebP images. The generic name "imglossless" as opposed to
a more specific "webplossless" was chosen in case future image
formats we also implement also support lossless/lossy modes in the
same format (JPEG-XL? AV1 image format?).
It's an okay meme but lossy mode really falls apart on our sorts
of images on the more zoomed out composite tiles, resulting in
pretty blurry messes. Might be due to a PSNR bias in the encoder,
which is to be expected from Google.
A world being unsupported may not be a fatal application error in
all instances where this codepath in world.py is used, hence
throwing an exception is more sensible.
Apparently we had memcached support. It was never worth it, and put
a weird md5 hash calculation in the path of regular caching. Seeing
as it was completely undocumented, I doubt anyone has ever used it.
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
Often, when people ask questions about Overviewer, "all it says is
'Welcome to Overivwer'" is a common question. Enable a little more
logging info at the start of Overviewer to hopefully make it more clear
that something is happening
There were some problems when a level.dat contained a non-ascii name, or
when a level.dat lived in a directory with a non-ascii name.
Paths returned by os.listdir are encoded, so we need to decode them
before printing them. When calculating the max length of the enumerated
world names, were we for some reason calling str() before taking the
len(). The had the effect of converting unicode strings into
non-unicode strings, which is not the correct thing to do.
This only affects what's written to overviewerConfig.js. That is, it
does not change the amount of tiles rendered (it's exactly analogous to
maxzom)
Closes#994
This also uses a dedicated logger instead of passing everything to the
root logger. `overviewer_core` still needs to be updated to reflect
this.
Additionally, `logger.configure` has been simplified.
Now correctly avoids globbing problems. Removed a bit of irrelevant code
for old style minecraft.jar. Tweaked error messages for resource packs
instead of texture files.
