- Add all possible variants of mushroom blocks introduced in 1.13
- Render mushroom stems similarly to red/brown mushroom blocks
- Add vine variants where vines are on the upwards facing side
- Use 'lit' property to determine when block is on or off
- Account for facing when generating textures
- Clean up smoker/furnace/dispenser/dropper texture generation code
- Fix extended pistons rendering as if they were retracted
- Fix retracted pistons rendering completely dark when using a
lighting rendermode primitive
- Use piston head 'facing' property to determine rotation
- Use piston head 'type' property to determine if sticky or not
- Add beds with colors other than red
- Use bed 'facing' property to determine bed's rotation
- Use bed 'type' property to determine if the head or foot is rendered
- Correct faulty logic during bed texture generation
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
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 adds:
- mossy stone brick stairs
- mossy cobblestone stairs
- mossy stone brick walls
We also add another block class for walls, and while we're at it,
clean up the stairs texture function to not have a huge sprawling
elif mess for loading textures, but instead to a cheeky dictionary
lookup.
In case you're wondering, yes I am just as disgusted by this code as
you are.
If the first texture loaded was not in the pack, i.e. we fell back
on system textures, then the pack was ignored altogether for the
remainder of the render.
Here we fix this by using an OrderedDict instead of the split jars
and jarpath nonsense, and then always checking the custom textures
first and opening them if they are not already open, and putting
the jar file handle at the start of the OrderedDict.
We also switch around some logic to avoid unnecessary isdir calls
when we're using a resource pack.
Sometimes a texture pack is not complete, but system textures are
available to make up the difference. In that case, we should load
those.
Current caveat is that we might not notice texture names changing
with newer minecraft clients because we have old ones installed.
I'll have to think some more about that one.
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.
