Previously, any kind of interruption during tile re-arrangements
would leave the tileset in a half re-arranged state.
This commit makes _increase_depth roll back possible changes it did
during the re-arrangement prior to it being interrupted.
Fixes issue #1166.
* Add 2 FAQ entries, one concerning mod blocks, the other
about the maps API.
* Add note about The End and lighting strength. (Closes#1111)
(Also, nice quads.)
Instead of doing the UUID->name resolution for all players in every
case, only do it when EntityId is accessed and the name hasn't been
retrieved this run already. This makes genPOI usable for people who
have many players on their servers but don't wish to use player POI
while still using other genPOI features.
To do this, a PlayerDict has been created, which contains a dirty
hack to see if the requested item is EntityId and whether it hasn't
been set already.
The validator will now warn if it detects that a crushed output
is fed into something that is not a crusher.
The is_crusher method of an optimizer shall return True if the
optimisation process is lossless, and does try to find optimal
encoding parameters as opposed to only removing unneeded channels
or reducing palettes.
Before someone says this is incorrect because it only ever uses
pngcrush: The old code always used pngcrush and nothing else
anyway. This is absolutely correct and the old behaviour.
I also added a check to make sure it's a list, as some people might
forget the whole list thing.
When HOME was undefined on Linux, the code would try calling
os.listdir(None) which will obviously fail.
This is a workaround. A proper fix would be to rewrite the
code to check for each operating system, not a combination
of operating systems, environment variables and the current
air humidity in London.
is_transparent returns 1 for every unknown block because that's an easy way to
make them ignore lighting, however, this makes cave render useless with a map
containing unknown ores.
The definition is_known_transparent checks whether a block is transparent and is known.
This is a workaround, a proper fix would be to have unknown blocks be neither transparent nor
solid. Or make them both. But don't prefer one of the two.
Up to this point, when launching overviewer with python3, overviewer would
(ironic as it is) crash on the line where the error message would be displayed
with a syntax error. I have now fixed this.
* Added paragraph and example about returning tuples from a filter
(Issue #859)
* Added section about manualpois
(Issue #858, Issue #869, Issue #598)
* Fixed a typo in the FAQ
* Added logging to file to the FAQ
(Issue #871)
If the returned type is a tuple, it will be interpreted as first the
title (i.e. hovertext), then the content of the infowindow. If the
returned type is a string, it will be used as both the title and
infowindow content (the old behaviour). This means that older configs
are still compatible and need no changes.
Here's how to use it:
have a list called "manualpois" in your config filled with objects that contain
the attributes id, x, y and z. Feel free to add more attributes as you need them.
Then, write filter functions to filter for your custom POIs (hint: use the id).
Nicolas F