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.
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.
In the process, we can clean up some of the command line argument
handling. Sadly, argparse's mutually exclusive groups are too
primitive to get rid of the autocrop/manual crop conflict checking,
but we'll have to live with those two lines I guess.
This script apparently also works with Python 3 now, which is neat.
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.
Nicolas F