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
On Windows with mingw-w64, Pillow includes windows.h, and thus
including Imaging.h would result in a name conflict of "TRANSPARENT",
which windows.h #defines but overviewer.h wants to use as enum.
For the record, this used to not be broken back when I initially
fixed Pillow for mingw-w64, so the change got somewhere introduced
between then and now.
There is no point in ignoring an invalid point, because without an error
message the user might wonder, why it's poyline doesn't look the way it
should.
One should use isinstance instead of `type(A) ==` because of
inheritance.
There should be an exception if a list of `elif`s don't match.
Make Polyline not only accept tuples, but any iterable.
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.
A usecase to demonstrate a possible application of the extended functionality:
**"Rails Overlay that draws only the rails that are on Cobblestone for a subway map."**
With this patch it is very easy to achive that:
```python
MineralOverlay(minerals=[(((0, 0, 0, 66), (0, -1, 0, 4)), (255, 0, 0, 255)),
(((0, 0, 0, 27), (0, -1, 0, 4)), (0, 255, 0, 255))])
```
In this case the overlay will be red for rails on cobblestone and green for powerrails on cobblestone.
The syntax is `(<tuple of conditions>, <target color>)`
* where `<target color>` is a 4 tuple with a `(r, g, b, a)` color
* and `<tuple of conditions>` is a tuple with an arbitrary number of conditions with the following syntax:
`((relx, rely, relz, blkid), ...)` where the `rel<>` parameters specify the relative coordinates to the block that is checked if it matches bklid.
In the example the fist tuple `(0,0,0,66)` checks if at the current position is a
rail while `(0,-1,0,4)` checks if at one below the current position is a cobblestone.
If both are true then the color `(255, 0, 0, 255)` is used.
A Sample Config file exploiting the capabilities:
``` python
worlds['My World'] = "~/.minecraft/saves/test/"
outputdir = "/tmp/test_render"
rendermode = "lighting"
renders["render1"] = {
'world': 'My World',
'title': 'A regular render',
}
renders["render_overlay_dafault_rails"] = {
'world': 'My World',
'title': 'Default Rails',
'rendermode': [ClearBase(), StructureOverlay()],
'overlay': ['render1'],
}
renders["render_overlay_cust_rails"] = {
'world': 'My World',
'title': 'Custom Rails',
#relative coordinates [[(relx, rely, relz, mineral)], (red, green, blue, alpha)]
'rendermode': [ClearBase(), StructureOverlay(structures=[(((0, 0, 0, 66), (0, -1, 0, 4)), (255, 0, 0, 255)),
(((0, 0, 0, 27), (0, -1, 0, 4)), (0, 255, 0, 255))])],
'overlay': ['render1'],
}
```
The "Default Rails" overlay uses default coloring of the structures overlay. "Custom Rails" uses some custom coloring.
fixesoverviewer/Minecraft-Overviewer#556 and fixesoverviewer/Minecraft-Overviewer#787
