pkfortis

Sigh. The pack I uploaded had some .mcmeta formatting issues, causing the overlays to fail to load; please use this one instead. It should load on both 1.21.8 and the snapshots so you can compare the differences in how armor renders.

Also, to clarify, the “second layer” I’m referring to is not the “layer 2” texture, but rather the part of the helmet/chestplate texture (iron_layer_1 in the old format, now it would be textures/entity/equipment/humanoid/iron.png) that would typically render as a second layer on top of the helmet.

The iron helmet texture I provided does indeed have a second layer; it’s the part that looks like a crown in the upper right quadrant of the iron_layer_1 texture. I tested the resource pack that BugTracker uploaded and it implements the textures correctly, but it’s incorrectly zipped; you’d have to copy the “MC-300723” directory within the zip file into the resourcepacks folder.

It’s a little big (I haven’t had a chance to run pngcrush or similar on it in a while), but I can also provide the resource pack I am developing; it’s where the original screenshots came from. I can confirm 100% that every single piece of armor in this pack (except copper) has a second layer on the helmet. Most (if not all) trims also have a second layer on the helmet part.

Oops. I meant 25w35a, obviously.

This bug persists in 23w35a.

As noted in the edit, this issue also applies to armor trims' second layers. I don’t have an example of this handy that doesn’t use my custom trim color palettes, so I’ll include the base palette, the gold palette, and the coast armor trim (leggings not included as they don’t use the second layer).

This issue applies to the second layer of all armor pieces, not just leggings. It’s most noticeable on leggings without a resource pack set, but if the active resource pack includes anything on the second layer for other armor pieces, the lack of rendering is very apparent.

@unknown, it may well be an unintended consequence of the fix, which would, in fact, make it a bug. We are not demanding a specific solution as you seem to be implying, we're pointing out that it's happening. Whatever happens after that point is up to the devs.

In my experience, submitting feedback through the official feedback site is not a productive use of time. If the developers respond to this report by closing it as Works as Intended, so be it.

This seems like a pretty over-the-top fix for a very minor cosmetic problem that could have been solved by editing the helmet textures in question rather than limiting what resource pack makers are capable of doing, but I can't say I feel particularly inclined to argue with the devs if this is how they decide the issue should be solved.

Given how they are exclusively per-world or per-server, installing a datapack just to change the grass color seems like something that just really shouldn't be necessary. Colors for grass and foliage, along with pretty much all other visuals, are traditionally controllable by the resource pack, and anything else is just weirdly inconsistent with established functionality. It's especially weird given that the developers are able to adjust the colormap however they see fit, up to and including adding little blob of #B6DB61 wherever the Cherry Grove's single pixel would end up on there based on the temperature and humidity values. 

I don't think anyone would disagree that resource packs are an extremely important part of Minecraft, and they're designed specifically to have their own looks in terms of visual style and color palette. If this decision was intentional, and we can expect more biome colors to be unchangeable without datapacks in the future, it's just kind of a slap in the face to resource packs in general.

All textures in /assets/minecraft/textures/entity/chest/ in the 19w38b jar have been changed. The rows have been flipped (looks like the top and bottom faces of both the lid and body of the chest have been rotated 180 degrees counterclockwise, while the sides seem to have been flipped vertically), and the front faces of the chests have moved to the far right side of their respective rows. The latch texture also looks like it's been inverted:

Normal chest texture from 1.14.4:

Normal chest texture from 19w38b:

I applied the changes to an existing resource pack to make them match the textures in the 19w38b JAR and chests render normally again.

By all appearances this looks to have been an intentional change to the chest model/textures that wasn't documented.