Enchantments put on items become ordered alphabetically regardless of order they were really enchanted

[aswqedfr456]

What behaviour is expected:

When you put enchantments on armor the enchantments are ordered according to the order you put them on. If I put protection 4, unbreaking 3, and mending on a chestplate the enchantments will be protection 4, unbreaking 3, and mending because that is the order I put them on.

What behaviour is observed:

What actually happened is that when I put protection 4, unbreaking 3, and mending on a chestplate, it always put mending at the highest order because M is above P and U in the alphabet. This also changed existing items in the server. For example, a helmet that had protection 4, unbreaking 3, aqua affinity, and mending was changed to have aqua affinity, mending, protection 4, and unbreakking 3 in that order.

Steps/models to reproduce:

Start a paper server using the latest build. Enchant a chestplate. The enchantments are always ordered alphabetically. Or you can start on a vanilla server enchant items, switch to paper, and check the armor.

Plugin list:

No plugins

Paper build number:

version git-Paper-162

[VADemon]

https://hub.spigotmc.org/jira/browse/SPIGOT-5063 https://hub.spigotmc.org/jira/browse/SPIGOT-5656

This is a whole range of issues with NBT serializing differently but having i.e. equal contents. If alphabetical is consistent, imho better leave it that way to prevent stacking issues.

[aswqedfr456]

I don't think that this is for the better. I first noticed this on my server when I attempted to put respiration on my helmet when I noticed that it costed 20 experience points because the enchantments were ordered alphabetically rather than how I had put them before which was by number order. From a gameplay standpoint this makes enchanting way more difficult then it was ever intended in the vanilla game.

[BillyGalbreath]

I first noticed this on my server when I attempted to put respiration on my helmet when I noticed that it costed 20 experience points because the enchantments were ordered alphabetically rather than how I had put them before which was by number order

Should have led with that ;)

Can I get some details on this? I was not aware order changed repair cost.

Maybe provide comparison numbers of paper vs vanilla, so we can see the actual difference

[aikar]

This is the correct way to do things has been this way for years and this is first report on it The client has always alphabetically ordered the enchants on display. this server change matches client ordering and fixes comparing if 2 items are the same. edit: seems client has changed in 1.15, see below.

[aikar]

I'll reopen until you respond to confirm comparison to vanilla server with no plugins.

If this is a behavior change from vanilla, then that means vanilla would have changed in 1.15 as this use to not matter, and i will be super confused on why mojang would make order of enchants application vary.

Why would applying 3 different enchanting book to same item have different cost just because they were done in a different order?

[aikar]

Wiz has provided information showing that enchants aren't sorted on client anymore, but that cost is unaffacted. but if that's all it is, then I'm not going to change anything.

Will need information reproduce steps on and how much each costed.

wizjany Today at 10:12 AM
if i enchant prot -> unb -> mend it's 4 4 5
if i enchant unb -> prot -> mend it's 3 5 5
on both vanilla and paper```

[aswqedfr456]

Is alphabetical sorting of enchantments an intentional feature? I was still wrong because the final costs are the same. I was confused because the individual costs can be more expensive sometimes on paper but the final costs are the same in vanilla and paper. I still think it is annoying that you have less control over the priority of the enchantments but if that doesn't matter then the issue should just be closed.

[wizjany]

Can you provide an example of individual costs differing? That's not consistent with what I found using the original example (unbreaking 3, protection 4, and mending).

[aswqedfr456]

If you go on paper and enchant a diamond pickaxe with unbreaking 3 then mending, it costs 3 xp for unbreaking then 3 xp for mending. If you do it the other way around it still costs 6 xp but the first cost for mending is 2 then unbreaking is 4 xp. In vanilla this matters because you have more control over where the enchantments go which usually matters from random zombie and skeleton drops when you combine the drops in an anvil but in paper two items with identical enchantments are ordered exactly the same when in vanilla this is sometimes not the case.

[BillyGalbreath]

If you go on paper and enchant a diamond pickaxe with unbreaking 3 then mending, it costs 3 xp for unbreaking then 3 xp for mending. If you do it the other way around it still costs 6 xp but the first cost for mending is 2 then unbreaking is 4 xp

Ok, so on Paper costs are:

Unbreaking 3 -> mending 3 -> total 6 Mending 2 -> unbreaking 4 -> total 6

What is that exact same behavior on vanilla? You haven't said that yet.

[LB45440078L]

If you go on paper and enchant a diamond pickaxe with unbreaking 3 then mending, it costs 3 xp for unbreaking then 3 xp for mending. If you do it the other way around it still costs 6 xp but the first cost for mending is 2 then unbreaking is 4 xp

Ok, so on Paper costs are:

Unbreaking 3 -> mending 3 -> total 6 Mending 2 -> unbreaking 4 -> total 6

What is that exact same behavior on vanilla? You haven't said that yet.

because it's the same 🤷‍♂

[aikar]

When you are adding a new enchantment to the item, it sums up the weight of the existing enchantments to factor in next cost...

order doesn't matter when calculating that summed weight.

4+4 = 3+5 for determining cost of 3rd enchant

Let's take the previous example:

if i enchant prot -> unb -> mend it's 4 4 5
if i enchant unb -> prot -> mend it's 3 5 5

first enchant prot, sum weight is 0, cost is 4 => Spent: 4 - in both vanilla in paper next enchant unbr, sum weight is 4, next cost 4 => Spent: 8 - in both vanilla and paper last enchant mending, sum weight 8, next cost 5 => Spent: 13 - in both vanilla and paper

next scenario first enchant unb, sum weight is 0, cost is 3 => Spent: 3 -> in both vanilla and paper next enchant prot, sum weight is 3, next cost 5 => Spent: 8 - in both vanilla and paper last enchant mending, sum weight 8, next cost 5 => Spent: 13 - in both vanila and paper

in both scenarios, both has cost 8 on 2nd enchantment. the only difference in the scenarios is the first cost, but these cost match vanilla.

The difference in first cost also occurs in vanilla..

this would only cause issues if a plugin explicitly did .getEnchantments().get(0) == specific enchantment instead of .hasEnchantment(), and that's just a silly scenario.

[aswqedfr456]

Is this an intentional feature of paper? I think that this is still an issue because it is not behaving the way the game is originally intended and there is no option to change this.

[aikar]

It is a bug fix, we don't provide config options for bug fixes. It is just a display difference... Not even going to call it an issue. You shouldn't worry over that.

Based on the linked bug reports, seems like we might even have more work to do in this area.

[aswqedfr456]

Ok. Thank you.

[awawe]

This is not at all how enchantments work, or have ever worked, in vanilla. And yes, order does affect the cost of combining enchantments in an anvil. Gnembon has made an excellent video explaining how vanilla enchantment combining works.

[Easyidle123]

Order of combination does matter, but if the enchantments are rearranged, it won't affect the cost. I believe this issue should be reopened though, as cosmetics are still important to many players.