dtt-c has been a thing for 8 years now, I think it's safe to say
people have deleted their old caches in the meantime.
findSigns has also been superseded by genPOI ever since genPOI
has been a thing, which has probably been since anvil.
One code style error can't really be fixed because despite
has_key being deprecated, "in" doesn't work on "super" for objects
that derive from dict, at least not in Python 2.7. Thanks Guido.
Also, I don't know which one of you it is that keeps putting semicolons
at the end of your statements but you seriously need to stop.
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.
We've also added a setup.cfg to specify what rules we want for
pycodestyle. We'll be ignoring some dumb ones that make no sense
and probably shouldn't exist, like both W503 and W504 being an
issue somehow???????
We're using a line length limit of 100. If you're on an 80 character
terminal and incredibly upset about this, then that's the nursing
home staff's problem, not ours.
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.
I've used pycodestyle to find pep8 violations, and isort to fix import
sorting.
Currently we're looking at a max line length of 80, but I think we may
want to raise this to 100 because 80 is a pain in the butt.
A young software tinkerer from Switzerland noticed an issue with
an application he was working on one day. The progress bar it
was rendering only updated very rarely. This perplexed the teenager,
but never bugged him enough to investigate further. Nobody else seemed
to notice this, so maybe it was his system?
Fast forward a few years. The young man is now a 24 year old fully
grown manchild. The progress bar was still updating only very rarely.
On this rainy afternoon, the tinkerer had nothing else to do than
finally get to the bottom of this perplexing behaviour.
Much investigating was done. Did the Observer have a logic bug? No,
if we check in the update function by appending a line to a file,
we can see that it works properly. Besides, the logic of this piece
of code surely hasn't been changed for years.
Did maxvalue get set to 100 instead of the number of tiles? No, it
correctly overrode the right method to not just set max_value but
also maxvalue. (Great naming there, aheadley.)
Was it the polymorphic inheritance causing issues then? No, even the
parent class correctly behaved in its update function. Well, almost.
That is when the developer came upon a shocking revelation. His hands
trempled as his fingers moved across the laptop's keyboard, nearly
accidentally entering the "nuclear missile launch" mode in Kate's
Vi-Input editing. The developer added one line to the file.
self.fd.flush()
The progress bar finally worked as intended.
With the changes to things being indexed by path instead of name,
old hashes would stop working. To make this a bit less jarring, we
can fall back to the default tileset of a world, which means the
map would still load.
Overlays should only show up for the base layers they apply to,
however, we've had them show up for all base layers in a world.
To fix this, we first change things to be indexed by the unique path,
not the human-readable name (which is not supposed to be always unique).
Then, we remove and add overlay layers to the layerCtrl as needed on a
baselayerchange event.
Some bad distributions (Debian) apparently are not good enough to
have a Pillow version from this decade packaged.
Therefore, we need to do it the painful way of prefixing our
symbols and refactoring everything to use them.
A new header file called "utils.h" has been added for this purpose,
and it is included in "overviewer.h".
The following macros have been prefixed with "OV_":
- MIN
- MAX
- CLAMP
- BLEND
- MULDIV255
Additionally, the C extension version was bumped to 56 because 55
was reverted back to 54.
Today in "why did we ever do this?", we discover we've vendored
code from PIL/Pillow, but PIL/Pillow moved some macro definitions
around, so now our vendored code conflicted with their macros that
they included in the headers we're including.
The solution is to throw out our vendored macros and update the
semantics in our vendored Draw.c. I'm not sure why we vendored it,
but we seemingly did remove some stuff from it to avoid having to
pull in all of PIL/Pillow.
Apparently TileEntities can just not even exist now, and the same
goes for the player Dimension key. For the latter, I'm not sure
whether the fallback is correct, but it's a guess I suppose.
Hopefully addresses #1480.
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.
This adds a work-in-progress section with a few tips and tricks
about how one should go about contributing to the project. It mostly
focuses on making people familiar with some of the code, and giving
them a few tips along the way on how to work with Git.
A few more contribution examples should be added, and what most
notably is lacking right now is a section about the web output
part. This is due to us currently rewriting it in Leaflet, so any
examples added now would quickly become outdated.
We previously stated that a Google Maps API key is not required.
However, this is not true (anymore). I'm still wary of adding
it to the documentation since my hopes is that in the time it would
take me to add this to the docs I could just finish leaflet, but this
is the least we can do to clear up any confusion.
Also switched some URLs to use HTTPS, which closes#1314.
Lastly, fixed a warning about a not long enough title line.
A side-effect of these changes is that \a no longer gets shown as
'\a', but '\0x07'. Some characters, i.e. \n and \t, are still shown
as '\n' and '\t' respectively, so this comes simply down to repr()
behaviour.
However, I do believe it's worth it to get rid of that ugly code
duplication.
It's EOL in a few days and the instructions only add confusion.
Anyone still using CentOS 5 has bigger issues than not having
documentation on how to build Minecraft-Overviewer.
With newer pillow versions, pillow would create debug log lines for
every single PNG images it touches, so that spams the log in
Overviewer's verbose mode quite a bit.
This is probably a leftover from the memcached thing. There is no
need to hash a key to be used for hashmap access, as the hashmap
itself hashes it already, and probably with a hash more appropriate
for the situation.
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.
I'd move the event setup into addTo, but JS is utter garbage and thinks
"this" in a function callback like that should be whatever, not where you
actually define it.
The spawn and location icons should now have the tip of the icon
image point at the actual location. Previously, the icons were
centred onto it, which was slightly off in the vertical direction.
Unfortunately we need to explicitly tell leaflet not to scale them
weirdly but to make them perceptually equivalent to the normal ones,
which means we have hardcoded icon sizes for those two right now.
Instead of stuffing specialised values into overviewer.collections,
put a reference to the overviewerConfig tileset entry into the leaflet
layer, so that we can access it from callbacks easily.
Nicolas F