Villager leader/center changes every time you log in and out

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:

Steps to Reproduce:
1.
2.
3.

Observed Results:

Expected Results:

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:

1. Make a village of sufficient size. (Possibly 5 or 13 villagers? See findings below.)

2. Place a bell in the center.

3. Save & quit.

4. Check the order of villagers in dwellers and POI lists, and village coordinates.

5. Reload the world.

6. Repeat step 3-6 several times.

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:

It looks like this:

• This screenshot was taken just after the iron golem spawned.

• This screenshot was also taken just after green sparkles appeared over 3 of the villagers and the bell. Each of these villagers also has an emerald block in its cell to mark it.

• The same 3 villagers and the bell together go back and forth between angry particles followed by sparkles several times each day during the afternoon meeting time.

• During the times following green sparkles and all the rest of the day cycle, the village center is the bed in the upper marked cell. You can see that cats have spawned around it.

• During the times following the angry particles, the village center is the bed in the lower marked cell.

• The original center of the village is the bed in the middle marked cell. This cell contains the 1st villager and bed that created the village.

• The upper and lower marked cells contain the 5th and 13th villagers and beds of the 16 villagers and 24 beds in the village.

• Relogging almost always changes the order of the 3 marked villagers in the dwellers & POI lists, but the top 3 always remain the top 3.

• Whenever I checked the village data right after green or angry particles, the top villager in the dwellers & POI list would correspond to the village center.

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