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
Sometimes people's texture packs contain weird things, and it'd
be good if instead of throwing an unhandled IOError, we raise
a TextureException with the filename in it.
Also, make verbose mode actually run find_file in verbose mode,
which is useful for finding where Overviewer loaded that texture
file from.
This reverts commit 9895fe875b.
The original code was correct, but confusing. Overviewer did regenerate
the texture in each worker process because Python pickling is incredibly
fragile fucking garbage designed by idiots who have no clue of what
a good language looks like.
We used to generate textures multiple times for each worker process,
which didn't seem to be intended as it was done gated behind a reversed
if statement. It just so happened to fix an issue introduced by the
pickling code which was deleting vital attributes like the actual
generated textures.
I'm honestly not sure why this was ever done, so let's just throw this
out and call it a day.
Fixes#1728
- CroppedRegionSet is a Wrapper for RegionSet and should have all of
it's Variables / Parameters
- genPOI sorts a list by (Cropped)RegionSet objects
- The comparing method (__lt__) was correct in CroppedRegionSet but not
in RegionSet. To prevent this issue from happening again, the
RegionSetWrapper now has the regiondir property, too
- Fixes Issue: #1706
- Example config: see below
def testFilter(poi):
if poi['id'] == 'Town':
return poi['name']
def townFilter(poi):
if poi['id'] == 'Town':
return poi['name']
renders["normalrender"] = {
"world": "Test12985",
"title": "Normal Render of Testworld",
'markers': [dict(name="Towns", filterFunction=townFilter), dict(name="Test", filterFunction=testFilter)],
}
renders["secondrender"] = {
"world": "Test12985",
"title": "Second Render of Testworld",
"crop": (180, -230, 220, -260),
'markers': [dict(name="Towns", filterFunction=townFilter), dict(name="Test", filterFunction=testFilter)],
}
Resolves an issue where chests with more than one adjacent chest would
fail to render. Instead of distinguishing double from single chests by
checking for the presence of adjacent chests, use the provided "type"
property of chests to determine if they are single or the left/right
part of a double chest.
This fixes a bug where a world with multiple layers with different
"northdirection" values would initially load at the wrong center point
because the center for the last layer would override prior values
in the overview.collections.centers map.
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.
Don't use .append(), we already know the final length. Instead,
have python initialise the list of a certain size and set the elements
in it.
Makes the function like 4% faster.
Turns out my previous grasp of how Minecraft does this was wrong.
This seems to be the correct way. One side effect is that biome data
now has less resolution. One only really notices this when looking at
water, for which Minecraft does not even use the water colours for
in-game, otherwise I can't really tell a big difference.
Fixes#1698.
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.
Okay so you know how you have chunks and they map to 4 levels of biomes?
Logically you'd go hmmmm, let's just map 4 Y levels to one biome level.
Except there aren't 16 chunk heights, there are about 17 if you count
Y=16 (which can contain data), but there's also -1 technically but I've
never seen this have data in an NBT structure I don't think.
Anyway, let's just hope we're doing the right thing by giving Y=16 the
same biome as Y=15. If someone wants to check whether that is actually
correct please feel free to, but for now it's better than crashing at
the very least.
Would be nice if we had a spec for these kinds of things.
Fixes#1685.
Apparently rotated worlds would try to access the biome for Y-level
-1. I don't know why they do that (probably some dumb reason that may
be a bug in of itself) but returning the first level should be harmless.
Fixes#1683.
Fixes#1650.
Mojang changed the biomes code so that it now can have different
biomes for different Y levels. We need to adjust our logic accordingly,
which is done through some small BiomeDispensary class where we shove
a numpy'd Mojang array in and can then read out the biomes for each level.
Biome data is now stored per-section, which needed some changes on the C
side of things. I didn't change anything in the biome overlay code so
I wouldn't be surprised if it's broken now, but for the time being I'd
rather have 1.15 fixed than some obscure overlay.
Tested to work with 1.14 and 1.15 data. No new biomes have been added
to the code yet.
Nicolas F