mojira.dev
MC-210214

Cured zombie villagers stop being grateful after a short time.

In a hard level game I am currently playing I cured a pair of zombie villagers, made them into farmers and started trading with them. At first they gave me great discounts, but after a few days of play I suddenly noticed that not only had they stopped applying the 'gratitude' discount, they were charging me more than double for the trades relative to farmer villagers that had never been zombified.

This is not related to the issue reported in MC-154504, because no version upgrades were applied.

SPECULATION: between curing the zombie villagers and noticing their changed behaviour new Microsoft accounts were introduced. Could this have changed the player ID in some way?

Comments 6

SPECULATION: between curing the zombie villagers and noticing their changed behaviour new Microsoft accounts were introduced. Could this have changed the player ID in some way?

No this has absolutely nothing to do with it.

A couple of questions:

  • Did you damage/kill any villagers or iron golems nearby?

  • Did you use a multitude of trades on these villagers or did you always use the same trade? If you use a specific trade too often, it will become more expensive, see MC-146373.

@unknown To answer your questions:

  • At no time were there any other villagers or iron golems near the two affected cured villagers. (They were in an igloo a long way - several regions - away from any other villagers).

  • I did repeatedly use two trades with this pair of farmers. However, in another village a long way away I had a 'control' pair of farmers I was also doing the exact same trades with. The difference was stark. The 'control' farmers consistently offered the trades at the baseline price or with a small discount. The cured farmers, after offering fantastic discounts for a short time, ended up charging double the baseline rate, and I simply stopped trading with them or even bothering to visit them.

It was the second point that motivated me to report this as a bug.

The same bug was met at 21w05b.

I captured a zombie and gave it a axe with sharpness V. Then I used it to kill villagers in hard mode. After many times of killing, Villagers gave me a lot discount - Only one emerald is needed for each trading.
But later, some villagers cancelled their discount. I have 9 villagers, 2 of whom cancelled their discount. The extent to which the two villagers cancel the discount is not the same. One of them cancelled part of the discount(about once salvation from zombie villager), and the other cancelled all the discount. I don't know the reason.

Speculation: Raid, Hero of the Village and other players' salvation may affect the villager. Because the first villager who cancelled its discount was appeared after I completed a raid and got the hero of the village, and another player was saving it at that time.

Repeat the bug may be very hard. Some test will be done later.

Some Other Info:
Version: 21w05b
Java: OpenJDK 14
System: Windows 10
In vanilla multiplayer server

I am unable to reproduce this in 1.17. Cured villagers prices go up by no more than one unit after a long time has elapsed.

Please provide a video with the debug screen enabled (hit the F3 key) demonstrating the issue.

In vanilla multiplayer server

Now I think the multiplayer server is the reason. I have asked my friends, and they meet the same bug, too. Our server is 1.17.1 now, and there is still this bug.

According to my friends' guess, if a player cure a zombie villager, and other players who have had discounts isn't "there"(They didn't explain what's the "there" mean and I'm awaiting their response), the villager will cancel its discount for the players who are not there. 

I used to have a try for that. By this way, I succeed in cancelling a farmer's discount for a online player who was building a ice farm about 8000 blocks away.

Video...I have no time to record it now. A few days later may be okay? Perhaps my friends will response and help me record it at that time.

Robert Bowles

(Unassigned)

Unconfirmed

(Unassigned)

1.16.4

Retrieved