Old message:
Welcome to Minecraft Overviewer!
New message:
Welcome to Minecraft Overviewer version 0.15.75 (9605bd8)!
This might make is easier to quickly see what version of Overviewer
people are running when they ask for support
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 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.
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.
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
Phoenix616