Villager leader/center changes every time you log in and out
I was Making a iron farm and i needed To find the villager leader so the iiron golems would spawn on the platform but every time i log Out and log back in the leader changes. Thank You
Linked Issues
is duplicated by9
Created Issue:
Villager leader changes every time you log in and out
I was Making a iron farm and i needed To find the villager leader so the iiron golems would spawn on the platform but every time i log Out and log back in the leader changes. Thank You
is duplicated by
is duplicated by
is duplicated by
Villager leader/center changes every time you log in and out
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
Thank you for your report!
However, this issue is Invalid.
Please put only one bug report in each ticket. It is very difficult to keep track of bugs when they are not in their own tickets, and it is easier for you to make multiple tickets than for the mods to separate them.\Please don't forget to search before logging each report as it is likely your issue has already been reported.
Also note that the issue with the leader changing is already being tracked as MCPE-54183. For villagers to sleep they must be able to reach the specific bed they are linked to. If you can verify this is happening this can be reported.
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Customer Support – 📖 Game Wiki
Thank you for your report!
We're actually already tracking this issue at MCPE-54183, so I will resolve and link this ticket as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Customer Support – 📖 Game Wiki
Thank you for your report!
We're actually already tracking this issue at MCPE-54183, so I will resolve and link this ticket as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Customer Support – ✍️ Feedback and Suggestions – 📖 Game Wiki
Thank you for your report!
We're tracking this issue as MCPE-54183, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been reported.
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Customer Support – ✍️ Feedback and Suggestions – 📖 Game Wiki
@Shannon Young The bug tracker is not the place to get detailed help sorting out your designs, sorry. I can give you a few pointers:
- Iron golems should not continue to spawn if you trap one village-spawned golem inside the village for every 10 villagers.
- Rather than a water trap, it might be easier and more space-efficient to leash iron golems to a fence post, or trap them in a boat or minecart.
- There is no such thing as a village leader. (See my last comment on MCPE-54183.)
- Bells do not define village centers. Instead, they set gathering points for villagers and the spawn area for wandering traders.
- The bell over your water trap is very likely to trigger the village center to shift every afternoon because villagers are blocked from gathering near it. (Again, see my comments on MCPE-54183.)
- Slabs, grass paths, etc. do not block iron golem spawns if there is a solid block underneath (what this ticket is about).
- Top slabs and double slabs do not block anything (it's not possible to place beds on bottom slabs, so I'm guessing you meant top slabs or double slabs).
- The spawnable blocks for iron golems have not changed at least since the Village & Pillage update, to my knowledge. The only change I am aware of is that the golems will usually spawn above any non-solid blocks that are on top of the solid block they spawn on, rather than inside those blocks. I believe that was the fix to
MCPE-41886. The block rules are just different for iron golems than natural mob spawns, but I think that is by design as I suggested in my earlier comment here. - You can find more information about controlling iron golem spawns and village centers on the Iron Farm Tutorial on the wiki (which I have recently re-written).
Thank you for your report!
We're actually already tracking this issue at MCPE-54183, so I will resolve and link this ticket as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
Thank you for your report!
We're tracking this issue in MCPE-54183, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
– I am a bot. This action was performed automatically! Please report any issues on Discord or Reddit
Thank you for your report!
We're tracking this issue in MCPE-54183, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
– I am a bot. This action was performed automatically! Please report any issues on Discord or Reddit
Thank you for your report!
We're tracking this issue in MCPE-54183, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
Thank you for your report!
We're tracking this issue in MCPE-54183, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 BDS Wiki – 📖 FAQs
The duplicate link to MCPE-50441 is correct because part of the issue reported here is that the villagers are linking to beds and workstations in places they cannot reach. However, the issue with bells destablizing iron farms is covered by MCPE-54183 so I have added that as an additional duplicate link.
Bells define a village meeting point, so villagers will try to pathfind to them in the afternoon. Whenever 3 successive pathfinding attempts to a POI fail, the village breaks links to the POI. Whenever village POI links change, the village center can shift.


Happens both on realms and local games
It also happens very frequently when you breed new villagers, and sometimes when you place profession blocks. Sometimes I have even ended up with three leaders (they get green sparkles when I place a bell).
Game version 1.14 on a Realm.
I tested this on local games and on realms and have been able to reliably reproduce this issue on realms only.
Would it be possible to get repro steps and/or a test world where this issue is happening?
can confirm on 1.16.0.55
I can confirm on 1.14.30 on realms As of 4/21/20 on bedrock for Xbox one
Thank you for your report!
However, this issue has been temporarily closed as Awaiting Response
Please include more information including steps to reproduce the problem:
If you have a simple test world also, that might help us understand the issue more easily.
This ticket will automatically reopen when you reply.
Quick Links:
📓 Issue Guidelines – 💬 Mojang Support – 📧 Suggestions – 📖 Minecraft Wiki
Steps to reproduce:
Observed results: The order of villagers in the dwellers and POI lists changes frequently, although the top 3 seem to remain the top 3. The the village coordinates, and by implication the center, sometimes change.
Expected results: The order of villagers in the dwellers and POI lists would remain the same, and the village center would remain the same.
Test world and Findings:
I've uploaded a test world: Village Leader Testing.mcworld
It looks like this:
Tl;dr to keep a village stable, make sure the founding villager always has exclusive access to his bed, and never use a bell.
Can confirm on Server and on Win10 edition 1.14.60.
On Standalone you just go out and back into your world to see the effect. For the server the bedrock-server.exe has to be restarted for it to change.
Easy test without looking into the data structures: Break the bell and the leader of the village will have storm clouds and his assigned bed is the center of the village. That works as long as the server is not restarted. You can break and re-create the bell and it will always be the same villager aka the leader.
After a restart (or exit/going back in on standalone) it's always a new villager.
Tried to recreate this iron-farm https://youtu.be/FoYXfnkfg08
The way he describes at t=12:00 onwards is not working at all as a result.
I need to amend my earlier findings on this report. I've found that the order of villagers in the dwellers and POI lists viewed with a third-party tool such as MCCToolChest is not necessarily significant. The order of the list changes every time you open and close the world. Therefore, a change in the order of the list is not evidence of de-linking from POI, and it does not always correspond with the center of the village shifting. According to a code-digger I trust, the changing order of the lists is because the game stores dweller data in an "unordered_map" that is recreated each time the village is loaded or unloaded.
In my previous comment I was careful not to endorse the concept of a "village leader" because I had heard from technical players that there is no such thing. The fact that the order of the dweller's list changes on every relog confirms that villages do not have a leader.
What villages do have is a center. My primary finding, that the village center can shift during the afternoon gathering time when a bell is present, remains valid. I suspect that the center shifting in the tests I ran--and in iron farms–is due to villagers not being able path to the gathering site, and de-linking from the bell as a result.
The reason angry and happy particles appear over exactly 3 villagers in relation to the bell may just be that it takes 3 failed attempts at reaching a POI to delink from it. With beds and workstations it's always 1 villager failing 3 times to reach its POI, but since bells link to up to 20 villagers, the 3 villagers failing to reach it once each might delink it from the village. Those same 3 villagers would then be first in line to relink when the bell is discovered, so they get the happy particles.
Code Analysis With the help of 0ld Guy, PekoNeko, and Yodalf, I have determined why the center of the village can shift around on login and logout. While running, Bedrock stores the POI information of a village in a data structure called a std::unordered_map. This data structure maps a VillagerID to a vector containing POI information for the bed, bell, and workstation that a villager is connected to (or if they aren't connected to any). This data structure is used to quickly look up the POI that a villager is connected to based on the villager's id. While the unordered_map is unordered, it is possible to iterate through a list of its contents; however, the order of this list varies between implementations of the std library and adding and removing villagers to a village can scramble it, as can saving and loading the information to an NBT list. As a result villager order can shuffle between restarts.
Normally the shuffling of villager order is not a problem for an unordered_map; however, when recalculating the bounding box of a village, the game does it in order of villagers in a way that makes the order matter. The game iterates through the data in the unordered_map, and the first POI found is used to construct the initial bounding box of the village. This POI can be considered the origin of the village. Villagers that occur earlier in the iteration are preferred over those that come later, and for a villager, beds have preference, then bells, then workstations when determining the origin POI. After the initial bounding box is set it is expanded as needed to accommodate all the POI in the village. The function that does the recalculation is Village::_calcPOIDist.
The center of the village is the center of the bounding box and is important for constructing iron and raid farms. As long as the bounding box is not recalculated the center of the village will not shift and farms will not break. Adding or removing POI (and some updates to the game) will cause the bounding box to be recalculated. If the order of villagers in the unorderder_map has changed, the identification of the origin POI might also change, changing the village's bounding box and its center.
In Game Workaround When constructing a village, don't add or remove POI after you are finished. (This includes villagers linking and delinking from their POI.) That way the village's center isn't recalculated outside of an update.
Proposed Solution 1 On Android, the implementation of std::unordered_map tends to reverse the order of villagers between saving and loading data to NBT. The solution to maintaining a consistent order is when loading data from NBT, add it to the std::unordered_map started from the end. Here is an example demonstrating is stability: https://gcc.godbolt.org/z/47KdcP. This does not appear to work on Visual Studio's implementation of std::unordered_map and a solution for Win10 will need to be investigated.
Impact None. This fix will add no complexity or performance costs to the game.
Proposed Solution 2 Replace std::unordered_map with std::map. Map orders its data by keys and is stable between saving and loading.
Impact Code complexity is not affected; however, std::map is potentially slower than unordered_map with a large number of villagers in a village. However, since the number of villagers per village tends to be low, std::map might be faster or about even with std::unordered_map.
Proposed Solution 3 Store POI information in a std::vector, and use std::unordered_map to map a villager to an index in this std::vector. The order of the vector would be kept constant between saving and reloading.
Impact This solution adds code complexity and would be potentially faster than std::map approach. It can also be implemented without changing how village information is saved on disk.
Proposed Solution 4 Calculate village boundaries in a way that doesn't depend on the order of villagers in a std::unordered_map. One possibility would be to construct a bounding box of from all the POI first, and then expand it as needed. Consequently, the origin of the village would be deterministically determined by the highest and lowest coordinate of POIs on each axis. The bounding box of the village would be set by the largest bounding box containing both the POI bounding box and a 64x24x64 bounding box centered at the origin of the village / center of the POI bounding box.
Impact This requires no changes with how POI information is stored in memory. This would be consistent with how players expect villages to work and would make easier for players to calculate their village centers. However, this change would impact trading-hall+iron-farm designs as the workstations in the trading hall would influence the center of the village. A solution to that would be to only use beds instead of every poi to calculate the village origin and initial bounding box, and then expand the bounding box as needed to accommodate every other POI.
Hi everyone!
I have made a "quick" demo, showing how a village is created, how the bounding box (village size) works, and how the first villager in the list, (the one I call leader) does matter when manipulating a village, as the center is the middle point of the square (or rectangle) that is the village size.
-In the video I explain briefly how the village size expands/where is created from.
-I show how the bounding box doesn't get recalculated until you update the village (adding or destroying POI) so the village size works the same as a BUD switch from Java redstone. (in my opinion a bad thing, as It should be dynamic/automatic)
-I show how adding more villagers may scramble the order in which the villagers are ordered and will make the first villager and a random villager to switch positions, making the village's bounding box change if you update it continuously.
-Also, how the order between those 2 villagers change with log outs and log ins, and how killing that "bugged" villager will make the order return to a stable state, making the first villager be the first permanently (if you don't add more villagers that could get "bugged" the same way).
-After testing myself and receiving reports/videos from people suffering from this problem while building my iron farm design, it's clear that the order scramble chance is different depending in which platform they are playing in.
https://youtu.be/go4ySjnZKU8
Can Confirm
in 1.20.51 the hierarchy (heirs to the leader and the leader) switches to the new villagers when more villagers are added to the village via breeding. Will do more testing soon.
Edit.
even if the leader can sleep in its bed, the leader position can be assigned to newly created villages breading or spawning.
Have a free roam village with vanilla buildings intact, save for some terraforming for easier pathfinding.
Whenever the Villagers have a town meeting, storm cloud particles are emitted constantly around the bell hanging beneath the well roof. The Villager(s) in question doesn't matter because it shifts every time.
I did some testing on this and here are some takeaways.
1. When new villagers are added to the village, they may be placed in any random location in the hierarchy order. They could become the new leader, the tail, or somewhere in-between. This confirms Pekoneko117's findings. Although Pekoneko117 stated that the entire order is scrambled, more specifically the new villager can be inserted at the beginning, end, or somewhere in the middle of the order. But the previous order remains intact excepting the new insertion.
2. When every bed in the village breaks, the order completely scrambles. This kind of makes sense given that a village is only formed with the first bed.
3. As of 1.20.72, on Nintendo Switch, every time the user logs in and out, the villager hierarchy order reverses. If the villagers were initially in the order 1, 2, 3, 4, upon logging out and back in the order will be 4, 3, 2, 1. However, if you login and out and then in and out again the order is back to it's original. This appears to confirm Reed Cartwright's code observation that "On Android, the implementation of std::unordered_map tends to reverse the order of villagers between saving and loading data to NBT." This reversal problem does not exist on the Windows PC Bedrock version as of 1.20.72.
4. The villager hierarchy theory appears to be true as of 1.20.72 on Nintendo Switch and Windows PC. You can tell the hierarchy order by breaking all the workstations, and placing them down again. The order in which the villagers claim them is the order of their hierarchy. I used Universal Minecraft Tool to verify that the village origin/center point follows the villager hierarchy order and their POI.
The take away problem is that the village origin is unpredictable due to the hierarchy order changing too easily. The solution should include a somewhat easy or at least consistent way to determine the village center so Iron Farms can work reliably. Added villagers should come at the end of the hierarchy order, not somewhere in the middle or beginning.
Workaround:
One potential work around is to expand the village by placing 4 workstations on the outskirts. That is, keep the beds inside the village boundaries and add workstations in the expansion range of the village. Since beds are prioritized as origin points and workstations can expand the village boundaries but won't act as an origin point if there are beds for every villager you can expand the village so the center becomes the geometric center of the village boundaries, allowing you to control where iron golems spawn. This can be done in any natural village meeting the requirements for iron golem spawning.
Steps to Reproduce:
Using Nintendo Switch Bedrock Edition 1.20.72:
1. Create 4 side-by-side fenced areas large enough to fit a bed, workstation and villager.
2. In the first fenced area, place a villager and then a bed. After he links to the bed, repeat the process for the next fenced area until all 4 fenced areas are accounted for.
3. Place down a workstation (can be the same type or different) in each fenced area, waiting for each to be claimed at a time, and take note of the order in which villagers claim them.
4. Break all the workstations and repeat step 3, one more time, noting that the order the stations are claimed in is consistent with the previous time.
5. Break all the workstations, beds, and kill all the villagers.
6. Repeat steps 2-5 a few times until you notice the order does not match the spawn order or claiming beds order.
7. Log out and then back in, delete all the workstations and place them down again one at a time after each villager links, note the order they are claimed in.
8. Repeat step 7.
Observed Results:
1. The villagers may not claim the workstations in the order the villagers were spawned in or each claimed beds in but in each cycle of steps 2-5 you'll notice the order changes. However, if you erase the workstations only and place them down again, the villagers maintain that order.
2. Upon the 7th and 8th steps, the order that villagers claim workstations is reversed both times.
Expected Results:
1. The first villager that claimed a bed should be the first villager to claim a workstation. The second villager that claimed a bed should be the second villager to claim a workstation and so on.
2. Logging in and out should not reverse the order that villagers claim workstations.