Switching items at the same time as attacking carries over the attributes and enchantments of the previously held item

Is this still an issue in the most recent versions (currently that is 1.10.2, or 16w42a) of Minecraft? If so, please update the affected versions and help us keeping this ticket updated from time to time.

Can confirm for 17w17b

Going to change the command to give a diamond sword with fire aspect to make it more noticable and replace the chicken with a cow

That was a completely unnecessary change. The bug has been confirmed many times and it's very clear what's going on. You're just changing details to other similar details.

Confirmed in 1.15.2 and 20w20b.

Updated command:

/give @s diamond_sword{AttributeModifiers:[{AttributeName:"generic.attack_damage",Amount:1000.0,UUID:[I;1,2,3,4]},{AttributeName:"generic.attack_speed",Name:"generic.attack_speed",Amount:1000.0,UUID:[I;5,6,7,8]}],Enchantments:[{id:fire_aspect,lvl:1}]}

Can confirm in 20w51a.

Can confirm in 21w05b.

Can confirm in 21w06a.

Can confirm in 1.16.5 and 21w08b.

Can confirm in 21w17a.

Can confirm in 24w44a

In addition, the melee attack charging does not reset in time

I tested and checked out the src, finally found out the solution.

The attributes of living entites only refresh when entities' mob effects change or by tick.

So we can refresh players' attributes when they change their selected item.

Please fix swapping with a mace with breach is completely unbalanced

Breach swapping it's the worst thing that can ever happened, barely needs skill and you can almost one shot a player

Please add that this also makes it possible to do smash attacks with the base damage of other weapons, for example a netherite axe.

Can confirm in 25w41a

Perhaps it is necessary to add the spear to the bug description as well. When switching from a sword to a spear, it can deal sword damage at a greater distance. This will be more broken than the previous mace because the cost of the spear is very low.

Besides, the title description seems not quite accurate. The enchantment used during the attack is indeed that of the current item. The main mistake lies in the fact that attributes and attack charges were not updated in a timely manner.

A kind request from PvPers to finally fix this, as with the spear it’s now possible to use Breach IV on a 4.5 block reach weapon.

Can now be used to completely circumvent Lunge’s durability penalty, and to get sword attack speed on lunges.

Can confirm in MC-28289

Oh what am I saying… I mean
Can confirm in 25w42a

Can confirm in 25w44a

The attack speed of other weapons can be used with this bug to bypass the forced attack cooldown of spears:

Uploaded the wrong video in the previous comment.

Can confirm in 25w45a

And why did the priority of this ticket turn back to Important ☠️

Can confirm in 25w46a

Still not fixed

Can confirm in 1.21.11 Pre-release 1

Can confirm in 1.21.11 Pre-release 2

To fix MC-28289 and MC-272517, OJANG just need to add AN EXTRA REFRESH OF PLAYER’S ATTRIBUTES at the same tick if the player switch items.

Can confirm in 1.21.11 Pre-release 3

To fix MC-28289 and MC-272517,

MOJANG may just needs to ADD AN EXTRA REFRESH OF PLAYER’S ATTRIBUTES AND ATTACK COOLDOWN at the same tick if the player switch items.

Can confirm in 1.21.11 Pre-release 4

Likely relates to MC-304733.

Still in rc1 despite effects on spears

Can confirm in 1.21.11 rc-1.

Because of this bug, player can use spear to increase the attack range and decrease the cool down after a lunging from spear.

After 1.21.9, player can bind a slot and attack to the same button, so they can ALWAYS TRIGGER this bug. Not only for breach swapping of mace but also increasing attack range from spear that recently added.

This bug may also leads to a strange attack. This attack can be named as the double swapping. This attack contains the attribute and cool down of the first weapon, then add the additional attack range of spear, and finally the enchantment of the third weapon.

Firstly wait the attack cool down completely, then stand 3-4.5 blocks away from the mob. Now player can only reach it through spear rather than sword.

tick 1: Switch to the spear (slot 8).

tick 2: Switch to slot 9 and attack at the same tick. In the first video slot 9 is a diamond sword with sharpness 4. In the second video slot 9 is hand.

In the first video, mob got a crit and lost 11.5 health. (Iron sword crit + Spear attack distance + sharpness 4 = 6*1.5 + 2.5 = 11.5). And only the diamond sword lost 1 durability.

In the second video, mob got a crit and lost 9.0 health. (Iron sword crit + Spear attack distance + Hand without enchantment = 6*1.5 + 0 = 9). And no weapon lost durability.

What is expected: Switching to spear and the third weapon leads the refresh of player’s attributes including the attack cool down, so the attack should be calculated as the 0% charged attack with the item in slot 9, and it will fail because player only has 3 blocks reach distance at this time.

I don’t understand why they’re dragging out the fix for this bug. The longer it stays in the game, the more people get used to it, and then, after it’s fixed, there will naturally be even more complaints. The bug with having a spear in one hand and a mace in the other was fixed almost immediately, but for some reason this one was skipped in the next version. I’m honestly afraid to play modes with spears on servers — it’s complete chaos there! It feels like a completely different game!

Because of this bug, the refreshing of attributes always gets delayed, and the indicator also can’t recognize some different items. By the way, it can be confirmed in 1.21.11 rc-2, 1.21.11 rc-3, 26.1-snapshot 1, 26.1-snapshot 2.

0:00-0:13 Switching between two different items (same name but one has enchantment and the other don’t), the indicator will still keep recharging, and finally player can make a full charged attack. So why the indicator do not reset?

0:14-0:19 Switching between two items, for the next 2 ticks the indicator recharges at the speed of the first item rather than that player holds. This leads to the “shake“ of the indicator. So why it behaves that strange?

I believe some staffs have tried to fix it several months ago but maybe they encountered some difficulties. So this part of aged code is actually in a mess.

Instead of the server sending the new attack speed to the player when it detects they swtched slots, I think the item should instead hold that information so that the client instantly syncs with the new attack speed instead of it shaking. Especially with high ping. And yes, the attribute swapping is compleyely broken. With maxed gear you can die in 2 hits. It doesn’t feel right and it shouldn't be a thing in my opinion.

Attribute swapping(MC-28289 and MC-272517) bugs are still in 26.1-rc-1.

What’s wrong with them for dragging out the fix of this bug? While 26.1 rc-1 didn’t fix any bugs, is it really no bug needs to fix? Why can’t some of the developers just look over these that have been confirmed 10 years ago?

Still bug in full release

Why would they try to fix it when:
- The PVP community has this a a feauture and they will go to mojang so it gets reverted

I don’t think this is a good idea to fix, it is a bug that has been in the game for a long(?) time and people have trained to be good at using this, fixing this would be probably not be very good for the PvP community

Still in 26.2 snapshot 1. Maybe it’s not a good idea to refresh the attribute and cooldown instantly. Instead, maybe a combat test feature is better: Swapping items refreshes the right attributes, but doesn’t reset attack cooldown (means real time but not percentage). So players won't feel that their swapping attack is too weak.

Swapping can combine attribute of item 1 and components of item 2 is absolutely broken. Datapacks or mods get the wrong result when detecting the used item. Also, marco can 100% successful and it’s not easy to detect on server because it’s same to “high-skill playing“ manually.

Even the third party server software, Paper, has made the fix plan for this bug by resting attack cooldown and refreshing attribute. However it’s not complete. The video shows that double swapping still has the spear reach and attribute (Some texture pack won’t affect the result). I guess it’s because the communication problems between server and client.

This bug is bad for PvP though, as it negates a ton of avenues for skill and narrows it down to one. For example, you don’t have to learn the attack speed and combos routes for maces to take advantage of Breach, because you can just transfer Breach onto a sword instead, invalidating the point of learning mace attack speed. Similarly, you can completely bypass the forced cooldown of spears, negating the point of using the faster wooden spear for Lunge use.

It’s also extremely overcentralizing for melee and mace use, as it causes melee attacks and smash attacks to have far more damage output than was ever intended due to being able to transfer Breach and smash attacks respectively onto weapons with far higher base damage. Fixing this bug opens avenues for skill expression by learning individual weapons, and removed unintended overbearing ones like Breach swapping in grounded melee and attack damage swapping in mace PvP. All that is lost by patching this is the skill avenue of the swap itself, but so many other actually intended skill avenues are opened with its removal (grounded Breach mace, wooden spear Lunge, grounded spear, etc).

Even the devs of the most popular 1.9+ pvp server (PvP Legacy) such as BlueBandit agree that this needs to be fixed, and any backlash towards it would be from people that don’t understand how its removal is a huge improvement, and only see “removing something that players found is bad”.

I agree with SeaOfPixels. This bug also affects item-detection in datapacks. The community knows that this is a bug and Paper (many pvp servers use this core) has the fix plan. It’s not strange that a small amount of bug-abusing people have different opinions, but why they say “don’t fix this“ instead of making breach available on sword using their datapack or making their own third-party server???

However, Mojang doesn’t fix it in newest version 26.2-snapshot-6. To fully stop the divergence, they needs the real actions instead of confirming that it’s a bug and then focus on the young mobs update.

Still in 26.2-snapshot-8.

I feel strange about the tick order. Let A=Components update from item 1 to 2, B=Caculate attack data, C=Attributes and attack-cooldown update from item 1 to 2. Hold item 1, then attack and swap to items 2 in the same tick, the next tick:

Expect order: A-C-B or C-A-B

Game reform order: A-B-C, attributes and cooldown of item 1 + components of item 2

In net\minecraft\world\entity\player\Player.class, in public void tick{}:

This is the origin code. In public void tick{}, the order is 1)this.attackStrengthTicker++, 2)this.itemSwapTicker++, 3)this.cooldowns.tick{}.

In public void tick{}, I move this.itemSwapTicker++ to the first place, before this.attackStrengthTicker++ and this.cooldowns.tick{}. Try to refreash all the data of item 2, including attributes, attack-cooldown and components, then caculate the attack.

I hope this change can fix this bug but I’m not sure about that. If it can’t, maybe there are some problems between server and client pack event.

This appears to be fixed on the latest pre-release (26.2-pre-2). I must warn whoever finally patched this, there will be backlash as this has been an established “mechanic” within the pvp community since the mace was released. I think this was a much needed change and it will only benefit the game long-term so please persevere.

@Primitive Enderdragon the client waits a tick to update the server on what item is held when swapping with a hotkey, scroll wheel was not affected iirc. The code you are looking at is server code, while yes that would be a partial solution it does not fully fix the issue because of reach components and other edge cases. If you attack with a spear and swap to another item, the 4.5 reach is still applied to the attack.

I think reach isn’t tied to weapons and is instead sent by the server every time. So if you have 200ms ping to a server, when you switch off the spear you will have the extra reach for another 0.2 seconds. I don’t have any coding knowledge and get this information just from gameplay which could be very wrong. If I’m right though, to fix it they would have to make reach tied to items (maybe in the nbt data) so that it’s handled by the client and instantly updates. They could maybe do the same for attack cooldown so it doesn’t jitter, especially on higher ping.

Reply to Notisln: You can still swap onto another item but it just acts like you didn’t swap. So for example you can switch off of spear and attack with sword, which would previously combine the two, but now it just acts like a normal spear attack. This isn’t really an issue, it’s basically just some coyote time on item switches.

Why was this re-opened? The described bug is fixed.

It is not necessarily fixed because by delaying your attack exactly 1 tick after swapping, the same behaviour carries out (except for spears which is the only thing fixed)

On top of that, placing blocks and using items while swapping is broken right now, see MC-308523

I tested this right now in 26.2-pre-2 and found this bug changed but not fixed.

Experiment1: Test attack damage for a zombie(armor=30, health=20, toughness=0),

I use “/attribute … base set 30“ to set 30 armor points and “/data get … Health” to detect the amount of damage.

Item A: a netherite axe(total-attack-damage=13, sharpness=5),

Item B: mace(total-attack-damage=6, breach=4),

Item C: a normal netherite axe(total-attack-damage=10, sharpness=0)

With fully charged, I performed 3 types of attack, the damage are:

Item A solely: 2.6, Item B solely: 4.8, Item C solely: 2.

Hold Item A, then attack and switch to Item B at the same tick: 2.6,

Hold Item C, then attack and switch to Item B at the same tick: 2,

Hold Item B, then attack and switch to Item A or C at the same tick: 4.8,

If I delay the attack after item switch for 1 tick, I can reproduce attribute swapping. I used macros and multiple-binding(added in 1.21.9) respectively to ensure the accuracy.

Hold Item A or C, switch to item B, attack at the next tick: 8, (The Reproduce, although the cooldown-bar showed empty, it’s still a full charge attack)

Hold Item B, switch to item A, attack at the next tick: 1.8,

Hold Item B, switch to item C, attack at the next tick: 1.2

Other experiment:

I temporality can’t reproduce spear-double-swapping I reported at 2025/12/31, for both multiple-binding and macros.

In video Minecraft 2026.04.06, I showed that swapping to another item, cooldown-bar increase at the speed of the previous item for 2 ticks. I use “/tick rate 1“ to test this in 26.2-pre-2, and that increase to 3 ticks now.

Or other plan, use the plan of this mod “attribute-swapping-fix” to force item update, same to paper. I read the mixin-code of the mod. Although it can’t fix spear-double-swapping, but it’s 0-charged and this attack can be cancelled by anti-cheat.

Maybe like MC-3304, this bug relates to some messy code, and the staff right now don’t know how it was written previously. However, respect to the staff who are conquering these problems.

From what I can tell, this doesn’t really seem like a proper fix but just delays interacting with newly held items by a tick (as @Longieee and @Primitive Enderdragon already mentioned). I believe the expected behaviour is that the Item in the slot the player is hovering the instance the client tick occurs is treated as the Item the player is holding. The previous client behaviour made perfect sense in that it always correctly sent the correct SetCarriedItem packet right before the corresponding Interaction and Swing packets, and I think the newly introduced client behaviour is very suboptimal. The problem lies entirely within how the Server handles these incoming packets. When the server receives a SetCarriedItem packet it essentially runs Inventory.setSelectedSlot(…), but doesn’t update the corresponding attributes until the next server tick. I think it would probably be more logical to call player.collectEquipmentChanges(…) or similar from within the SetCarriedItem packet listener to instantly apply the attributes on the server.