MC-349Villagers ignore data tags in trading
Re-opening applies specifically to data tags such as having a custom name
Villagers will only check an item's ID, not its damage value or any other data, in determining whether they will accept it. This leads to interesting situations where a priest will fully restore an item's durability when enchanting it, and a modified villager requesting bonemeal will just as easily accept ink sacs.
This bug also prevents map makers from designating custom items for villager trade (e.g. a piece of glowstone with a custom name and enchantment will be treated the same as an ordinary piece of glowstone).
What I expected to happen was...:
The villager would only accept the item if it was the same as the item they request - not if it merely shared the same data value.
What actually happened was...:
Priests would accept damaged tools and fully restore them when enchanting them. Modified wool-buyers were colorblind. Names and enchantments on items were ignored.
Steps to Reproduce:
1. Find a priest with an offer to enchant an item. Enchantment offers are rarer than other offers, so this can take some time/spawning.
2. Attempt to enchant a badly damaged tool using this priest.
3. Observe that the item has been enchanted, and has also been restored to its maximum durability.
3b. If you attempt to enchant a previously enchanted item with this priest, you will observe that the old enchantment is ignored and the new one is placed. However, normally it is not possible to unenchant an item, and even anvils will charge extra for overwritten enchantments, so this behavior is not consistent.
Caveat to fixing:
Although making trades strict would fix the issues outlined above, it would cause other issues. Farmers would then only accept white wool, and it would be impossible to fulfill a librarian's request for a Written Book.
Instead, it may be preferable (if anything is done about this issue at all) to add a new tag to an offer, determining whether it is to be considered strict. Thus, among vanilla Minecraft offers, the priest's enchantment offers would be marked 'strict', requiring unenchanted items at full durability. As this would be an NBT tag, map-makers would also be able to make use of it to prevent the aforementioned issues in custom traders.
- Fixed
WolfieMario![[Mojang] Searge (Michael Stoyke)](../../../data/assets/gravatar/searge.png)
[Mojang] Searge (Michael Stoyke)- 36
- 17
- Confirmed
1.4.2 - 1.8
1.4.2 1.4.6 1.4.7 13w01a 13w01b 13w02a 13w03a 13w04a 13w06a 13w09a 13w09b 13w10b 1.5 1.5.2 13w19a 13w21a 13w23b 13w24a 13w24b 13w25a 13w25b 13w25c 1.6 1.6.1 1.6.2 1.6.4 13w37a 13w37b 13w38c 13w39b 13w41a 13w41b 13w42a 13w42b 1.7 1.7.1 1.7.2 1.7.3 1.7.4 14w02b 14w02c 14w04b 14w05b 14w06a 14w06b 14w07a 14w08a 1.7.5 14w11b 1.7.6-pre1 1.7.6-pre2 1.7.10 14w27b 14w28a 14w28b 14w29a 14w29b 14w30a 14w30b 14w30c 14w31a 1.8-pre3 1.8- 14w02a 1.8.1-pre4
Created Issue:
Villagers ignore damage values and item tags in trading
Villagers will only check an item's ID, not its damage value or any other data, in determining whether they will accept it. This leads to interesting situations where a priest will fully restore an item's durability when enchanting it and a modified villager requesting bonemeal will just as easily accept ink sacs.
This bug also prevents map makers from designating custom items for villager trade (e.g. a piece of glowstone with a custom name and enchantment will be treated the same as an ordinary piece of glowstone).
What I expected to happen was...:
The villager would only accept the item if it was the same as the item they request - not if it merely shared the same data value.What actually happened was...:
Priests would accept damaged tools and fully restore them when enchanting them. Modified wool-buyers were colorblind. Names and enchantments on items were ignored.Steps to Reproduce:
1. Find a priest with an offer to enchant an item. Enchantment offers are rarer than other offers, so this can take some time/spawning.
2. Attempt to enchant a badly damaged tool using this priest.
3. Observe that the item has been enchanted.3b. If you attempt to enchant a previously enchanted item with this priest, you will observe that the old enchantment is ignored and the new one is placed. However, normally it is not possible to unenchant an item, and even anvils will charge extra for overwritten enchantments, so this behavior is not consistent.
Caveat to fixing:
Although making trades strict would fix the issues outlined above, it would cause other issues. Farmers would then only accept white wool, and it would be impossible to fulfill a librarian's request for a Written Book.Instead, it may be preferable (if anything is done about this issue at all) to add a new tag to an offer, determining whether it is to be considered strict. Thus, among vanilla Minecraft offers, the priest's enchantment offers would be marked 'strict', requiring unenchanted items at full durability. As this would be an NBT tag, map-makers would also be able to make use of it to prevent the aforementioned issues in custom traders.
Villagers will only check an item's ID, not its damage value or any other data, in determining whether they will accept it. This leads to interesting situations where a priest will fully restore an item's durability when enchanting it, and a modified villager requesting bonemeal will just as easily accept ink sacs.
This bug also prevents map makers from designating custom items for villager trade (e.g. a piece of glowstone with a custom name and enchantment will be treated the same as an ordinary piece of glowstone).
What I expected to happen was...:
The villager would only accept the item if it was the same as the item they request - not if it merely shared the same data value.What actually happened was...:
Priests would accept damaged tools and fully restore them when enchanting them. Modified wool-buyers were colorblind. Names and enchantments on items were ignored.Steps to Reproduce:
1. Find a priest with an offer to enchant an item. Enchantment offers are rarer than other offers, so this can take some time/spawning.
2. Attempt to enchant a badly damaged tool using this priest.
3. Observe that the item has been enchanted.3b. If you attempt to enchant a previously enchanted item with this priest, you will observe that the old enchantment is ignored and the new one is placed. However, normally it is not possible to unenchant an item, and even anvils will charge extra for overwritten enchantments, so this behavior is not consistent.
Caveat to fixing:
Although making trades strict would fix the issues outlined above, it would cause other issues. Farmers would then only accept white wool, and it would be impossible to fulfill a librarian's request for a Written Book.Instead, it may be preferable (if anything is done about this issue at all) to add a new tag to an offer, determining whether it is to be considered strict. Thus, among vanilla Minecraft offers, the priest's enchantment offers would be marked 'strict', requiring unenchanted items at full durability. As this would be an NBT tag, map-makers would also be able to make use of it to prevent the aforementioned issues in custom traders.
Villagers will only check an item's ID, not its damage value or any other data, in determining whether they will accept it. This leads to interesting situations where a priest will fully restore an item's durability when enchanting it, and a modified villager requesting bonemeal will just as easily accept ink sacs.
This bug also prevents map makers from designating custom items for villager trade (e.g. a piece of glowstone with a custom name and enchantment will be treated the same as an ordinary piece of glowstone).
What I expected to happen was...:
The villager would only accept the item if it was the same as the item they request - not if it merely shared the same data value.What actually happened was...:
Priests would accept damaged tools and fully restore them when enchanting them. Modified wool-buyers were colorblind. Names and enchantments on items were ignored.Steps to Reproduce:
1. Find a priest with an offer to enchant an item. Enchantment offers are rarer than other offers, so this can take some time/spawning.
2. Attempt to enchant a badly damaged tool using this priest.
3. Observe that the item has been enchanted, and has also been restored to its maximum durability.3b. If you attempt to enchant a previously enchanted item with this priest, you will observe that the old enchantment is ignored and the new one is placed. However, normally it is not possible to unenchant an item, and even anvils will charge extra for overwritten enchantments, so this behavior is not consistent.
Caveat to fixing:
Although making trades strict would fix the issues outlined above, it would cause other issues. Farmers would then only accept white wool, and it would be impossible to fulfill a librarian's request for a Written Book.Instead, it may be preferable (if anything is done about this issue at all) to add a new tag to an offer, determining whether it is to be considered strict. Thus, among vanilla Minecraft offers, the priest's enchantment offers would be marked 'strict', requiring unenchanted items at full durability. As this would be an NBT tag, map-makers would also be able to make use of it to prevent the aforementioned issues in custom traders.
is duplicated by
![[Mod] Ezekiel (ezfe)](../../../data/assets/gravatar/ezekielelin.jpeg){kind=small}
Villagers ignoredamage values anditem tags in trading
Villagers ignore itemtagsin tradingVillagers ignore item value in trading
Re-opening applies specifically to data tags such as having a custom nameVillagers will only check an item's ID, not its damage value or any other data, in determining whether they will accept it. This leads to interesting situations where a priest will fully restore an item's durability when enchanting it, and a modified villager requesting bonemeal will just as easily accept ink sacs.
This bug also prevents map makers from designating custom items for villager trade (e.g. a piece of glowstone with a custom name and enchantment will be treated the same as an ordinary piece of glowstone).
What I expected to happen was...:
The villager would only accept the item if it was the same as the item they request - not if it merely shared the same data value.What actually happened was...:
Priests would accept damaged tools and fully restore them when enchanting them. Modified wool-buyers were colorblind. Names and enchantments on items were ignored.Steps to Reproduce:
1. Find a priest with an offer to enchant an item. Enchantment offers are rarer than other offers, so this can take some time/spawning.
2. Attempt to enchant a badly damaged tool using this priest.
3. Observe that the item has been enchanted, and has also been restored to its maximum durability.3b. If you attempt to enchant a previously enchanted item with this priest, you will observe that the old enchantment is ignored and the new one is placed. However, normally it is not possible to unenchant an item, and even anvils will charge extra for overwritten enchantments, so this behavior is not consistent.
Caveat to fixing:
Although making trades strict would fix the issues outlined above, it would cause other issues. Farmers would then only accept white wool, and it would be impossible to fulfill a librarian's request for a Written Book.Instead, it may be preferable (if anything is done about this issue at all) to add a new tag to an offer, determining whether it is to be considered strict. Thus, among vanilla Minecraft offers, the priest's enchantment offers would be marked 'strict', requiring unenchanted items at full durability. As this would be an NBT tag, map-makers would also be able to make use of it to prevent the aforementioned issues in custom traders.
Villagers ignoreitem valuein tradingVillagers ignore data tags in trading
![[Mod] CubeTheThird](../../../data/assets/gravatar/cubethethird.jpeg){kind=small}
is duplicated by
is duplicated by
is duplicated by
A comment with security level 'global-moderators' was removed.
A comment with security level 'global-moderators' was removed.
Does anyone have the command(s) they are using?
[Mojang] Searge (Michael Stoyke)
Edit: Replaced my crummy explanation with a better one, courtesy of Torabi.
This is a complicated issue, caused by a collision of multiple trading mechanics. The code doesn't really distinguish between the enchantments placed on the books – other than to set the price based on the level of the enchantment. So an offer of a book with a particular enchantment can be replaced with a book with any other enchantment, because all it checks when generating an offer and determining whether to add a new one or replace an existing one is the item ID.
The first component is MC-349: all potential offers for Enchanted Books are considered the same item, regardless of the enchantment or its level.
When generating a new offer, if the item matches an existing offer, it only replaces it if the price is better. If it's not better, nothing changes.
Enchanted books are priced differently than other items, based on enchantment level: (2 + level * 3 + random(0, level * 10 + 5)).
The result of these three components is that low-level books can easily replace higher-level books, but high-level books can never be priced low enough to ever replace some low-level offers. For example, the minimum cost for a level 5 enchantment is 17 emeralds. Once a librarian generates an offer for an enchanted book priced lower than that, they will never again offer a level 5 enchanted book. (Ranges for all levels, from the wiki: level 1: 5 – 19, level 2: 8 – 32, level 3: 11 – 45, level 4: 14 – 58, level 5: 17 – 71). Because of the random nature of generating offers, it's guaranteed that the more you trade with a librarian, the worse their offers will get. This is the exact opposite of how trading works for every other type of trade, including the librarian's offers for other types of items, in which it's guaranteed that offers will never get worse, and, if you trade with a villager enough, you will eventually unlock all their potential trades, at the lowest possible prices.
The enchanting offers provided by priests work entirely differently than enchanted books. The cost only ranges from 2-4, and is not related to the enchantment or its level. Offers can be replaced with a different enchantment, and that enchantment may be better or worse, but the full range (all enchantments that would cost 5-19 exp levels if you used a enchanting table) is always available for the offer generator to pick from, and nothing about the existing enchantment offer will ever exclude part of that range.
It is almost certain that the behavior of enchanted book offers is an oversight, not an intentional deviation.
Duplicate of MC-349, please use the search function to see if your bug has already been submitted. Currently over 52% of tickets are being closed as duplicate.
![[Mod] Torabi](../../../data/assets/gravatar/torabi.png){kind=small}
They're not "ignoring" it. They're busy tackling the 2,613 other unresolved issues.
This is a complicated issue, caused by a collision of multiple trading mechanics. The code doesn't really distinguish between the enchantments placed on the books – other than to set the price based on the level of the enchantment. So an offer of a book with a particular enchantment can be replaced with a book with any other enchantment, because all it checks when generating an offer and determining whether to add a new one or replace an existing one is the item ID.
- The first component is
MC-349: all potential offers for Enchanted Books are considered the same item, regardless of the enchantment or its level. - When generating a new offer, if the item matches an existing offer, it only replaces it if the price is better. If it's not better, nothing changes.
- Enchanted books are priced differently than other items, based on enchantment level: (2 + level * 3 + random(0, level * 10 + 5)).
The result of these three components is that low-level books can easily replace higher-level books, but high-level books can never be priced low enough to ever replace some low-level offers. For example, the minimum cost for a level 5 enchantment is 17 emeralds. Once a librarian generates an offer for an enchanted book priced lower than that, they will never again offer a level 5 enchanted book. (Ranges for all levels, from the wiki: level 1: 5 – 19, level 2: 8 – 32, level 3: 11 – 45, level 4: 14 – 58, level 5: 17 – 71). Because of the random nature of generating offers, it's guaranteed that the more you trade with a librarian, the worse their offers will get. This is the exact opposite of how trading works for every other type of trade, including the librarian's offers for other types of items, in which it's guaranteed that offers will never get worse, and, if you trade with a villager enough, you will eventually unlock all their potential trades, at the lowest possible prices.
The enchanting offers provided by priests work entirely differently than enchanted books. The cost only ranges from 2-4, and is not related to the enchantment or its level. Offers can be replaced with a different enchantment, and that enchantment may be better or worse, but the full range (all enchantments that would cost 5-19 exp levels if you used a enchanting table) is always available for the offer generator to pick from, and nothing about the existing enchantment offer will ever exclude part of that range.
It is almost certain that the behavior of enchanted book offers is an oversight, not an intentional deviation.
But according to MC-349 NBT data is still ignored ?!
Anyway, is this issue obsolete with the new trading mechanics of 14wXX ?
Duplicate of MC-349
The plan is for data values to go away entirely in 1.9. The relationship between block ids, data values, and blockstates is currently hardcoded, but that should change in 1.9. It's not currently possible to define your own blocks or items. The method people were using before to accomplish this was a bug that had to be fixed in order to move forward on the rendering and block engines, which themselves needed to be rewritten for the plugin API. It's unfortunate that this is such a huge task that it can't all be completed in one release cycle. However, you should be able to limit villager trades using data tags, though that is currently broken, and also scheduled to be fixed in 1.9. They're rewriting core components of the game that a lot of things depend on, so that the behavior will be predictable and more easily customizable. They're trying to prevent it from breaking things in the meantime, but so much of Minecraft is too hardcoded and interdependent for it to be a perfectly smooth transition.
I'm not aware of any way to prevent an item from being used in crafting using data tags. That would make for a good feature request.
Intended. Caused by the fix of MC-349.
This bug is essentially the opposite of MC-349, and is intended.
The Recipes entries still add a Damage tag with the default value of 0. Changing it so that this tag is ignored would then bring the disadvantages described in MC-349 again.
But it might be difficult to solve since the item NBT data likely has to be converted to an ItemStack object to be validated, which probably adds the Damage tag.
In terms of consistency, I agree that adding enchantments to items should not affect their durability. However, seeing as different colours of wool are not distinguished in terms of, say, crafting, it doesn't really make sense for villagers to make this distinction.
Yes, this is why I suggested the fix should only apply to priest's enchantments, and to whatever custom offers a map maker chooses to add the property to. I explicitly said that it would be an issue if farmers distinguished wool color
confirmed, NBT tags, I understand why villagers don't look at that.
Damage values too a bit, when we're talking about tools. Although when you make a custom villager, it would be handy to trade only with a certain map.
That is a bad glitch in my opinion. You can forever repair your diamond tools at almost no cost. Enchanting damaged tools should at least retain the damage value.
I'll go with 'only the green villager watches NBT data and damage values' that's handy for mapmakers.
I'd like to mention two things which worsen this bug:
1. Anvils now allow you to abuse the enchantment offers like never before. The enchantment offer not only restores the durability - it also restores repair cost! At this point, you can buy something like Sharpness III on your 1-use-left dozen-times-repaired diamond sword, and use an anvil with a Sharpness III book to upgrade it to something respectable - at a very small fraction of the cost!
2. On the Plugin API JIRA, Mojang's Grumm has revealed that Mojang plans to do away with block metadata altogether. This means each wool will have a different value - and thus, farmers will only buy white wool after this change. So, the main good reason to have this bug will be removed in the future, leaving nothing but an exploitable bug and a headache to mapmakers.
There is also a bug:
If you create a villager with MCEdit, after some closing and opening from minecraft, he trades 1 Emerald for 8 Gold, and this is each time like this.
hmm yeah that's weird
I wouldn't say it's a bug for Minecraft to not interact correctly with MCedit, considering MCedit's a third-party tool. Does the same happen when creating a villager with any tool? If so, that would imply something changed in the NBT format or the game isn't loading the villagers correctly - either case would also mean that bug applies to vanilla villagers, and if you have evidence of that, then file a report about it. I personally haven't noticed villagers reverting to "1 Emerald for 8 Gold", although I haven't tested villagers on the snapshots - what version do you get this issue in?
At any rate, how do you directly create a villager in MCedit? If you're importing a schematic, the villager will have the trades it has in that schematic - edit the NBT if you want something different. If the villager has no trades, vanilla will generate offers based on the villager's profession. If the profession is 5 (unused), the only offer that villager has is 8 gold ingots for 1 emerald, regardless of how many times you trade it. Vanilla has never had an offer of "1 Emerald for 8 Gold", so if it's not MCedit's fault then it's a very strange bug indeed.
I use an NBTedit mod I created a trade where 2 different maps (with different damage values) are traded for another map (so map 1 + map 2 --> map 3) but it is still possible to put in map 1 twice and still get map 3. Without even gaining map 2.
That's my problem but this can also be a problem for vanilla survival. For example it is very easy to repair tools now using the Priest.
I agree with that; it should honestly be fixed - I suppose I should clarify that my last post was addressed to Marcono1234 (which is describing a different, seemingly unrelated bug which I've yet to actually witness).
I'm glad I'm not the only one having this problem. I tried making villagers trade items for custom items (Dmg values/Name/ect) for my adventure map and ran into this. My problem is not related to enchantments but it's caused by the same issue.
When I found out the villagers did not respect NBT tags, I thought "No biggy. I'll just use bogus damage values to force them to only accept custom items." So when I try that, it fails also.
Hopefully Mojang gives us more of a answer then the villager did when I asked. All I got from him was "Hmm."
Edit: I just saw the post date for this bug... Sigh Remember to up vote it or they'll never get to it at this rate. .-.
yeah, for some reason some bugs take a looooongg time to fix
I think they just prioritize bug types (Which makes sense of course). Although this is a big issue with a lot of people, it's just not high on their to-do list. I just hope they find time for it eventually. :/
Today marks this issue's 1 year anniversary. Even though it has not been seen to yet, I'm glad people have not forgot about it. Thank you mods and OP for keeping the issue up to date.
Just out of curiosity, what do people think is the biggest issue holding this up? Complicated coding, Mojang just being busy with bigger things, or the caveats Gerrard mentioned at the bottom of the original post?
It's probably either the caveats, or Mojang being busy.
Looking at the code, it wouldn't be complicated to fix: if you ignore the caveats, it's literally a change to one line (compare items by their existing equality method, rather than the equality of their IDs). My suggestion of adding an "offer strictness" tag to workaround those caveats would take a little more, but it wouldn't actually be complicated.
I'm guessing there's a chance this issue will be revisited once Mojang removes block metadata, as it will break the farmer's wool offer (as I mentioned a while back). I'm interested in seeing if/how they will fix that.
Confirmed for 1.7.4
This has been fixed by Jeb: https://twitter.com/jeb_/status/420896850879987712
This is not actually fixed. Villagers will still ignore NBT tags. For example, you can trade the following villager ordinary bedrock instead of bedrock named "CustomBedrock":
/summon Villager ~ ~ ~ {Profession:1,Offers:{Recipes:[{buy:{id:7,tag:{display:{Name:CustomBedrock}},Count:2},sell:{id:1,Count:64}}]}}Confirmed for 14w02b; can this please be reopened?
Does the damage value still not matter?
@Ezekiel I can confirm that the Damage tag in this is fixed, but can also confirm that dataTags are still ignored.
Reopened specifically for data tags. May be working as intended, however.
Confirmed for 14w05b and now 14w06a/b. Present in 14w07a/14w08a.
Confirmed for 14w28a.
Confirmed in 14w28b as well.
Confirmed still broken in 14w30b
Hello. I'm mostly talking about Pocket Edition bugs (such as MCPE-1319 texture bug), but this bug made me worrying about custom maps and things like that.
I agree with people who want the 'strict' tags to be in Minecraft. Sometimes, one may need or just want to trade an used tool (enchanted or not) for a better one, but he/she may see a trade needing a fully-repaired tool. This is not a problem if you have an anvil, but custom tools may not be repaired like that (unless using custom attributes), while repairing by crafting will remove all enchantments and revert attributes to normal. So, the 'strict' tag will save most custom maps.
Also note that I only played PC Minecraft on my brother's computer (versions 1.5.2 and 1.7.4). Other times, I played Minecraft Pocket Edition (demo and v0.8.1), but stopped due to MCPE-1319 texture bug, plus I cannot update to 0.9.5.
Confirmed for 14w31a
In the 1.8 update, it seems this might have been partially fixed, probably because they went through and rebalanced villager trading. For the modified trades, the commands might not have been set up properly.
{id:"minecraft:Item name",Damage:0s,Count:1b}{Offers:{Recipes:[0:{buy:
,sell{id:"minecraft:Item name",Damage:0s,Count:1b,
{id:1s,lvl:1s}tag:{ench:[0:
,]}}},]}}
Mapmakers can easily set up villager trading using this data tag set up; tag:{ench:}} is optional.
Villagers will only accept the specified data values, so items like dyes and wool will work as intended now.
entitydata @e[type=Villager] {Offers:{Recipes:[0:{sell:{id:"minecraft:wool",Damage:14s,Count:1b,tag:{}},buy:
{id:"minecraft:wool",Damage:0s,Count:1b},buyB:{id:"minecraft:dye",Damage:1s,Count:1b}},]}}
This command will make a villager accept regular white wool and red dye and trade you red wool. It will not accept any other wool or dye color.
Try using the command:
{id:35s,lvl:5s}/entitydata @e[type=Villager,r=5] {Offers:{Recipes:[0:{sell:{id:"minecraft:diamond_pickaxe",Damage:0s,Count:1b,tag:{ench:[0:
,]}},buy:
{id:"minecraft:diamond_pickaxe",Damage:0s,Count:1b},buyB:{id:"minecraft:emerald",Damage:0s,Count:10b}},]}}
If I typed it correctly, this should change any villager within a radius of 5 blocks to offer the trade of a special diamond pickaxe with a fortune 5 enchant for a regular diamond pickaxe and 10 emerald. Unfortunately, this requires a fully repaired diamond pickaxe to work; trying to trade a damaged one will fail to work. If you wanted to have it not repair the pickaxe, you would have to change the value for the Damage tag under sell and buy so that they match.
For an easier solution, there would have to be a way where it checks the damage value on the tool being bought by the villager and apply that value to the tool being sold.
The problem is that these data tags apply to the items seen under the trading gui, and it simply checks for a match on your item and applies the values under the sell tag to the item being given to you. It would have to apply the damage value of your item to the item being sold, and take the values under the tag data tag from the sell tag, and merge that with the data of your item.
Sorry for the long explanation, but I hope this helps.
@Aaron, the problems is the inability to define the "tag" tag in the "buy" compound to force players to provide an item that has specific extra data, such as a display name or custom data. The "Damage" value detection was originally the issue, but was fixed a while ago in the 1.8 snapshots. The report remains open for the "tag" tag, specifically for the "buy" tag. The "sell" tag has always worked as far as I can recall.
Sorry, I just tested that and you are right. Thank you for the input, I have only recently started trying to help on bugs/glitchs and have also only started testing them, so I don't know exactly when these fixes were implemented.
It only applies the data under the tag data tag to the item under the trading gui.
The code is probably just missing for checking for a complete match, and it might be a simple fix.
The only fix for it repairing an item that gets enchanted by a villager seems to be that they just changed it to giving you an enchanted item for emeralds instead of enchanting an item you give them.
Aaron PLEASE stop editing your comments after you post, re-read them carefully before you submit your posts. Every time you edit them it sends everyone watching this Bug which is 30 people.
So far I have gotten 20+ emails of you editing the post you made, this is pretty irritating.
Thank you.