danegraphics

I am able to launch 1.5 and even beta versions on my M1. I don’t know about anyone else though.

However, everything before 1.6 has the R and B color channels swapped, so colors look inverted. But I think there is a different bug about the color swap issue, which still needs addressed.

I strongly disagree with the "Works As Intended" resolution of this ticket because bundles fundamentally work as inventory.

With bundles, it is entirely possible to put an item in your inventory (in the bundle), craft using said item, and still not unlock the recipes or advancements associated with that item.

This is not the case with shulkers where there is no way to use or craft with the item without putting it in your inventory first, so this was never an issue with shulkers.

@MrMuskle - I strongly disagree with the "Works As Intended" resolution of that ticket because bundles fundamentally work as inventory.

With bundles, it is entirely possible to put an item in your inventory (in the bundle), craft using said item, and still not unlock the recipes or advancements associated with that item.

This is not the case with shulkers where there is no way to use or craft with the item without putting it in your inventory first, so this was never an issue with shulkers.

Can confirm in 1.21.2

@Jeremy - If that is the case, then it might be a good idea to open a new ticket and post the details of how you get that to happen in vanilla, along with video of it happening, if possible.

I don't know how else we can alert them to closed tickets that need re-opened.

Confirmed 24w09a

However, with "minecraft:unbreakable" being changed to a component, and no longer being a boolean, we could potentially add properties to it that would allow it to combine with other items.

Things like "minecraft:unbreakable={anvil_requires_matching_damage:false}" would allow us to specify under what circumstances unbreakable items can be combined in anvils and more.

If "anvil_requires_matching_damage" is unspecified, it can disable combining completely. Setting it to true would require the damage values to be the same. Setting it to false would allow you combine items of the same type regardless of damage values.

There could even be a field to specify how it combines in anvils, either keeping the damage value of the first item, or adding the damage values together to get a new value, or something else.

I believe something like this could solve most if not all of the issues with this bug.

—

Side note: It is possible with components to now remove the "minecraft:damage" component from an item completely (though only in loot tables, through item modifiers, etc. It's not possible to do with /give or other such commands yet due to the limitations with the new syntax), and this makes the item equally unbreakable.

However, items with the damage component removed cannot be combined in anvils either (understandably), leading to the same problem as before.

But this isn't an issue if "minecraft:unbreakable" is able to be modified to allow the combining of items under specified circumstances.

I think the problem with trying to fix this is that damage values pull double duty. Not only do they measure the damage of the item, they also serve as the means of letting map makers create new items. This means that "Unbreakable: 1b" is pulling double duty as well, which is a problem when one may not want both fulfilled.

So an unbreakable item's damage value must be assumed to be perfectly stable, regardless of what a player attempts to do with it.

But on the other hand, if someone wants to make certain items (say all swords) unbreakable through a datapack, and wants the players to be able to do everything else normally, such as combining enchantments with other items regardless of the other item's damage, they should be able to do so and have the resulting item remain unbreakable.

So somehow, custom items remaining stable, and combining items with enchantments in anvils, need to be segregated.

Perhaps this could be a solution:

• allow "Unbreakable: 1" items to be combined if they have the same damage value, but don't change the damage value of the resulting item, and...

• give the "Unbreakable" nbt tag a possible value of 2 (an int instead of a bool), which still be unbreakable, but would allow the item to be combined with any item of its type regardless of damage values, and the resulting item still have "Unbreakable: 2".

This would allow map makers to continue to use their items as is without needing to worry about changing too much (1b would just be taken as an int of 1), and would allow future map makers and especially datapack makers to allow the combining of enchanted items in anvils without worrying about damage values.

Can confirm for 1.20.4.

Can confirm that this also applies to Elytra, which will make shuffling sounds when modified.

@Zgajak - Thank you. This allows older versions to start now, but they are still visually buggy. Specifically, the inverted colors issue has not been resolved by this.

Again, probably a result of the java version used to run the pre-1.6 versions of the game.

Note that the workaround described in WEB-6665 is incredibly janky.

It required me to reset my password even though I was using my correct microsoft password that works everywhere else.

The fact that it was not accepting my correct password may give a hint as to what the actual issue was.

Can confirm in 1.20.1.

When I saw it happen I laughed so hard.

This bug is happening again.

Just happened in MacOS 13.5.

@ampolive - You were right. They work perfectly fine in vanilla. Though I suspect it's because simulation distance can't be set below the max render distance of the dolphins (which is 5 chunks, far below all other mobs for some reason?).

It may occur on modded servers because the simulation distance can be set below the max render distance of dolphins. So those values may actually be tied together.

I imagine that's the reason dolphins don't render beyond 5 chunks regardless of settings?

Can confirm in 1.18.2.

Attached image of command locating a different biome than the one I was right above.

A note just in case the issue marked as a duplicate of this ticket is ignored:

Once this issue is fixed, please make sure that it also resolves MC-200226 so that formatting also successfully applies to Titles and Authors in books, not just the text of the book.

If it does not, then please reopen MC-200226.

I'm pretty sure this is a different problem from MC-133841. Not a duplicate.

That issue is about not being able to paste the character into the text of the book (as far as I understand). This one is about the Title and Author fields specifically ignoring the character and not formatting anything.

It's possible these have the same cause, but they are separate side-effects of the issue and both need to be tracked, not just one. Otherwise you may fix that issue but not this one.

Yay! You're the best, Mobius!

Oh, I thought the lag in this ticket was described as lag in general. In that case, can we get someone assigned to MC-98994? Because my server is unplayable until that's fixed. Thanks.

Can this please get assigned soon? It is still a massive problem.