insomniac_lemon

Still affects 1.11. (see screenshot 1.11_still_affects.png)

Also I'm using a GTX 1050 Ti now so I can confirm that this isn't caused by having an old GPU (like I described in my previous comment).

The fix to this that doesn't seem like a strange quirk would be to add full sticky piston chaining: when sticky pistons are retracted, they will pull other sticky pistons and slimeblocks so long as they are facing the same direction. Pulling ANY connected would complicate things, but would also allow more elaborate contraptions (connected blocks can always be slid off using non-movable blocks like obsidian, or pushed off since stickiness would not go both ways) so I guess it'd depend on how the community feels about it.

Chaining will simplify the needed redstone immensely, especially for longer chains. Instead of a simple on circuit and an advanced off circuit that needs to recursively de-power and re-power the chain to retract all pistons and move the target block, it will instead be completely the reverse circuit design (a simple line of pistons will be powered back-to-front and de-powered front-to-back). This is how the original piston mod functioned: https://youtu.be/mQEgPPjLoG8?t=57s

This, along with lower restrictions on slimeblocks (like making restrictions individually counted, that way the amount of normal blocks you can push... but then pistons are not counted in that number, and slimeblocks would count the number of self-connections they have versus the amount of non-slimeblock connections they have) would make big slimeblock doors possible (that are aesthetically pleasing) that don't close incredibly slowly like this: https://youtu.be/ZZXThD0pBLs?t=15s

Still affects 16w33a, please reopen. It has changed, lighting seems no longer linked to external events, but blocks (and items if using a resource pack with item models) are lit from below rather than how they appear in the GUI...

Added a resource pack (mc_30630.zip) to make the issue clearer. It has both a colormap and double-tall textures. The colormap has exaggerated colors that are can be chosen for each height (which makes the issue much more noticeable, and the double-tall textures are included because dual-coloring looks much worse on cleaner textures that are more unified between the two blocks ('airy-er' textures, especially those with somewhat noisier textures might have the issues be less noticeable).

As with all properly zipped resource packs, simply download the file to your resourcepacks folder and then add it to the top of your resourcepack-stack to see its affect.

It should affect most biomes, the exceptions are those without color variance (I think deserts and the nether fall under this) or those that don't use the colormap (swamps and mesas... swamps DO have color variation but I don't think it's height based, so won't trigger this issue)... roofed forests also only partially use their biome colors, so might only have a partial variance effect.

A good way to see the issue (besides searching for a plains biome or spamming double-tall grass everywhere) is to place 2 grass blocks down (on top of each other)... if the color of the bottom and top mismatch, so will the double-tall [grass/fern] in the same spot.

Confirmed from 1.9 through 1.9.1 pre-3, please reopen.

Yes, it appears to be fixed.

I have the feeling that the example 'fix' code could also be applied to defining elements for custom models and it would fix MC-73186 as well. Although both are UV bleeding, just in different contexts.

I forgot to post it here, but I discovered that you if you add culling to models it works in fast mode. The issues with it are:

a)It does not allow for models to use culling in fancy mode
b)It requires culling to be explicitly set, although this was not previously needed
c)Since default does not set it, most users are rendering unnecessary leaf faces unless they have a resource pack that explicitly tries to solve this

So you should remove your hack that makes leaves treated as a opaque block. The only time where leaves culling opaque blocks is more beneficial than leaves culling itself if when a single leaves block is touching the ground, in any other case there are more faces inside a cluster of leaves blocks (such as on trees) and the amount of opaque faces culled is minimal in comparison. So the hack isn't even really needed.

There is also a good behavior to go about this that's friendly to resource packs: only override the culling if it's unspecified. That way certain parts of leaves can have culling in fancy or they can be in fast mode without culling.

Predicates could also be used as a non-hacky way to specify another model to be used in fast mode. If this were a global override, that'd be a great way to allow resource pack makers to make lower-detail models for any block/item for those having poor performance. Or, if variables (similar to how textures are used) could be used on cullface and predicates without models could be used to only override culling and possibly textures, that'd be a good solution as well.

Although if opaque blocks are not culled by leaves in fast mode, there is little reason to not allow them to have transparency. It might be a bit odd to see them looking so hollow, but they could benefit from 'leafy' particles on the inside especially considering particles now have less performance impact, in fact it might even be visually better than how fancy leaves are now and perform better since there are less faces being rendered and because particles can easily be scaled to lower numbers. It could even use areaEffectCloud.

Grum, can I get some explanation behind the WAI?

I feel like this could be a misunderstanding behind one of my screenshots. To be clear, what I recommend changing:

• in fast mode, all internal leaf faces are culled (by other opaque blocks and themselves)

• leaves no longer cause opaque blocks to be culled (not the issue at hand, but this gives minimal performance benefit while having an X-ray effect... so not really needed)

This is basically the opposite of what fast leaves do now. However, in vanilla SSP, most situations with leaves probably have more internal faces with leaves than opaque blocks (tree trunks, grass, etc.) especially in large jungles/forests. So you should get better performance not rendering the leaf internal faces than not rendering internal opaque blocks.

Confirmed fixed for 15w49a.

However something to note is that existing suspended tripwire hooks will still be broken, must be taken down and then replaced in order for the activation animation to appear properly. Please keep that in mind.

Sycholic, did you look at MC-93554? It's about ALL z-fighting in the game and covers at least 7 other issues.

So a mod forgot to comment "resolving as duplicate for a more general issue". And if it feels bad, I have one of my issues (a typo I had posted near when it happened and kept the affects versions up-to-date) marked as duplicate because a newer version of it (what should have been marked as a duplicate) was posted and the dev saw it and fixed it... afterwards mine was marked as a duplicate...

Just remember that bug trackers are free-for-alls.

Can you confirm if there are any that will likely NOT be removed? Yeah, some of these don't currently work right (and like some of the growth stuff, was likely internal stuff only, didn't act right when you could see it) but some should already work provided you fully use multipart, and some of these are really useful to have.

Redstoners would greatly benefit from being able to use a resource pack that can make disabled hoppers look different (this works) and when command blocks are activated (especially since chain command blocks are a thing, but this might not work). Activated tripwire/ filled jukebox stuff is also useful (I can confirm has_record works perfectly already) and good for aesthetics.

It makes sense to lose:

• bed occupied state: minor aesthetics and likely internal only in a buggy way

• reeds/cactus growth stages: player placed ones are completely screwed up... though this could be fixed by making setting the age to max when the same block is placed over them and set to minimum when the same block is broken over them. Still a minor change, even less useful for cacti since it has collision.

• unused snowy states: since snowy likely never was intended to be added onto dirt

• dispenser/dropper triggered: since they already give signs of activation

• TNT 'explode' state: it doesn't make sense to control entity models through a blockstate... unless this is about the ones that break on-contact, then it's misleading ('volatile' would be a better name) and it makes sense to lose that since you can't get it in default

• doors' 'powered' state: not that useful, and iron doors can't be open and unpowered (or powered and shut) anyways.

So much of it is justified in being thrown out, but the rest I'd hope can stay since they are 'stable' in function as well as useful to a large scope of users.

Have you tried offsetting one slightly? They probably only set the second half off once because they activate it at the same time. Try starting one side with a repeater (or both sides with differing delay repeaters).

Michał. I wouldn't say so because with 0 light (not covered by slabs) you can see the shulker because it isn't pitch black.

If anything, this is caused by the game thinking the shulker is fully encased in blocks. As a test: same setup as the shulker, but dig a block down. Place a skelton there and then the slab. Notice the skeleton turns pitch black as well (if it isn't on fire). This same setup with work with the foot section of the skeleton exposed to light but a slab through the torso as well.

Now remove the slab, kill the skeleton, and dig another block down. Place a skeleton and slab again... it's darker but not nearly pitch black (noticeably brighter than when encased in slabs, although still light level 0).

I have updated my debug pack to show MC-50817 in action, as well as show iron bars without the line in them. 50817 is needed to be solved even for this issue to be fixable by resource packs.

Here is the pack:
https://bugs.mojang.com/secure/attachment/105321/jira_debug_insomniac_lemon_v3.zip

Updated example pack. Has iron bars model from 15w47c with culling enabled on top/bottom faces showing that culling is happening in places it should not.

It also shows the removal of the middle faces on that previously didn't render on walls of iron bars, something is part of MC-62118 that wasn't addressed.

Kumasasa, MC-72891 is in no way related to this issue. That issue is about backface culling being used on iron bars, and seems to be fixed already. This issue is about inter-block culling, not backface culling.

EDIT: MC-72891 is actually a duplicate of MC-62118 which has been partially fixed. The complaint they do share certainly has been fixed.

Zaggy1024, removing randomized models wasn't needed, I'm not sure why it was removed since I uploaded that only to show Grum that the rotation on a non-rotated block of TNT and lit TNT didn't match (in other words, lit TNT added its own rotation).

The rotation itself is fixed as is, at least for non-randomized TNT. I'm not sure what redstonehelper is talking about though (unless it's different in SMP) because lit TNT takes the default rotation (or really, that entire first line) of block TNT.

A simple blockstate test:

{"variants": {"normal": {"model": "tnt", "x": -90 }}}

Notice that when you light the TNT, it stays exactly the same. If you have random options, the first is used. That means lit TNT simply inherits the default versions of TNT...

Another thing this means is that random TNT rotation can be added back with a resource pack... when lit, it won't match the random options but it will match the first.

Patrick, it's still based on a bug even if it's useful. It's a day*light* sensor, if there's no daylight (or 'moonlight') and it behaves rather erratically, it's clear it's not an intended feature.

Plus, does this bug even do anything now that cannot be achieved with proper skylight, daylight+inverted daylight sensors, and redstone logic? See Jeb's comment on July 30th 2014, inverted sensors were added to replace this bug. Use one of them either with a skylight, or above ground with redstone (or even piston activation) going down to your contraption.

Because honestly, if you just don't want your stuff to be reworked, that's not a reason to keep this. Daylight sensors working properly underground brings unique contraptions. Secret doors that open or close (or traps being set off!) when a room is broken into or sealed off. Jungle temples could explode if you try to bypass the puzzle (I was able to make a simple design to do this... but unfortunately it went off because the pistons moved too slowly to cover a daylight sensor before light got to it). Mapmakers could use it as a proximity sensor especially if the user can break a certain kind of block (or use TNT) to get to secrets/easter eggs. Anything close to that is currently impossible due to the false positives.

I'm sure above-ground sensors and redstone logic can replace the current buggy underground function. It seems like it currently just detects sunrise/sunset, regular gaining signal it should not have and inverted being even worse with being on almost all of the time and then dipping to 0 on sunrise/sunset. With above-ground sensors you could replicate that (or have only one if you wanted) by circuits that activate something else for a short time after they deactivate. (pistons would probably be a good way to achieve this).

Grum, unless you have changed the culling system to *fix MC-50817 OR you implement up/down states as Meringue **suggested above then this issue is only half fixed.

People don't want to see horizontal faces through their iron bars or glass panes... (besides just being visually jarring and ugly, it differs from past behavior of iron bars/glass panes)

*= either detecting the state/model a block uses and only cause culling if it's a match/covers all faces... allowing culling on top/bottom faces without issue

**= so culling isn't needed here to have faces on the top/bottom but NOT on the inside... similar to the fix I employed which uses 1-connection states for the sides