AgentMindStorm2

In 1.21.110.24, Mojang added the biome_music definition to all Nether biomes and the normal roofed forest. This has not resolved the issue because all the following biome groups are still missing the component:

• Swampland (all)

• Peaks (all)

• Meadow

• Grove

• Snowy Slopes

• Cherry Grove

• Birch Forest (all)

• Roofed Forest Mutated

• Forest

• Flower Forest

• Mega Taiga (all)

• Redwood Taiga (all)

• Mesa (all)

• Desert (all)

• Lush Caves

• Dripstone Caves

• Deep Dark

For this issue to be resolved, all these biomes need the correct biome_music configuration. I have tested and confirmed personally that adding the component with the right definition to these biome files fixes the music issue.

I also encountered this issue and did some investigating to figure out why it’s happening. Here is a more thorough description of the issue:

Title: Smooth lighting on partial blocks is broken after 1.21.100

Description:

Smooth lighting has completely broken for partial blocks as of 1.21.100. This was not an issue in 1.21.94. This change from the 1.21.100 changelog has most likely caused the issue:

• Fixed faces of non-full blocks (eg. Cakes or Trapdoors) having an unnatural ambient occlusion applied to them in some neighboring blocks configurations

This has actually made lighting significantly worse for all non-full blocks. It is most noticeable on snow layers and village paths, since they are light in color and often surrounded by full blocks.

List of confirmed affected blocks:

• All slabs

• Snow layer

• Dirt Path

To Reproduce

1. In the main menu, navigate to Settings → Video → Graphics Mode, and select Fancy.

2. Enable Smooth Lighting.

3. Enter a world in Creative Mode with Cheats enabled.

4. Type the following command:

   1. /locate biome minecraft:snowy_slopes

5. Teleport to the Snowy Slopes biome.

6. Observe a sloping hill with snow layers.

7. Observe the unnatural lighting on the snow layers.

Expected Result

Lighting is smooth on partial blocks when next to full blocks.

Observed Result

Lighting on partial blocks looks unnatural next to full blocks, with a harsh dividing line at the edge of the partial block.

Can confirm in 1.21.93.

The environmental fog from Java Edition is nothing like Vibrant Visuals' volumetric fog. The Pale Garden fog, for example, is handled differently, being extremely thick on Bedrock while basically unnoticeable on Java.

Vibrant Visuals is not a good reason for Fancy Graphics parity breaks in general. Do the new cloud changes from Java Edition intend to match Vibrant Visuals? Not really; in fact, Bedrock clouds are still as limited as old Java clouds in Fancy. I don’t see why the fog would be different.

Can confirm.

This may be caused by https://report.bugs.mojang.com/servicedesk/customer/portal/6/MCPE-219051

This is not a bug. Sound events choose a random song from their list, and there is nothing in place to prevent the same song from being randomly chosen multiple times.

Humans are bad at perceiving true randomness: https://www.howtogeek.com/847793/why-spotify-shuffle-is-not-truly-random/

This is more of a feature suggestion than a bug report.

Can confirm.

To explain:

The linked report in Greymagic’s comment is about the delay configuration in music_definitions.json. That report talks about how the delay between songs is incorrect.

This report is about the song sound location in the world. The main issue is that you can walk away from ambient music. This is clearly a different issue than the delay between songs.

Replying to GoldenHelmet:

You are half correct, but adding to sounds.json won't solve the issue.

Sounds which are played through animations like spin and the chest open/close sounds follow different volume rules than sounds played through sounds.json. Animation sounds have no attenuation distance limit. Also, volumes above 1.0 to affect the playback volume, instead of the attenuation.

The solution is to add a “max_distance”: 16.0 setting to every copper golem sound event in sound_definitions.json. This is how this same sound distance issue was solved for the Breeze.

This resolution is wrong. The linked report describes a completely different issue. I would know because it’s my report.

I'm glad to hear that the labels are being considered for Manifest V3, but I think this is still a valid report, because Manifest V2 functionality shouldn't change just because a new system was added.

This issue was fixed in 1.21.80, as the game no longer crashes in that version.

I’ve actually noticed this flickering in first-person view as well. It happens with vanilla entities and entities from Add-Ons in 1.21.92.

Not all textures have MER maps. Textures without them fall back to the default configuration, similar to Add-On textures.

The original 12 music discs don’t have MER maps either.

Here is a sample pack.

Steps to Reproduce

1. Import and apply is_carrying_block_sample_pack in the latest preview. (1.21.100+)

2. Enter a world with Cheats enabled.

3. Switch to third person front camera so you can see yourself.

4. Run the following command:

   /replaceitem entity @s slot.weapon.offhand 0 amethyst_block

5. If the is_carrying_block query worked correctly with the offhand, the player’s head would now be floating.

6. Observe that the player head is not floating.

7. Run the following command:

   /replaceitem entity @s slot.weapon.mainhand 0 amethyst_block

8. Observe that the player head floats.

9. This means query.is_carrying_block always checks the main hand, even when the offhand is specified, which confirms the issue.

This is the animation used in the sample pack. It is formatted correctly:

Holding offhand block (Head should be floating, but it’s not):

Holding mainhand block (Head should not float, but it does):

Sample pack required to reproduce:

I experienced these bugs on Windows. They also affect 1.21.92 (the hotfix did not solve the bug)

Duplicates two issues:

MCPE-221350

MCPE-219051

These issues may also be contributing to the problem:
MCPE-222958

MCPE-223046