Villagers not breeding, recognizing houses or farming
The bug
Villagers are not breeding in test where houses are at same level as villagers. Created 20 houses around two villagers, made them willing by trading and stacks of bread, but they do not breed any villagers after a long test period. Villagers do not seem to be recognizing houses in generated villages at night as well. They do trade food. Observed a villager running away from a village with doors at night being chased by two zombies.
Workaround
For the time being, a possible (but probably annoying) work-around would be to ensure the villagers are 4 blocks below and 16 blocks in the negative X and Z directions from a door in order to create a village at the proper location.
Code analysis
Villages are created successfully, but are immediately destroyed because the center of the village is much further than the valid door. Using MCP 1.12 for names, and having modded a decompiled 18w05a to ensure it works, this appears to be a one line fix.
In 1.12.2, net.minecraft.village.VillageCollection.addDoorsAround(BlockPos central) creates immutable BlockPos objects for the positions around the villager's location where it should search for doors.
Now in 1.13, it uses net.minecraft.util.math.BlockPos.getAllInBoxMutable(int, int, int, int, int, int), which for all intents and purposes does the same thing except that it uses a single mutable BlockPos whose coordinates are changed when the next item is requested from the iterator. The loop finds the door correctly, but stores the mutable position in a list of doors to be added later to the village (call to VillageCollection.addToNewDoorsList(BlockPos)). Instead an immutable copy of the position should be passed to addToNewDoorsList since otherwise the found door positions change once the next positions are requested from the iterator resulting in all doors "found" at the last search position and therefore being removed from the village since there is (most of the times) no door.
Mappings
| MCP name | 18w06a name | 18w06a MCP equivalent name |
|---|---|---|
VillageCollection.addDoorsAround(BlockPos) |
afr.b(ec) |
see MCP name |
VillageCollection.addToNewDoorsList(BlockPos) |
afr.a(bfj, ec) |
VillageCollection.addToNewDoorsList(IBlockState, BlockPos) |
Linked Issues
is duplicated by27
relates to6
Created Issue:
Villagers not breeding, not recognizing houses
Villagers are not breeding in test where houses are at same level as villagers. Created 20 houses around two villagers, made them willing by trading and stacks of bread, but they do not breed any villagers after a long test period. Villagers do not seem to be recognizing houses in generated villages at night as well. They do trade food. Observed a villager running away from a village with doors at night being chased by two zombies. Something is just not right.
Environment
Java 1.8.0_151 64bit, Debian Linux 9, ES-1660, Quadro 4000
duplicates
relates to
is duplicated by
duplicates
Villagers not breeding,notrecognizinghousesVillagers not breeding, recognizing farms or farming
Villagers not breeding, recognizingfarms or farmingVillagers not breeding, recognizing houses or farming
is duplicated by
relates to
is duplicated by
Java 1.8.0_151 64bit, Debian Linux 9, ES-1660, Quadro 4000
is duplicated by
is duplicated by
is duplicated by
Seems like villages.dat does not contain valid entries for the villages. Seems to store the Tick integer value, but the Villages NBTTagList had no NBTTagCompound entries. Villagers still seem to go into houses at night.
relates to
is duplicated by
relates to
relates to
Villagers are not breeding in test where houses are at same level as villagers. Created 20 houses around two villagers, made them willing by trading and stacks of bread, but they do not breed any villagers after a long test period. Villagers do not seem to be recognizing houses in generated villages at night as well. They do trade food. Observed a villager running away from a village with doors at night being chased by two zombies. Something is just not right.
Code Analysis by [Mod] Skylinerw can be found in this comment .
Villagers are not breeding in test where houses are at same level as villagers. Created 20 houses around two villagers, made them willing by trading and stacks of bread, but they do not breed any villagers after a long test period. Villagers do not seem to be recognizing houses in generated villages at night as well. They do trade food. Observed a villager running away from a village with doors at night being chased by two zombies.
Something is just not right.Code Analysis by [Mod] Skylinerw can be found in this comment.
The bug
Villagers are not breeding in test where houses are at same level as villagers. Created 20 houses around two villagers, made them willing by trading and stacks of bread, but they do not breed any villagers after a long test period. Villagers do not seem to be recognizing houses in generated villages at night as well. They do trade food. Observed a villager running away from a village with doors at night being chased by two zombies.
Code analysis
Code analysis by [Mod] Skylinerw can be found in this comment.
The bug
Villagers are not breeding in test where houses are at same level as villagers. Created 20 houses around two villagers, made them willing by trading and stacks of bread, but they do not breed any villagers after a long test period. Villagers do not seem to be recognizing houses in generated villages at night as well. They do trade food. Observed a villager running away from a village with doors at night being chased by two zombies.
Code analysisCode analysis by [Mod] Skylinerw can be found in this comment
.The bug
Villagers are not breeding in test where houses are at same level as villagers. Created 20 houses around two villagers, made them willing by trading and stacks of bread, but they do not breed any villagers after a long test period. Villagers do not seem to be recognizing houses in generated villages at night as well. They do trade food. Observed a villager running away from a village with doors at night being chased by two zombies.
Workaround
For the time being, a possible (but probably annoying) work-around would be to ensure the villagers are 4 blocks below and 16 blocks in the negative X and Z directions from a door in order to create a village at the proper location.
Code analysis
Villages are created successfully, but are immediately destroyed because the center of the village is much further than the valid door. Using MCP 1.12 for names, and having modded a decompiled 18w05a to ensure it works, this appears to be a one line fix.
In 1.12.2, net.minecraft.village.VillageCollection.addDoorsAround(BlockPos central) creates immutable BlockPos objects for the positions around the villager's location where it should search for doors.
Now in 1.13, it uses net.minecraft.util.math.BlockPos.getAllInBoxMutable(int, int, int, int, int, int), which for all intents and purposes does the same thing except that it uses a single mutable BlockPos whose coordinates are changed when the next item is requested from the iterator. The loop finds the door correctly, but stores the mutable position in a list of doors to be added later to the village (call to VillageCollection.addToNewDoorsList(BlockPos)). Instead an immutable copy of the position should be passed to addToNewDoorsList since otherwise the found door positions change once the next positions are requested from the iterator resulting in all doors "found" at the last search position and therefore being removed from the village since there is (most of the times) no door.Mappings
MCP name 18w06a name 18w06a MCP equivalent name VillageCollection.addDoorsAround(BlockPos) afr.b(ec)see MCP name VillageCollection.addToNewDoorsList(BlockPos) afr.a(bfj, ec) VillageCollection.addToNewDoorsList(IBlockState, BlockPos)
Code Analysis
Villages are created successfully, but are immediately destroyed because the center of the village is much further than the valid door. Using MCP 1.12 for names, and having modded a decompiled 18w05a to ensure it works, I have what appears to be a 1-line fix for this issue. A forewarning: I am no expert in Java whatsoever, so while this fix does work, I can't quite explain why or if it's a good fix.
In 1.12, net.minecraft.village.VillageCollection.addDoorsAround(BlockPos central) uses an inline loop to find doors around the provided BlockPos (which is the villager's location that is adding a door to the village). Now in 1.13, it uses net.minecraft.util.math.BlockPos.func_191531_b(), which for all intents and purposes does the same thing.
The issue, with my limited experience in Java, seems to be usage of static iterables. The loop finds the door correctly, and stores the door's location in a list to use later. But it's storing the static iterable, which is continuing to loop until it reaches 16x4x16 blocks away from the villager's location. That means the door's final location will instead be that many blocks away from the villager, rather than the actual door's location.
The 1-line fix is found in net.minecraft.village.VillageCollection.addToNewDoorsList(BlockPos doorBlock), which in 18w05a it would be aet.a(bcl bcl, ea ea) (equivalent to VillageCollection.addToNewDoorsList(IBlockState blockState, BlockPos doorBlock)).
This line, in which BlockPos (ea) is directly from the static iterable:
aeq aeq = new aeq(ea, n2 < n ? eg : eg2, this.e); Equivalent to: VillageDoorInfo VillageDoorInfo = new VillageDoorInfo(BlockPos, n2 < n ? EnumFacing : EnumFacing2, this.tickCounter);Is changed to:
aeq aeq = new aeq(ea.h(), n2 < n ? eg : eg2, this.e); Equivalent to: VillageDoorInfo VillageDoorInfo = new VillageDoorInfo(BlockPos.toImmutable(), n2 < n ? EnumFacing : EnumFacing2, this.tickCounter);The difference being the addition of toImmutable() to the BlockPos, which fixes the offset and the door's position becomes correct (and villages will then work).
If somebody with more knowledge on Java's mechanics can correct my analysis, that would be great! This should also fix
MC-122369andMC-122538for new villages.For the time being, a possible (but probably annoying) work-around would be to ensure the villagers are 4 blocks below and 16 blocks in the negative X and Z directions from a door in order to create a village at the proper location.
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
relates to
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
relates to
Another observation about the areas to the south outside the circle in the deathstarfarming image, they are not harvested, just planted.
OK, I wrote a long comment above, but TL;DR. So I will summarize my test results.
1. Villagers are confirmed as breeding with my infinite breeding test using 4 doors 5 blocks below the villagers.
2. A farming radius test around a single door made the expected pattern of crops 31 blocks to each side of the center block, however failed in time in the south direction due to an anomaly with the villager AI (see deathstarfarming image).
3. A village merge test between two villages placed with 63 blocks in between was successful, the first village farms were created 31 blocks to either side, after the second village only the blocks at or between the doors were planted and farmed. The farms from the opposite side of the first door was no longer harvested as expected. (see villagenotfullymerged image)
4 A villager iron golem test was successful with 10 villagers and 21+ doors, in the 16x16 area, and retested with 20 villager and 21+ doors which spawned 2 golems over time but stopped there as expected.For the intent of the bug reported, this issue seems to be confirmed as resolved, however, this anomaly observation of the farming ai in the south direction looks like a new and possibly related issue and needs attention.
relates to
Thank you for your report!
However, this issue has been closed as a Duplicate of MC-123055.
It has been linked to this report. If you have additional information, please add it to the duplicated report.
Please search before reporting, as it's likely that one exists already.
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Customer Support – 📖 Game Wiki
Thank you for your report!
However, this issue is a Duplicate of MC-123055.
If you have additional information, please add it to that report.
Please search before reporting, as it's likely that one exists already.
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Customer Support – 📖 Game Wiki
Duplicate of MC-123055, unless you don't get the purple particles either.
Related to MC-123055?
Thank you for your report!
However, this issue is a Duplicate of MC-123055.
It has been linked to this report. If you have additional information, please add it to that report.
Please search before reporting, as it's likely that one exists already.
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Customer Support – 📖 Game Wiki
Please do not mark issues as private, unless your bug report is an exploit or contains information about your username or server.
Thank you for your report!
However, this issue is a Duplicate of MC-123055.
If you have additional information, please add it to that report.
Please search before reporting, as it's likely that one exists already.
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Customer Support – 📖 Game Wiki
Aha, thanks for the clarification; I think I found the issue: MC-123055
Thank you for your report!
However, this issue is a Duplicate of MC-123055.
It has been linked to this report. If you have additional information, please add it to that report.
Please search before reporting, as it's likely that one exists already.
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Customer Support – 📖 Game Wiki
In 1.12, a villager will detect doors (house) up to 3 blocks above the ground level they are standing on as documented by the wiki: https://minecraft.gamepedia.com/Tutorials/Village_mechanics#Housing
This is used in many villager breeders to allow them to be turned off by moving the villager out of range of the doors. This is also used by many iron farms designs to enable the manipulation of villages and allow them to be stacked to increase the rates of these farms.
In 1.13-pre1, this detection range seems to have increase to 4 blocks. This means that many villager breeders will continue to produce villagers even though the player may assume their breeder is off which could be detrimental to their world due to the increased entities. This also breaks many iron farms that work just fine in 1.12 and will require rebuilding. This is a non-trivial task as many of these iron farms rely on precise positions of villagers at particular timings for them to work correctly. This change will mean a lot of reworking for technical players in 1.13.
I believe this changes the census area from 32x32x8 to 33x33x9.
I've attached some screenshots from 1.12 and 1.13-pre1 showing the issue as well as a world download of each. Please note that when moving the villager out of range you need to wait for a little while for the village to deregister. I don't know the exact timing of that but if you wait 5 minutes that will be plenty.
I've also made a video showing the issue here: https://youtu.be/s-VzpcRLdJc
After posting the above video I was shown bug MC-123055 which maybe related but its marked as resolved currently.
Found it! This is the one I remember seeing. MC-123055 It says it's fixed? But maybe they just mean the breeding part?
Relates to: MC-123055.
Relates to: MC-123055.







Just to clarify, if I create a village and add villagers, they should conglomerate around the center of the village. This appears to be offset, however even if the villagers are at the offset location, they still are not breeding.
I can confirm. Tried same artificial village in 1.12.2 and in snapshot 17w50a. Villagers breed in 1.12.2 but not 17w50a. Also, in another test villagers eventually drift southeast in the snapshot rather than northwest like in the release.
Also confirmed, 17w50a. Tried several methods, no number of doors or trading seems to make villagers want to breed.
Confirmed for 18w01a, no entries appear in villages.dat.
Confirmed 18w01a, villagers still won't breed. Tried a villager breeder that worked in 1.12.2, it didn't work in neither 17w50a nor 18w01a. Also tried an abandoned village and added some more buildings and two villagers, couldn't get them to breed.
Villagers still don't breed in 18w02a.
Villagers still don't breed in 18w03b. Wonder why this isn't assigned to anyone? Sort of a serious bug for anyone who wants to make a base full of villagers, or someone who just wants to repopulate a zombified village.
I have confirmed from my own experiments that villagers do not detect doors.
In villages.dat in the nether, end, and overworld, not a single village is created. Villagers do not track towards doors, do not breed, and do not produce iron golems.
Possibly related to
MC-122308?Testing with 18w03b, villages.dat is being called to save village data when doing save-all, but village door data is non-existent, or a single incorrect entry is included for a village with multiple doors. So, houses are either not being added, perhaps due to how door direction is determined, or possibly something is removing houses from the list. Either way, should be pretty straightforward to debug why villages.dat gets no door entries if someone looks into this issue.
With the changes in the codebase I would assume that the variable/ID for doors has changed and that the villagers have not been redirected to the new var.
Just tested 18W05A, villagers still don't breed. Crafting erotic magazines and handing them to villagers also doesn't help them to breed. This new version is still broke.
As of this morning 18w05a is still not saving info in the data/villages.dat file. Consequently villages are not recognising doors and not breeding. I'm surprised this bug is still Unassigned.
Tried it again in 18w07c, breeding still doesn't work. Also, /locate says that villages are at y=0? Still a bug...
In 1.12.2 they sometimes breed but with some door configurations that should work according to the minecraft wiki, they don't work.
I was able to open Minecraft 18w08b with the ASM Village Marker mod, which draws the village radius and detected doors to the screen. In a void world, I made a line of doors and spawned a ton of villagers. The villagers are detecting the doors, BUT the villages instantly despawn. See this video to see what I'm talking about: https://www.youtube.com/watch?v=OAsust8I-m0
(Confirmed for 18w08b)
Tried getting villagers to breed in 18w09a, villagers still act like no doors are around and they're still not interested in breeding. I imagine Mojang is probably knuckling down on the 'look and feel' part of 1.13 now and they'll hit the 'debug' portion of the release later, but hopefully this village/villager bug gets fixed before 1.13 is released.
Agreed, cannot stand villagers not breeding.
I can confirm this for 10w08d, using the ASM village marker mod (https://www.youtube.com/watch?v=p8IcoPeeIOg).
It's worth pointing out that when the villages are created (then immediately destroyed) their centres are pretty far away from where the doors are. It's possible that for some reason the villagers detect the doors, save the wrong coordinates, then the game checks if there is a door there and fails, deleting the village.
OK, I've just done a bit of testing. I made a strip of 12 "house" doors and found where the village's centre was. I made a platform of doors in that area, and to my surprise the village stayed after "detecting" a few doors in that area, but every few seconds its centre would tick to the left or right. These doors also wouldn't've counted as houses as there were no roof blocks. When I put down a bit of farmland and seeds and two villagers, they entered love mode and began farming!
And to add to all of this, after looking at the NBT of the villages.dat file, there were 12 door entries (which is correct) BUT they all had the same X/Y/Z coords. When I broke all the doors on the platform EXCEPT for the door at that position, the village still broke, and the centre moved when I placed all the doors back. I minimized the platform to the smallest I could with the village intact, but after a few seconds (presumably an autosave) the village broke again, then later reappeared. The platform with the doors is 16 blocks east, 16 blocks north, and 3 blocks up from the original doors with 5 strips doors on either side of the centre strip (after some adjustments to my experiment).
That's exactly what it's doing. The loop being used to check for a door within an area around the villager uses a mutable BlockPos instead of immutable, so while the door's position is detected correctly, the final coords will be in +16X/Z and +4Y from the villager's location (since that's where the loop ends). See the description of the report for this info; the fix is to simply call toImmutable() when storing the BlockPos.
OK, interesting. This seems like a pretty simple fix.
Still an issue in 18w14a.
Seems like it might be fixed in 18w15a. I've seen villagers take shelter in the houses and also seen them breed in a simple pen surrounded by 'houses'. I haven't tested all the mechanics in detail though.
Fixed in 18w15a. I loaded my village testing world in 18w15a with the ASM Village Marker Mod (it has a mod builder to work with any version) and the village doors are recognized in the right places.
The doors are also saved properly after closing; I checked the villages.dat file.
I noted 18w15a is also affected but later it is removed.
Can someone confirms if the villagers can breed in 18w15a?
The previous testing showed that it was saved properly (see the above comment); 18w15a was added because
MC-128611was reported and it's currently being checked whether this is actually still an issue or not.This issue as reported, has been confirmed as being resolved for 18w19b.
Summary:
1. Villagers are confirmed as breeding with a typical infinite breeding test using 4 doors placed 5 blocks below satisfied villagers.
2. A farming radius test around a single door made the expected pattern of crops 31 blocks to each side of the center block, however an anomaly was observed in the south direction possibly due to villager AI behavior (see image).
3. A village merge test between two villages placed with 63 blocks in between was successful, the first village farms were created 31 blocks to either side, after the second village only the blocks at or between the doors were planted and farmed. The farms from the opposite side of the first door was no longer harvested as expected. (see image)
4. A villager iron golem test was successful with 10 villagers and 21+ doors, in the 16x16 area, and retested with 20 villager and 21+ doors which spawned 2 golems over time but stopped there as expected.
For the intent of the bug reported, this issue seems to be confirmed as resolved, however, this new anomaly observation of the farming ai in the south direction needs further investigation.
Seems like this bug is back on console Xbox One v1.9.0
Did the update and now none of my farms are breeding, picking up food or farming. I even created 2 new breeding farms and still no luck.
For issues with the 1.14 snapshots, please create new tickets, if none exist yet.
Hmm this bug still exists for me as of 12/22/19 in 1.15.1. Here's a screenshot as proof:
Interesting that this issue has been fixed since 2018 because my screenshot shows a different story. O.o
Also, thanks Dave for reporting this! I am hoping this issue really gets fixed. It's pretty frustrating to watch your villagers die each night because they can't go in their homes.
I have heard that if there's anything within 1 block of the door the villagers won't enter the door for some reason.
My best guess for this was someone swept this under the rug. We'll prob never know who it was. But I am sure that Jeb found out about this and handled it appropriately.
As I said above, if you're still encountering this (or a similar) issue, please create a new ticket, if we don't have one already. Also note that every comment edit sends a new email to every single person who watches this ticket.
Hello there. Ah ok thanks for the heads up about watchers of tickets. Yes; I did report the issue after it was going on for several months; however here's where it gets really odd... Anytime that I reported that issue, someone would remove it saying it was a duplicate. O.o I double checked the others, and all of them were listed as resolved.
At that point I just decided that ok someone doesn't want to deal with this problem so it prob would never get fixed. Out of frustration I quit playing the game.
As of 2020 this issue was mostly repaired but not 100%. I decided to resubmit it again after I fine tuned what could be causing it to give it another chance.
At the time I didn't think anyone cared about our comments because of what happened and I am glad that someone did reply back.
JD: As violine1101 stated: "Also note that every comment edit sends a new email to every single person who watches this ticket."
You just sent out 936 emails. I recommend writing your comment in a text editor and finalizing it before submitting it to avoid this.