Uploaded image for project: 'Minecraft: Java Edition'
  1. Minecraft: Java Edition
  2. MC-123055

Villagers not breeding, recognizing houses or farming

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Minecraft 18w15a
    • Minecraft 17w49b, Minecraft 17w50a, Minecraft 18w01a, Minecraft 18w02a, Minecraft 18w03b, Minecraft 18w05a, Minecraft 18w06a, Minecraft 18w07c, Minecraft 18w08b, Minecraft 18w09a, Minecraft 18w10b, Minecraft 18w10d, Minecraft 18w11a, Minecraft 18w14a
    • Confirmed

      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

      By Skylinerw

      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)

        1. 2018-03-10_16.32.39.png
          2018-03-10_16.32.39.png
          415 kB
        2. 2018-03-10_16.52.48.png
          2018-03-10_16.52.48.png
          379 kB
        3. 2018-04-11_14.01.30.png
          2018-04-11_14.01.30.png
          714 kB
        4. deathstarfarming.png
          deathstarfarming.png
          2.85 MB
        5. villagenotfullymerged.png
          villagenotfullymerged.png
          2.04 MB
        6. 2019-12-22_17.05.02.png
          2019-12-22_17.05.02.png
          2.10 MB
        7. 2019-12-22_17.05.02.png
          2019-12-22_17.05.02.png
          2.10 MB

            ProfMobius ProfMobius (Thomas Guimbretiere)
            klugemonkey David Chamberlin
            Votes:
            144 Vote for this issue
            Watchers:
            73 Start watching this issue

              Created:
              Updated:
              Resolved:
              CHK: