the code that calls handleEntities in genPOI was building a list
of all filter funcs in the config, then used itertools.groupby to walk over
each region set, calling handleEntities and passing filters funcs for the rset.
this works fine when all of the renders point at a different world,
since rsets are sorted via __lt__ using the regiondir. when an rset appears in
the config multiple times, groupby can't sort the rsets reliably,
so a single rset is passed multiple times to handleEntities with only some
of the applicable filters. for a config with just two renders of the same world,
handleEntities would frequently be called 5-7 times instead of just 2.
this change eliminates group by, and just iterates over all the rsets, each
time plucking the list of applicable filters based on rset associated with
each filter (simple equality).
use json.dumps(sort_keys=True) to apply a consistent sorting to the output JS files.
improves the readability of diffs and making config testing easier
People could always set this through the config file, but somehow
not the command line. This commit fixes this oddity by adding the
option to the genPOI script's argument parser.
Add support for polyline POIs just like in the good ol'
Google Maps days. See #883.
The format after this commit is:
{ id, x, y, z, text, color, polyline/polygon: [{ x, y, z }, ...] }
Optional properties:
- common ones like "icon" and "hovertext"
- "strokeColor" (string),
- "fill" (boolean)
- "weight" (integer)
Docs not included.
Largely based on PR #1536 by @jsmienk.
Closes#1456, closes#1536, closes#1643.
Apparently the gzip stream can be malformed in a way where it
does read it, but then throws an EOFError when it abruptly ends.
Catch this so we don't error out.
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.
Use CroppedRegionSets to generate markers, which should only affect
handleEntities. I have not yet checked whether this generates
dupicate players and manualpois for maps with multiple crop zones,
but that's a fire to put out for another day.
Fixes#1574.
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.
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.
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.
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.
Entries in the uuidcache will now be considered expired if they were
retrieved before the mtime of the player dat file. This follows the
recommendation made in issue #1279.
Minecraft now uses minecraft:sign as its id for signs, but also uses
Sign for older versions or chunks that have not yet been updated.
Change the genPOI sign wrangling code and the documentation to reflect
this change.
Fixes#1340.
Previously, the files were not closed after reading or writing;
by using a "with" statement, the file handles will be closed as
soon as they go out of scope.
Possible fix for #1271.
* When reading the cache, catch some errors on load, instead of crashing
* When writing to cache, write to tmp file, then move it into place.
This should be more robust if a ctrl+c is recieved while writing the
cache
Addresses #1266
