mgatland

To prevent confusion I removed the suggested fix from the description since we've chosen a different fix.

Wandering Traders in the Villager Trade Rebalance should sell Mangrove Logs but should not sell Warped Stems or Crimson Stems.

The set of Logs they can sell should match the set of Saplings and Propagules they can sell.

Our intention is to have 2 Sus Sand blocks in each Desert Well. The other disparities were already fixed in a previous release so the Desert Well in BE is already working as intended. I'm closing this as fixed.

I'm closing this as 'Works As Intended'. It is intentional that a new raid cannot be started during the victory celebration, and this matches the behaviour in Java Edition.

We know that this change nerfed raid farms. This was a natural side-effect of bringing raids closer to parity and was not a deliberate attempt to slow down raid farms.

Increasing parity is important for the future of the game. We care about farms and technical players, but in this case we think it is more important to bring villager systems to parity than to keep raid farms working with the same rates as before.

We're marking this as 'Works as Intended'. /kill @e will kill spectators in Java Edition so we have made it work in the same way in Bedrock Edition.

We are discussing this inside Mojang and might change this decision later. In Bedrock edition, /kill @e ignores creative players and it would make sense for it to also ignore spectators, but this would mean introducing a parity break with Java Edition.

Thanks for the report.

This is Working as Intended for the initial implementation of Spectator Mode. See the changelog for details of what was intended in this version.

We have not included every feature from Java Edition and have chosen to focus on the parts of spectator mode that we hope will be most useful. In this case, we chose to disable the inventory completely as it was easier to do and that meant we could release Spectator Mode sooner.

If you have feedback on what should be added to Spectator Mode next, please post it on feedback.minecraft.net.

The Goat Horn is meant to drop when the goat rams a Coal Ore. This was accidentally omitted from the change log. Nice work on spotting this mistake!

I see similar numbers of panda spawns in 1.17 and 1.18 Pre-release 6, so I'm closing this as 'Cannot Reproduce'.

If you can find some clear evidence that panda spawning has changed between 1.17 and 1.18, please open an issue with a repro case that lets us see the difference between 1.17 and 1.18 🙂 

Please raise a new issue with the repro steps from @unknown's post and mark that it 'relates to' this one : )

Can you cause the corruption by putting chests inside chests over and over again, without using bundles?

This change was intended, so I'm closing this bug report as 'Works as Intended'.

However, we are interested in feedback on these changes. You can post feedback on the official Minecraft feedback site or in other online communities like the Minecraft subreddit.

When we fix this, the fix will only apply to new bundles. If you keep a bundle from a previous snapshot you may see still this issue happen once for that old bundle.

'Fixed' as the new bundle UI makes this irrelevant

Having no animation is consistent with other inventory actions, e.g. repairing an item on the anvil

This is intentional, but it is the only exception to the rule. For any other item, a bundle should only fit 1 stack's worth.

After investigating, I see this as two separate issues. I have only fixed one of them.

I will update this issue to only describe the issue that was fixed. A moderator may want to reopen one of the duplicates that represents the other issue and ask for a new triage.

The issue that is fixed: When a structure loads, water sources in the structure spread into waterloggable blocks

The issue that is not fixed: When a structure is placed in water, water sources outside the structure spread into waterloggable blocks. (For example, when a shipwreck generates under water, its trapdoors become waterlogged.)

There was an example of the second case in the description. I removed it but it's here if you want to copy it to a new issue:

Example of it happening with vanilla structure generation:

seed: mansiontest

coords -18490 69 -3374

I have fixed this but the fix does not include Evoker Fangs or Experience Orbs, which have a different cause and do not cause log spam. Please raise a separate issue for them.

Wow, this is quite exciting! Until the server crashes.

This is actually Working As Intended. Here's why:

In 1.16 lightning_bolt entities can be selected using commands.

Your command spawns lightning when any entity (including lightning) stands on a bone block.

So when you step onto a bone block, one lightning bolt is spawned.
Next tick, there are two entities on the bone block (one player and one lightning bolt) so two more lightning bolts are spawned.
Next tick, there are 4 entities on the bone block, so 4 more are spawned... you get the idea!

Fix by making the command ignore lightning:

/execute at @e[type=!lightning_bolt] if block ~ ~-1 ~ minecraft:bone_block run summon minecraft:lightning_bolt

I think these wolves are affected by a bug which makes them stay wet forever and never shake the water off. This combines with MC-105248 (wet wolves are too dark) to cause this bug.

I have marked this issue as fixed because:

• If an entity is in a portal at the end of a tick, it will be teleported in the next tick.

• The entity only has to be touching the portal for 1 tick.

I believe this issue was originally about a problem where an entity had to be touching a portal for more than one tick to be teleported. That bug is fixed.

There are still some issues that could be raised separately, with more specific repro steps:

1. If an entity is in a portal in a non-entity processing chunk, it will not teleport.

2. If an entity is moving fast, it can pass right through a portal without ever touching it and will not teleport (MC-196556)

3. Entities teleport though portals at the start of a tick (before they move) instead of at the end of a tick (after they move)