Can confirm on snapshot 4 on Windows

Can confirm on 26.3-s8, relates to MC-299683 as noted by @ Rebel459

Cause and Fix

Alright, so this is because the old way of choosing creative music that didn’t look at the biome’s parameters https://mcsrc.dev/1/1.21.5/net/minecraft/client/Minecraft#L2477 was replaced by one that checks for it in the biome-dependent build https://mcsrc.dev/1/26.3-snapshot-8/net/minecraft/client/Minecraft#L2692 except none of the biomes actually defined the creative music so it falls back to survival.

To fix it, one can add the creative music back to every biome in OverworldBiomes.

One way is to change the single-parameter constructor for BackgroundMusic to have creative music. This requires the fewest line changes, and has some side effects, like adding creative music to the nether which was not the behaviour before 1.21.6

Another way is to add a two-parameter constructor, and use it for all the biomes. There are only 23 constructor calls in the overworld which can probably be replaced quickly with pasting or a regular expression.

You can also use the full three-parameter constructor, though that may be verbose.

Finally, you could create a method like BackgroundMusic.withUnderwater() to add creative music. Again, that’s currently 23 constructor calls to append .withCreative() to.

For example, after writing something relevant in BackgroundMusic, replace all (new BackgroundMusic\(.*)\)\)$ in OverworldBiomes with $1, SoundEvents.MUSIC_CREATIVE)) or $1).withCreative())

I still believe that the creative music needs to be able to play in these common biomes in creative. If biome-dependent songs are something you also want to keep, you could rework the creative sound event to also include those songs at the appropriately low weights.

Fixed in pre-3

You can load this pack above the built-in Programmer Art pack to reproduce the bug. Acacia leaves have the expected appearance, dark oak leaves have a deliberately incorrect appearance. Due to the pack not changing oak leaves, that can be used for the observed appearance.

Seemingly fixed in pre-2.

Hi, could this please be reopened? This is meant to be the same as MC-269523which was confirmed as normal priority. Alternatively, I could formally move the Creaking into that ticket. The Copper Golem does not have this bug, meaning the issues is contained and would likely not have to be expanded to mention more mobs.

Another way to verify the bug is to add distinct subtitles to all the music sound events and notice that certain biomes don’t use the subtitle for music.creative as it is supposed to.

My apologies, it’s a combination.

This is not a duplicate of MC-300108, it is a duplicate of MC-141075.

I disagree with this conclusion because the glow (and thus fully powered) part of the redstone torch has not changed; only the firey part which is not the redstone power itself. When the photo attached is in thumbnail form (zoomed out), the colours look quite similar overall.

I have been unable to reproduce this, but it may relate to or be an evolution of MC-299683

What dimension and biome were you in when this happened?

An easy fix if we could revisit would be to copy a working texture from the Bedrock Edition of the game which would work just fine if we want to call it parity.

Hello, would it be possible to reopen this one as its own standing ticket? The original post is not articulate at all on the issue, and I would be happy to help update the description with new evidence.

In the time after the resolution of this ticket, Mojang choices suggest that this special case is actually not a duplicate of MC-169889:

As has been pointed out, old textures not from immediately prior to the Texture Update have been added to Programmer Art (see crying obsidian). Similarly, leather horse armour has been in the Bedrock Edition since 2016. Old textures already exist there, ready “for restoring” (the definition provided in MC-169889). This sets it apart from the likes of MC-159632 despite similar wording on the tickets.

Furthermore, the recent fixes for MC-280047 and MC-280278 demonstrate that additions need not be drag-and-drop for inclusion in Programmer Art. In fact, the 1.21.5 cycle demonstrates an openness and willingness to put in effort, such as the re-creation of previously generated spawn egg textures—some of which never previously existed on their own.

Please consider rectifying the current erroneous resolution. I acknowledge that reopening does not in any way guarantee a fix (I’ve seen that before). But for the integrity of bookkeeping, we ought to set the story straight by giving this ticket the opportunity to stand on its own in the current context. Thank you!

I think now is a great time to fix this, given the model adaptations from the Spring to Life release and the fix for MC-280047 also making minor adjustments to ensure the model works properly.