Thelarrikin

I literally searched for suffocate prior to posting and got no similar results only to see a flood of "resolved-duplicate" results following publishing this post... Frustrating.

To add additional context, at one point it was mentioned that some blocks with such block states would be broken out into their own identifiers (or aliases), but even so this still would have to be fixed due to the way some items, such as water bottles (being the default state 0 for a minecraft:potion item) when queried, would return true for any potion - there's no way to determine that the player is specifically holding a water bottle and not a mundane potion, for example.

This was recently marked as resolved, awaiting response, but I don't think because the entire transform_item event is not functioning at all in current versions that this can be marked "resolved". Related issue MCPE-159116 needs resolved first prior to determining if that solution resolves this issue as well, and it hasn't been.

In one of the more recent official behavior packs (after recipe unlocking was introduced), previously missing torch recipes are now available, albeit with an odd identifier: "minecraft:Torch_recipeId" and "minecraft:Torch_charcoal_recipeId", to a point where removing the crafting table tags does indeed remove it from being craftable (i.e. works as expected).

With that in mind and renewed hope, I revisited the trapdoor recipes with other names, such as trapdoor_recipeId, Trapdoor_recipeId, [woodtype]_Trapdoor_recipeId, etc, but to no avail.

That being said, this still affects 1.20.15

Still affects 1.20.10

Additional context: it is not handled as a versioned change and breaks prior version blocks, as well.

From what I can tell, any block declaring any version that utilizes Molang in at least Components and/or Permutations, (possibly Events, too? I haven't had a chance to check), will not evaluate.

• Under bone_visibility (possibly other components?), the block doesn't load and logs error(s).

• Under, for ex. a material_instances permutation with Molang utilized to define a condition, the condition doesn't evaluate.

There isn't an addon because the content is MISSING from the official documentation. It can easily be verified by simply looking in the official creator content behavior and resource packs that contain the actual Minecraft files, as there are no recipes given to allow one to 𝘰𝘷𝘦𝘳𝘸𝘳𝘪𝘵𝘦 trapdoors other than the new wood types (warped, crimson, mangrove, bamboo, with iron available, too), and a few other "og" staples (like torches) as well.

There are many instances of this generation. Here is one I have open: -1835164682780775258, coordinates: -201, 64, 252.

I don't believe the other ticket covers this happening naturally (during world generation), with this particular block, or the performance impact it causes.

That is why I wanted to document it as an independent issue, as the other issue has been around for some time, but this particular world gen issue has only existed as of 1.19.31.

I have to disagree with the "invalid" diagnosis, this is definitely a bug. It didn't occur until the 1.19.31 update. (Curiously, it also occurred on the same update last cycle, 1.18.31)

And it's not simply "laggy" - food takes twice as long to eat, mobs take a step every "tick", stop pathfinding and stand still (animation and everything), only to take another step a second later.

This can be easily documented on the Switch, where my kids primarily play, and occurs with newly created worlds as well as worlds created prior to 1.18.31.

I have noticed it is slower when there is more water around, and that grass blocks are spreading under sea grass, so I might attribute it to that, but all we can do is speculate. Could be that, could be anything, could be some weird way the system reacts to 1.*.31 updates, for all we know. 

I am now getting the same issue after updating to 1.19.30 and .31, connection fails from PC, Switch, and from same-PC with loopback exemption in place.

Please reopen this ticket. Issue is still present in most recent 1.19.40 beta.

Just checked the most recent Beta behaviour pack available (1.19.40.22) and the old wood type trapdoor recipes, torch recipes, and a few others are unavailable. This means the recipe ID is unavailable to be overwritten or disabled.

attached a .mcworld file with a BP and RP included to show the blocks (both using custom geometry) and how walls and fences attach despite the modified hitbox.

I had a similar issue, I believe due to the quantity of blocks I had, each with a scheduled tick, that overwhelmed the game. Mobs would freeze (but you could hit them once), and broken blocks would "fall" within their immediate block-space and float but were not able to be collected.

After removing that portion of my addon, I've yet to find a frozen chunk. Guess I'll just have to figure out another way to go about it.

For other issues, trailing spaces outside of the main json object started throwing errors recently, or having multiple main json objects in files that were expecting one. Not sure if that was in 1.18.30 or prior.

(I used to keep "backup" block code as a second main object after the first with no errors until one of the updates.)

There are a handful of now-missing components that I've listed here: 

1. MCPE-154122

The second slot of the Smithing Table recipe will take any item in the format namespace.netherite_ingot. While I will not give a 100% pass to this solution, it does allow recipes to be made with custom items using your namespace so long as the item is properly named.

It's not 'fixed', but does allow for a workaround.

Trapdoor recipe, along with a handful of other "original" recipes (torches, etc) are still not available in the official Vanilla Behavior Pack download.

Fixed in 1.18.10, y'all