Villagers crowd into a single building
Villagers are not using houses made for them. They are staing in 2 or 3 houses ( of aprx. 150)
You can see on a pic, how they behave
What I suggest to do:
- make an array of doors in village
- make an array of villagers
- order every villager in villagers array to choose one door from doors array
For example, there are 10 villagers (1,2,3 ...9, 10) and 10 doors in the village (A, B, C);
Then each villager have to use 1 door, for example:
1 villager - A door
2 villager - B door
...
10 villager - J door
So, if the house contains 5 doors, there will be 5 villagers
I think, it's realy easy to realize, and I didn't get, why you haven't made this yet.
Thanks for attention.
Linked Issues
is cloned by1
is duplicated by7
MC-12677Villagers all go into 1 houseDuplicateMC-16708villagers stuffing into the same doorDuplicateMC-37114All villagers goes in the same houseDuplicateMC-38479problem with of villagersDuplicateMC-42081Villagers just go in 1houseDuplicateMC-50663Villagers in my game always cram themselves into one house.DuplicateMC-3079Village size is too smallDuplicaterelates to6
MC-10841Villages are persisted to NBT, yet still destroyed/recreated on chunk reloadAwaiting ResponseMC-3944Villagers in Minecraft, when given a roughly 5x5-10x10 area, will arbitrarily pack up in the north-west cornerDuplicateMC-10782Villagers slam doors when trying to enter housesIncompleteMC-17247Villagers running all the timeFixedMC-38040Weird villagers' behaviourAwaiting ResponseMC-4662Iron golems spawned in a village walk around 1 placeIncompleteAttachments12
Created Issue:
Villagers AI complain
Villagers are not using houses made for them. They are staing in 2 or 3 houses ( of aprx. 150)
You can see on a pic, how they behaveWhat I suggest to do:
- make an array of doors in village
- make an array of villagers
- order every villager in this array to choose one door from doors array
For example, there are 10 villagers (1,2,3 ...9, 10) and 10 doors in the village (A, B, C);
Then each villager have to use 1 door, for example:
1 villager - A door
2 villager - B door
...
10 villager - J doorSo, if the house contains 5 doors, there will be 5 villagers
I think, it's realy easy to realize, and I didn't get, why you haven't made this yet.
Thanks for attention.
PS. I <3 minecraft, and I want it to be perfect game.
Attachments1
- Unresolved
- Open
- Public
- Unconfirmed
- AI doors mobs ridiculous village
- 1.4.2
VillagersAI complainVillagers crowd into a single building
![[Mod] CubeTheThird](../../../data/assets/gravatar/cubethethird.jpeg){kind=small}
relates to
relates to
is duplicated by
relates to
is duplicated by
relates to
is duplicated by
relates to
![[Mod] Ezekiel (ezfe)](../../../data/assets/gravatar/ezekielelin.jpeg){kind=small}
Villagers are not using houses made for them. They are staing in 2 or 3 houses ( of aprx. 150)
You can see on a pic, how they behaveWhat I suggest to do:
- make an array of doors in village
- make an array of villagers
- order every villager in
this array to choose one door from doors arrayFor example, there are 10 villagers (1,2,3 ...9, 10) and 10 doors in the village (A, B, C);
Then each villager have to use 1 door, for example:
1 villager - A door
2 villager - B door
...
10 villager - J doorSo, if the house contains 5 doors, there will be 5 villagers
I think, it's realy easy to realize, and I didn't get, why you haven't made this yet.
Thanks for attention.
PS. I <3 minecraft, and I want it to be perfect game.Villagers are not using houses made for them. They are staing in 2 or 3 houses ( of aprx. 150)
You can see on a pic, how they behaveWhat I suggest to do:
- make an array of doors in village
- make an array of villagers
- order every villager in villagers array to choose one door from doors array
For example, there are 10 villagers (1,2,3 ...9, 10) and 10 doors in the village (A, B, C);
Then each villager have to use 1 door, for example:
1 villager - A door
2 villager - B door
...
10 villager - J doorSo, if the house contains 5 doors, there will be 5 villagers
I think, it's realy easy to realize, and I didn't get, why you haven't made this yet.
Thanks for attention.
PS. I <3 minecraft, and I want it to be perfect game.
Villagers are not using houses made for them. They are staing in 2 or 3 houses ( of aprx. 150)
You can see on a pic, how they behaveWhat I suggest to do:
- make an array of doors in village
- make an array of villagers
- order every villager in villagers array to choose one door from doors array
For example, there are 10 villagers (1,2,3 ...9, 10) and 10 doors in the village (A, B, C);
Then each villager have to use 1 door, for example:
1 villager - A door
2 villager - B door
...
10 villager - J doorSo, if the house contains 5 doors, there will be 5 villagers
I think, it's realy easy to realize, and I didn't get, why you haven't made this yet.
Thanks for attention.
PS. I <3 minecraft, and I want it to be perfect game.Villagers are not using houses made for them. They are staing in 2 or 3 houses ( of aprx. 150)
You can see on a pic, how they behaveWhat I suggest to do:
- make an array of doors in village
- make an array of villagers
- order every villager in villagers array to choose one door from doors array
For example, there are 10 villagers (1,2,3 ...9, 10) and 10 doors in the village (A, B, C);
Then each villager have to use 1 door, for example:
1 villager - A door
2 villager - B door
...
10 villager - J doorSo, if the house contains 5 doors, there will be 5 villagers
I think, it's realy easy to realize, and I didn't get, why you haven't made this yet.
Thanks for attention.
is duplicated by
is duplicated by
relates to
is duplicated by
2014-01-13_16.14.15.png
relates to
is duplicated by
latest snapshot, bug is still present
is cloned by
![[Mojang] Adrian Östergård](../../../data/assets/gravatar/nighter.jpeg){kind=small}
i agree.
![[Bot] Arisa](../../../data/avatars/users/43007.png){kind=small}
is cloned by
is cloned by
Likely relates to MC-78.
Related to (or caused by) MC-78.
The reason for this issue is the effect of the bad villager AI. The villagers define their village (or more correctly, find the doors and then decide to ignore the more distant ones), and golems just use that result. If the village/villagers issue gets fixed, the golems should roam equally better, although golems do have the same "villager radius * 0.6" problem in their code as villagers do.
Can confirm (by observing some added console logging for each door/village addition/removal activity).
Additionally, during loading the world, the doors and the village under testing was removed twice, yet no signs of adding them back. Yet, the village is there (as if there was still a third entry that was kept). Something weird, though not dangerous in that.
Also, related to MC-78.
Any changes to this have lots to do with MC-78, (and its related issues), as the village behavior depends strongly on the doors.
Note that simply keeping the door knowledge of a village even when the containing chunks get unloaded (as suggested in the description) may have some undesired effects unless compensated in other related code. For example, if doors are not dropped, the village center and radius stay the same. Then villagers would, over the day, move randomly over the full the village area. Once they decide to move to a spot that is unloaded, they get "stuck" there. This may lead to "pushing" the villagers (and golems) to one side of the village, with its possible side-effects, like dropping (temporarily) the doors on the nearer side of the village. (And that was just one example that came to my mind).
EDIT:
Apparently, if one moves far enough to get the village removed by chunk unloading, it will still survive in the saved data (but only for some special case). When the world is loaded again (while being as far away), the doors and village gets either removed twice, but its data is still there (as it will not be "found" again while approaching it), or it and its doors get scanned through and village created, with its chunks still supposedly unloaded (i.e. it will have to load the needed far away chunks just to check for the doors).
This behavior only goes for one village, the one that was near when the world was created. There are two other villages I've visited, but they seem to behave more or less as expected.
Caveat: There are probably some code paths I've not just spotted which explain some of these mysteries, and I'm testing this the only way possible, i.e. using the MCP decompiled version, which may change some things.
This is related or probably even caused by the same reason as MC-78 (i.e. the mechanism by which the village is defined), so as long as that is still unresolved, this should be considered to be unresolved, too (unless specifically otherwise informed by Mojang). Yet, even if MC-78 gets resolved, there is still a chance that this needs an additional change, too; depends on the details of how golems check their movement area.
I'll try and check it in the code tomorrow (Edit: erm, later today); helps in confirming the issue's presence, as experimental testing of the golem movement area is s l o w 
That was actually easier than expected...
Villagers and iron golems share the "wandering" AI, so for that part it is exactly as I thought; both villagers and golems need some minor touches in addition to fixing the overall way the villagers and villages interact to define the village shape and size (the "houses" or doors).
Iron golems have an additional AI routine for going from door to door (shared with zombies). That one might work ok without changes, although seems it might have a minor "issue" if the village has less than 16 doors. (But that would be another bug report, and I'm not bothering until MC-78 gets fixed.)
I think this counts as a duplicate for MC-78.
First one is dupe of MC-78, second one please provide full output of the development console.
Duplicate of Unresolved
MC-78
If you have not, please use the search function in the future, to see if your bug has already been submitted. If you could not find the original report, please comment with the keywords you searched for.
i thing this bug is the same with MC-78
yes Dan Keller this happen at savanna and desert
I've noticed this too.
I also agree. I have a village with 66 houses and they all try to cram into one. Eventually I worked around this by adding tunnels from house to house for 'overflow'. Also adding ladders to the roof with fence around it.
Wouldn't it be a bit better if houses are the arrays, instead of the doors, and the space in the houses determining how many villagers can be in them? This way you will have "families" so as to say, instead of a-social villagers
I just want them to have sounds, longer pregnancies, and to hold hoes and farm realisticly.
Logically, there can be more than 1 villager in a house, like how there are families in a real life house. I think an alternative way is to limit the max number of villager in a house, so that they dont over flow. This will possibly disable the infinite breeding, which I think is considered cheating.
I solved this problem short term simply by destroying doors from most popular apartment (my world has few large apartments with many rooms for villagers) and villagers randomly selected rooms afterwards. After I put doors back on, 1/4 of them went there again. In least room is usable for them now.
My villagers don't go in their houses anymore.
There is a bug with the AI, on reddit an user (ninti) described the bug in detail.
http://www.reddit.com/r/Minecraft/comments/12aist/suggestion_why_dont_villagers_use_valid_beds/c6tn2hs
So, that means now guys from mojang have to fix it because this bug really old and annoying
The behavior of villagers in terms of wandering or failing to wander is definitely erratic and unbalanced. I've seen the same "crowding into a single building" though it was in a previous version (a whole mob had jammed themselves into a "church" and many of them kept leaping off the top to their deaths).
In 1.4.2 I had built a large number of new houses and no villager would "discover" the new doors (over many many days) and therefore would not breed. It completely looked like part of the same village, but I think the problem was that the houses on the street leading to the new street of houses had doors too far apart. They were large houses (either generated naturally, or copies of houses that were generated naturally) and the distance between the doors was perhaps 15 or 20 blocks, and the villagers simply never wandered far enough to find them. Though I swear I've seen villagers wander quite a long ways out into a field. I ended up moving these houses closer and putting in a new house between them and the new street and that was enough for the villagers to discover the new houses and set off the baby boom I was looking for.
It seems to me that the "wandering" algorithm could use adjusting. Perhaps this behavior should take into account crowding (moving away from clusters of people when they get too dense), as well as roads (there should be a certain amount of bias toward following a road rather than wandering across grass).
I can't wait untill Jonkagstrom returns to minecraft from scrolls to work on the AI again. Untill that moment I guess we just have to wait
What if the number of villagers per house (at night time) was proportionate to the size of the house? For example, the small 2x3 (inside) huts could have 1-2 villagers and the large T-shaped one could have a dozen or so. Of course the total number of villagers would still be regulated by the number of doors in the village.
This is very annoying indeed, they also seem to move within one very specific area, kind of like Eric mentioned above.
When I use a spawn egg to create a new Villager on the Est side of the village, he/she instantly runs to the West side, where all the 20 are using five houses, at maximum.
Someone else here from BdoubleO?
Anyway, I can confirm this. I have a natural village (not even made by me) and they just stay in the 3 middle houses.
I can confirm this, but IMHO it isn't that bad, sometimes it looks sweet how they gather together and form a community. there are worse bugs
Well, it can be bad if you're trying to grow your village, get golems, etc. And it's quite hit or miss (maybe depending on the way the building happen to generate?)...in some villages they cluster quite badly but in others you hardly notice it.
yeah villager AI is a peice of crap atm i don't understand wy they dont fix it rather than adding more problems :/
I can confirm this. I have 3 small villages and it happens in all of them. Please, fix this. I do not think it is a hard problem to fix and, besides, it is one of the most popular issues.
Here are some screenshots.
<EDIT: Uploaded screenshots properly>
Gustavo, it is recommended that you attach screenshots directly here.
The reddit link Sid Ben provided seemed to have somewhat nice description about a few possible/likely reasons (i.e. bugs or design flaws) behind this issue.
However, those are not the only reasons that affect the problem. The Villager's have a "home village" (or at least they usually have one), and they set their "home area" to that village's radius... times 0.6! That village radius is defined by the valid door (house) furthest from the center. And their movement AI wants them to stay about in that home area, instead of the full village radius. So, in a large city, the villagers that have somehow gotten to the perimeter area have a tendency to come back towards center, and thus not only possibly loosing sight of the furthest doors (at least temporarily), but also bringing villagers closer together. Being closer together means many of the villagers will concentrate on the houses closer to center.
I did not test the assumption above (based on reading source code), as getting proper facts on the village center, radius, each NPC's AI states etc. etc. is a bit difficult without proper debugging setup (e.g. overlaying some visible markers in the view of the world). (Which I'm sure Mojang has available in their development version.)
Gustavo, AI problems can often be hard problems to fix, especially when designed in the way they are in Minecraft; multiple partially independent "goals". One "fix" could easily affect few other goals, breaking them or make them behave otherwise in unintended ways. But I don't mean this issue should not be looked at, and the details given by players already give a lot of help.
please Jon we need you back!
everybody go beg https://twitter.com/jonkagstrom
to return to minecraft!
MisterSanderson, sorry about that. (I had not seen the attachment option in the comment window, so I just put it at my Dropbox.)
Markku, I had a simple vision of the solution, like the ones posted by the OP and Sid Ben. I know almost nothing about source codes, so I assume you must know a thousand times more than me and, well, probably you're right. Still, I'm looking very forward to this fix, despite its complexity.
About that "radius times 0.6" formula, if I make an artificial village, can I deliberately choose the radius? Is there a maximum radius?
The "0.6x radius" factor, as the way the radius is defined, are both hardcoded, and can not be affected. There seems to be no maximum radius (took a quick look only), but at least I'd say it can become a challenge to play with the villagers to spread further when the other ends starts to get unloaded
What can be (partially) affected is how the radius changes over time. It is defined by the valid active doors, which in turn are noticed by the villagers. So build houses to spread the village around, and once a villager is even temporarily in a perimeter house you want to "keep", block the villager inside. Repeat in all directions. Adjust the area between as desired. The blocked villagers will keep the village radius large enough to always include all those - depending where the center of village moves, the radius may still extend at other sides to beyond those blocked houses.
Village center in turn is based on the "center of mass" of the (active/valid) doors (of houses). So a bit of math or even decent ability to estimate that can give a good hint how the village is in the minds of the villagers.
Yes, I've built a huge village with lots of nice houses but they only stay in one little area. I've lost all interest into finishing the village.
I just creating 3 (properly spaced) villages. In each village only one house was used (2 houses were sometimes used in the largest 23 house village). Suddenly all villagers from all three villages mobbed two houses in one village. My entire set up was ruined. I hope they fix this soon. I think the best choice would be to permanently be assign a villager to a door, and one villager per door. If there are too few doors, an unassigned villager should stay with a neighbor but continuously search for a new door. Potentially, this may make an untouched natural village look more realistic as well. The blacksmith would stay at the forge and priest would stay in the church, ect.
After trying multiple different changes in the code, I couldn't get it even near "good", but at least I managed to make the villagers spread more evenly around the village, and somewhat in the houses, too. There could still occasionally be 3-5 villagers in the same house, but with around 15 villagers, at least 5-8 houses were occupied each night. So, an improvement, but not fully fixed.
Also, if a house has more than one door, the house has a higher chance to get crowding, even with the changes. The other door(s) lure the villagers out away from the door they are supposed to restrict.
The biggest problem to solve this issue somewhat easily is the door restriction operation. Basically, it does not work. There is no point in trying to work out a well working algorithm that takes occupation into account when that occupation data is mostly useless.
The changes
1) Changed the villagers' "home area" to be based on the bounding box of village's doors (instead of mass center). This matches better the needed area of movement, though the current way has the minor benefit of bringing the villagers slightly closer together during daytime - sort of looks like "community behaviour".
2) Increased the radius factor from 0.6 to 0.9. The 0.6 for the current mass center -based solution does make sense as the most distant door from that mass center can indeed be quite far away, and larger factor could allow villagers to wander quite far "out" in the opposite direction. Unfortunately, that will also limit their chances to move to that distant house that is in the village. With bounding box center -based "home area", the radius can be higher without that problem.
3) Changed the way villagers choose which door they'd like to go to. In current code the distance is given unnecessarily large disadvantage weight (squared and in addition anything beyond 16 blocks was given an extra about x30 distance which in practice means fully ignored), and when near enough, it has no effect at all. I changed the distance weight to linear, multiplied by just 4, and added the restriction value (for whatever rare effect it has). Also, I made it keep 3 best choices and pick randomly one of them in the end. The randomness tries to diminish the effects of the remaining badly working things.
4) Removed any extra doors from multi-door houses. Not a nice change, and not absolutely needed.
1 and 2 together spread the villagers quite nicely around the village. This already decreased the crowding effect a lot, but local hotspots would still be a problem.
3 and 4 reduce the local hotspots a bit. Not that well, but at least better than the current code.
What would still be needed
The above changes are merely a minor fine-tuning to reduce the worst of the issue.
Full fix would require quite a total rethinking/design for the way a door or house is marked occupied. To me, it seems that it would be best to simply bind each villager to a single door. Easy when generating the village (the code can just bind the generated villager to the house/door it was generated for). When spawning a new villager or when a door gets invalid/destroyed, there would need to be new code that looks for least bound doors and picks one of those, to spread the villagers evenly.
Then, when villager wants to get inside, it would prefer its "home door" unless it is really far away (like more than 50 blocks away?), in which case it could just pick a random valid door nearby for that night.
And also: related to
MC-4662.A better way might be to let villagers map out the buildings themselves (perhaps rejecting pathological buildings such as http://www.minecraftwiki.net/wiki/File:Bare_Minimum_House.png and http://www.minecraftwiki.net/wiki/File:Minimum_House.png ), and then attach themselves to particular houses. They would also remember how crowded they were (villagers/inside area) in the old building. If they find themselves in an overly crowded building overnight (check at midnight?), they might take a 1/(N+1) chance of rejecting their current home altogether, after which they would later pick a different building.
For performance reasons, you'd probably want a "house-hunting mode" that they would only invoke occasionally – for example, when they find a new door (or any door, if they're currently homeless), or if their prior house has been too badly damaged. Naturally, they could also share info about how many villagers have already chosen a given house. If you want to be nice to the players, you could tweak the overnight check to make a player count as 3 or so villagers for crowding purposes. (That is, if the player moves into a building, villagers give them room.)
Detecting when a player (or anything else) is in a house is quite a difficult task. In fact, figuring out what really makes a house and what is its inside or outside is very complex task to start with. That is why the current mechanism is so simple, and concentrates its minor effort on doors.
The attachment of a villager to a door ("house") is something I already mentioned above, as was the knowledge about how many villagers would be in each house, and to look for new one if old door becomes "invalid". (Check the last part for those; the rest of the text is for just the quick-and-dirty remedy that could keeps us player somewhat happy while implementing bigger and better changes.)
What I'm suggesting here is that the movements of the villagers could themselves be used to figure out what a house is, along the lines of "after passing through a door, wander around a bit, keeping track of where I've stepped. If I find myself under open sky without passing through another (or the same) door, this isn't a (very good) house. If I pass through another door, I expect to be under open sky within a few blocks – if not, I might still be in a house".
@David Harmon
The villager does not have to move in order to do that process; it is enough to move a variable and keep checking blocks wherever it goes. The benefit from this is the need for less memory (to remember all the places having been visited) for long periods; instead, it is enough to hold it for a shorter period. Like the duration of running a single method.
Now, whether it is the villager or an abstract pointer, it will still be an algorithm that tries to figure out what makes a house. And while it first sounds easy, there are plenty of traps to fall in. Just as one example to the algorithm you gave; what if the "house" has one nice door, very nice two block high walls, ceiling at 4 blocks higher. Nice. But then ground outside has a place for monsters to climb up those two blocks and they can slip in. Not very good house after all. There are more similar oopsies...
As I said, detecting/figuring out a good house is a difficult task (for a computer/program).
And the biggest problem for this issue is not the detection of houses (or doors), but how the villagers end up getting crowded into one to few of the available houses (doors). Even if the CPU is put to its knees to be smart about what makes a house, without fixes to the real problem here, they'd just crowd in one to few nice houses. (The house detection should be another issue, or more likely, moderators will judge it to be a feature request.)
Also, even detecting how many villagers are (or will be soon) in a single house is a challenge. That is the main thing currently bugging out badly. And due to it being so difficult problem to solve, I proposed the binding of a villager to a "home" house, and using that as the primary house choice; no need to worry about counting how many are in a house, as it is easy to distribute the villagers to houses at that level (the valid doors (i.e. houses) of the village are known well).
Please don't alter the "what is a house" detection mechanism, that would be a significant breaking change, and lots of village/iron golem farm designs would no longer work.
One question to help clarify this issue for me: in your "choose a door to enter tonight" code, do you have global knowledge of all the other door choices that have already been made by other villagers? If so, then you can just restrict door choice to the closest door that hasn't been chosen by any other villager (or by the least number of villagers, if villagers>doors).
Or does each villager only have "knowledge" of what they can determine from the world?
Even in that case, you could add a "villager count" attribute to your village door object, that would get cleared in the morning, and would increment every time a villager selected it at evening time.
Hope that makes some sense. Still sounds like your revision is an improvement on the current.
Villagers currently do not have "this is my door" knowledge; it is all based on what they happen to "see" at each time. They do already try to restrict a nearby door in certain situation, but that functionality is not working well (the main problem for this issue). I.e. the value you call "villager count" is actually much more weirder value and isn't working as expected/desired.
Currently, villagers do know their village, and the village does know every valid door found by all the villagers.
What I suggested was basically adding the knowledge of one door to each villager - its "home door". It doesn't matter much whether it is for this night or a bit more permanent choice, but the latter choice would give a bit more realistic behaviour (getting back to own home each night), and would need less computation at night fall (since the knowledge is already there).
It is indeed trivial to spread the villagers quite evenly over the doors of the village even with the existing data. The problem is the missing data explained above, whichever way it is then used.
It's true. In a previous world that I had, when rain or night came, i would often get up to 50 villagers in the one house, while all the others would be empty.
Markku: <i>Not very good house after all. </i>
The example you gave sounds like an error or backstab by the player building it, and it's not reasonable to expect villagers to outsmart the players.
I'd say the villagers could settle for a door leading to an enclosed space with no open sky, and no holes in the wall over 1 block high) that lead to outside (windows and doors don't count as holes). (Note that this would also rule out your example.) (If the player wants to let spiders in, whatever – they don't attack villagers anyway.) If you want to be fancy, you could have any villager who finds a non-zombie monster indoors, declare the house unfit. (Zombies, of course, can spawn inside houses – just one more problems with the current overcrowding situation.)
The hard part would be keeping track of bounding boxes for the village's houses, especially if there are tunnels involved.
David, it was just one example, to show you that naive algorithms simply fail. But we're getting kinda offtopic here. This issue is about villagers crowding, not about how they detect houses. So, I'll make a feature request about this on the forums, lets continue there. Here's the forum thread:
http://www.minecraftforum.net/topic/1690912-villagers-should-be-smarter-about-what-makes-a-house/
Will the repairs that have been made so far (The repairs listed since the 7th of February)be available in the 1.5 update or the snapshots leading up to it? By the way, we all really appreciate the work you guys do!
Those "repairs" are just comments about how I modified my own "test platform" Minecraft and what effects they had. As far as I know, Mojang hasn't even seen them yet, let alone included in a snapshot.
Oh . . . well I feel kinda dumb. Well in any case I how Mojang has the time to look into this bug soon. I'm starting to get apathetic about village building. . .
I've noticed this in 1.4.7. I've made a huge village and they all crowd into the same 3 houses in the far north/west corner of the village.
My suggestion for changing this in villagers... we know that village population is tied to the number of wooden doors in a village, so that must mean that all doors are counted or indexed in some fashion. Each villager should be given an attribute that is a 'favorite' door he prefers to walk towards when idle, hiding from the dark, or when running from zombies. This favorite door should be a door that is not another villager's favorite, if possible.
There are usually more villagers than doors, but perhaps each door should be given a number or ID, and each villager that spawns should be given the door ID, in order. This means that if there are 5 doors, for example, the first villager gets, door A, the second gets door B, and so on, until the sixth gets door A again. This means that each house should have an even number of villagers.
Lleyton J, if you read my comment earlier, the last part of it under "What would still be needed", it is explaining the same you did, although without example. Just "least bound door". Note, the doors do not need numeric ids for that. The currently existing list of door is enough, but the door info needs to be added a counter (or repurpose the current restriction counter which isn't working well).
Sorry Markku.
Its okay. Even if redundant comment, it still confirms that the idea is obviously a decent and acceptable one as others get the same idea. Might convince Mojang to go for it.
You're right. Hopefully it might just convince mojang to really deal with the issue.
Can someone please add 13w07a to the version list？ It still happens there.
Easy fix, been using this one for a while, as have others.
in EntityVillager
find:
ChunkCoordinates var1 = this.villageObj.getCenter();
Villagers cluster around center of village
replace with:
VillageDoorInfo var1 = this.villageObj.findNearestDoorUnrestricted(MathHelper.floor_double(this.posX), MathHelper.floor_double(this.posY), MathHelper.floor_double(this.posZ));
Villagers go to last door they encountered.
Paul Aslin: That is not a fix, but a kludge that makes the current mess even messier, just with apparently useful side-effects. Also it won't make them to go the 'last' door they encountered (though it often may be that door, by chance). The problem is, as soon as someone wants to actually improve something with the villages / villagers, that change will bite back.
Basically, that change only breaks the notion of villages having a center and villagers basing their common lives around that. Thus, the villagers would think each of having different "home" area and unable to move far enough to completely discard some parts of the village (the useful side-effect).
Without testing (have to delay that to tomorrow), I'd guess that change would allow some villagers having "home" at the edge of a large village to be able to move quite far away from that village, possibly far enough to "lose" that home village.
That change is certainly good enough as, say, a mod that allows temporary improvement until the issue gets properly fixed by Mojang.
The general idea in bug fixing is to make code to work more correctly, not to make it work even less correctly, even if such change seems to have some beneficial spot effects. I've already given several fixes that actually improve the sub-tasks involved, but even those are not enough to fully overcome the real bug causing the crowding. One straight forward solution for that main issue is also known, but needs large enough changes for me to keep away from it; it is not difficult one, but needs to change the saved data and becomes too large to be posted here.
Can we get a confirmation of whether this happens in 13w10a and an update to the affected versions?
Updated
I hope this annoying bug gets more attention from Mojang for the upcoming 1.6 update. Currently I have to trap some of the villagers inside buildings in all corners of my village. If I don't do that they just forget most of the available doors and instead crowd in one corner of the village.
My village has 80 doors, 35 villagers and 4 golems.
This bug is super annoying and makes it pointless to bother interacting with villages. Why is still not even assigned while all kinds of trivial bugs are being fixed with every update? I /had/ been building an empire of villages across an entire continent, so it's not even worth playing until this is resolved.
Of course as soon as I post the above comment they announce they've been secretly working on 2.0
No wonder this wasn't a priority. We only get frustrated because we love you Mojang.
^ Minecraft 2.0 is an April Fools' joke…
Alex, that's a mean April Fool's joke . . .
Alex didn't make the joke, he mistakenly thought the 2.0 joke by Mojang was a real announcement.
This is still a bug, it still should be worked on, it's still not being worked on, and we still don't know why. But we do know that "Minecraft 2.0" is not the reason.
This has been happening for a year and they still haven't gotten around fixing it... I pretty much revolve the game around making many villages and soon turning it into a metropolis, but I can't do that with so many empty houses and 50 villagers cramming into the same dang house!
Awww that's so mean! Now I"m back to being pissed about this bug - I didn't even know it had been going on for a year. WTF Mojang. Ridiculous!
This is confirmed with 1.5.1.
I have this problem all of the time.... it makes it very hard to trade with them and you cannot get to most of them.
It gets so bad, that the villagers glitch out, suffocate, and appear to "float" out of the building.
This is in fact getting terribly annoying. We built over 40 structures (in the style of the originals) at a large npc village. 95% of the villagers cram into one 3x3 building every single night. They're worthless for trading and it takes 15m in the morning for the concentration levels to get low enough that you can efficiently trade and any of the further out buildings never get filled or have villagers near them. Even though they're only 30-40 blocks away. Really really annoying.
Completely random buildings would be better than this.
85% of the village i built is a ghost town, meanwhile the other 15% is overflowing with villagers.
Oh good, it's not just me.
They all insist on cramming into the tiniest building in the village; not a single villager in a different house.
I can force them to leave, but they always head to the same next house. They also have a bad habit of standing in front of the door to block other villagers from entering.
I got this all the time. I have like a 50 to 60 house village and 70% is abandoned
while 20% is overcrowded. This bug only seems to happen occasionally but it happens every time it rains.
In my villages, I always plan a trap (usually a 2x2 hole in the ground) in the north-west house, with an underground river pushing the villagers to the south-east corner, where they can escape. They still don't pay too much attention to the other houses, but at least I can see them running across the village, heading back for the north-west corner
I'm having the same issue. My villagers are all crammed in one house, I can just sit there around the corner and kill zombies all night in one spot without moving. So many villagers and they just go to the same place to kill them. Camping at its best.
Suggestion: villagers should be programmed with a kind of "wanderlust," if there are too many villagers in their immediate vicinity, that prompts them to wander in a random direction for a while, checking occasionally to see if there are doors nearby. If they find themselves in a place with many doors and few other villagers, they'll get the urge to settle down in the new location.
@Kevin: They already do all that. Well, not the "if there are too many villagers in their immediate vicinity", as they have that near-area wanderlust to kick in simply randomly. That part of their coding works somewhat well. It could work a bit better (as indicated by my earlier tests), but their wandering is working good enough to not be the real cause for this issue.
Oh, and they do not "settle" at all. No villager has any kind of "home". Having a home has been suggested as one way to fix this problem, and yes, it would fix things. However, it has its own problems to be solved, so it is not a trivial fix.
I have provided some tested changes in earlier comment. They do not fully fix this problem, but they can be done without major changes to the code, and reduce the crowding enough to not be as big an issue as it is now.
I hope this really annoying bug gets more attention from Mojang for the upcoming 1.7 update. Currently I have to trap some of the villagers inside buildings in all corners of my village. If I don't do that they just forget most of the available doors and instead crowd in one corner of the village.
My village still has about 80 doors, 35 villagers and 4 golems but i somewhat lost interest in them because of this bug.
@David Harmon: If you want to be nice to the players, you could tweak the overnight check to make a player count as 3 or so villagers for crowding purposes. (That is, if the player moves into a building, villagers give them room.)
That would not always be nice. When trying to trade with villagers, seeing most of them suddenly escape the house you just entered would be bad.
The entire way villages are defined is kind of sucky. 1 door = 1 housing space is very limiting.
Houses with lots of doors yet an obviously lower "habitability" can't work weel. For example, if a player makes each room inside a big mansion house not only have it's own set of doubledoors plus doors for each closets too, obviously this would at last triple the housing" value of the house for no good reason. Sure it should have more villagers after all it's a mansion, but it should not have THAT many villagers in it. Even if the masion'.s rooms where without closests and single doors, the "rooms per occupant" of luxury houses is instinctively not the same as for slum housing. In the same way, a storage shed with lots of cubicles, made for decoration, should not suddenly automtically become a house for lots of villagers in it. Or a house that the player uses as his "own"' yet doesn't want to be constantly annoyed by "impromptu visitors". And not all wooden doors player places in his own base should not also automaticaly count as potential village doors.
In short, wooden doors, while an imporant aspect of villager navigation, should not be what defines the housing unit criterion itself. Something else that is not a door is needed, and a way to differentiate "housing" doors from "normal" doors too. But it is just the simplest way right now.
Also, in the case of super long villages or villages with weird shapes say, an L shaped village, using the center mass makes villagers wander, on those sides without houses, quite farther away than normal (when counting the nearest housesdistance, not the village center) to unsafe spots. Also, several nearby villages tend to create funky village dynamics where villagers can just suddenlty abandon one village forever, cramming into the next village.
Instead of a single village of varying boundary, maybe have a "village rating" in the section? (not a chunk because chunks are 256 blocks high = 16 sections that are 16x16x16) is determined. Then villagers just occupy those sections, so that a village of any weird shape or size will, because of villager semi-random travels, eventually be filled more or less evenly. You could build a huge city that way.
Any way, each villager should definitely have "his" house and stick to it as much as possible during the night. Currently finding a specific villager for trading is a real nightmare except in the tiniest of villages. It would look cooler to see villagers sleep in the house they spawned in (librarian in the library, etc.)
But just making the villagers stop crowding all in the same spot would already be a boon.
@Patrick:
"If you want to be nice to the players, you could tweak the overnight check to make a player count as 3 or so villagers for crowding purposes. (That is, if the player moves into a building, villagers give them room.)"
The biggest reason why this issue exists at all is mostly because that counting mechanism is not working. So, your idea would not work, unless the counting mechanism works, and if it works, your idea is not really needed.
About deciding what makes a house; there is a thread about that on forums (the supposedly correct place for put ideas/features in). Me and David we're getting off-topic (about what makes a house) in a lengthy way, so I made this http://www.minecraftforum.net/topic/1690912-villagers-should-be-smarter-about-what-makes-a-house/
About village shape: better matching of internal and visual village shapes would be good. Coding complexities affect, but one of the changes I listed earlier would help a bit while still being quite easy to implement. (The change to base on bounding box instead of mass center of doors.)
Still in 1.6.2 all villagers congregate in one area. Do we think there will eventually be a fix? Its comical for sure.
Bah, this is getting out of hand lol
They arent AI'd properly and i hope they fix it in 1.7
Confirmed in 1.7 snapshots through 13w39a.
This is likely caused by how they detect doors in a village.
Villagers only spawn once in the world. Therefore, they will stay in a certain part of a village unless they detect another door.
To detect a valid door, they must be within 16 blocks long either axis. However, many times the spots villagers congregate in have no doors meeting this criteria (even though there are many more doors in the naturally spawning village).
To fix this, simply build more intermediate houses between structures to entice villagers to new houses. This will both increase possible population cap of the official village, and spread them out.
The other problem has to do with their social AI. Villagers tend to stay in groups of two or more and "talk." This is part of the new AI where villagers gained some sort of psuedo-intelligence. This is another reason (and more likely) that villagers stick together.
Check the end of this section for detection of door rule. http://minecraft.gamepedia.com/Tutorials/Village_mechanics#Housing
Read this section for info on Villagers' social tendencies:
http://minecraft.gamepedia.com/Villager#Behavior
Andrew, your analysis is incorrect. This has nothing to do with new behaviors (It was first reported a year ago) or distance between doors. I never build regular villages any more and instead build "MegaVillage"s with literally hundreds of doors in an area less than 4 square chunks (32x32). My villagers ALWAYS congregate in 2 or 3 areas at night, enough to push their fellow villagers through walls sometimes, into areas that a villager simply cannot go or (far more frequently) killing them with suffocation damage.
They can see probably a hundred doors within 16 blocks, and it doesn't affect where they crowd. The only thing that you can do is cordon them off during the day and then they just crowd up next to the fence, trying to get to their shared "home."
I agree with Wesley's statement. I have a large village with many doors and even half of the village is vacant, which the villagers mush together in one or two hotspots for a few rainy days or starry nights, only leaving to a new hotspot that is once again overcrowded, not spreading like butter like they should. I want a normal looking village with normal behaving villagers, not ones that want house parties every night. This is a problem that after all this time needs SOME attention and SOME kind of action.. Its slack not putting this as a top priority by this point in time.
â– Confirmed on:
@Andrew Thomas
For a better idea for the cause, check my old comment https://mojang.atlassian.net/browse/MC-78?focusedCommentId=44199&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-44199
That comment also provides some tested changes that make this problem less severe (to "buy time" to create a proper fix). (However, since Mojang isn't really using this JIRA properly, that idea of providing those change ideas has lost its point.)
Note also that among the comments there is a link to a forum thread about discussing how a house should be defined (for the villagers), part of a proper fix. Though it is now so old thread that someone might call it "necro" if anyone ever replies in it
Is this still a concern in the latest Minecraft version 13w42b? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
Can partially reproduce in 13w42b. Some houses (mainly in the centre of the village) are much more populated than others.
Do you mean 13w42b?
Yes, corrected.
Sure, it affects 13w42b
imho, nobody in moj* wants to get hands dirty in hardcoding like this bug requires to
one simple question: is that gonna be fixed until minecraft version 15w~? not sure it will
This probably won't ever be fixed unless they transfer Jonkagstrom back to MC to finish what they originally hired him to do. House choosing/assigning needs to be done, and house detection needs to be done even more. Plus villagers need to be able to be better at defending themselves seeing as they are currently defenseless and even a couple of iron golems are not smart/fast enough to protect villagers.
Villages need to generate fully lit (inside and out) and doored (with doors facing the right way), too.
1.7.1 prerelease. It calmed down the past few snapshots, but they've suddenly started cramming into a single building again.
Villagers now spend their full time going into & out of one building. I even made sure the weather was clear.
Still present in 1.7.2.
I made 10 small buildings around a small area and 2/3's of my villagers crammed into one house.
At first I find it funny because they run and cram in clusters but I realized the rest of the houses I built are now useless...
The most annoying thing about this bug is that when they are all packed into the one house they are constantly opening and closing the door, the sound of which is maddening.
This has 283 votes as of now and is over a year old, and STILL hasn't even been assigned yet. Why isn't Jonkagstrom on the case yet?
@Matthew - we should note that many (or even most) of the tickets fixed in various versions never list an assignment on the individual tickets, and given the public visibility of this ticketing system I understand they wouldn't want to list a specific person for tickets so we don't have anyone to blame (other than Dinnerbone and Jeb anyway...)
Matthew Sladen, because Jonkagstrom was moved to the scrolls project shortly after he was hired and did and bit of basic AI work. So yeah, he's not working on Minecraft AI anymore even though that's why he was hired in the first place.
David Truog, the truth is that many of these big issues go unnoticed. The "quick fixes" are usually the ones without assignees. Usually, if a big enough bug is confirmed by a Mojang-ster and they plan to spend time on it to fix it, they assign themselves. Some bugs are fixed without an assignee because their fix was already planned (not because of the ticket) or it was fixed accidentally and just stopped happening (related to another fix or even libraries, such as LWJGL bugs).
I hope this really annoying bug gets more attention from Mojang for the upcoming 1.8 update. Currently I have to trap some of the villagers inside buildings in all corners of my village. If I don't do that they just forget most of the available doors and instead crowd in one corner of the village.
My village still has about 80 doors, 35 villagers and 4 golems but I almost lost interest in them because of this bug.
Oh and the door sounds are really annoying too.
I made it where there was a strip of glass 20 blocks long, did 5x20 doors on each side underneath, then made a house on top of it. They all crowd outside. lol
http://i.imgur.com/jOET70x.png
Several problems with the op proposal, doing 1 per door is odd because each villager is worth 2.9 doors and what if, like in my example, some are impossible for the villager to reach?
They oughta establish only one door ta be "theirs" at night, until broken or driven out.
I always assumed that they're all related in these cases (consider themselves a family unit). Note that if you destroy the door all the villagers will pick one of the other houses to all crowd in to. Killing all villagers (in creative mode so you don't get bad karma) and using spawn eggs to repopulate (putting them inside the house you want them to use) seems to work, although they often will pick a different house than the one you spawned them in.
Obviously a workaround is no substitute for the actual bug getting fixed.
I'm not seeing this problem. In a few of my villages I have 8 to 12 villagers. At night each there are 3 to 4 villagers in each house. What is the best way to reproduce this defect?
Grow your village to 20-30 villagers. If you have only 4 houses with 4 doors each, it's a bit hard to see. Get 10 houses with 6 doors each and you will find only most of them gather in one or two of them. I often build a few houses with 8 doors each to enlarge a village and find that most of them huddle in one of the original homes with only a single door. It is silly seeing a dozen people crowded into the 4 square feet in such a house. Destroy that one small home and they move to a larger one with more doors, but they still tend to mostly gather in one home instead of spreading out.
I have a village in which this happened and where I had created a large house with 72 doors. All the villagers crammed into one of the small houses which became so crowded I decided to destroy it to see what would happen. They, indeed, moved on and even moved into the large, 72-door house I had made. However, they all crammed into one small corner of the house. The issue is not just that they crowd into a single building but that they seem to gravitate to a specific geographic point as well.
This village in question also is affected by the issue where the villagers are constantly running and going in and out of buildings as if they are panicked. It makes for a very noisy situation when near the 72-door house.
Houses with 72-doors? What? Doesn't house usually have 1 door? I think I see your problem.
Trust me (or don't and try it yourself though it'll take a lot longer than the one-house-72-doors example). If you make 72 houses each with one door, they'll all crowd into 1-3 of those houses.
Correct. It doesn't matter the size of the house. The doors are the key. Please educate yourself here: http://minecraft.gamepedia.com/Tutorials/Village_mechanics if you are unsure about how to create additional housing and why you might do it. Particularly concentrate on the "Player-made Village designs" section which shows how to make large cabins of the sort I'm discussing.
What I'm doing is not the cause - the issue was there before I created my large house/cabin. I only saw the issue grow as the population grew due to the additional housing I created.
OK, were the villages generated automatically and then you spawned more villagers or did you build a bunch of houses and spawn villagers in the middle of nowhere?
It happens both with naturally spawned and player created villages, though with the bare handful of villagers that naturally spawn it isn't as easy to see the problem, but it is there if you look for it. Each villager picks a door to be their "home" and tries to stand just on the inside of it at night. A good naturally spawned village might have 10 houses with one or two doors each and 5 or 6 villagers. If you watch them at night they always return to the same one or two houses and ignore the others. Of course most natural villages only have two or three houses and only 3 or 4 villagers, so you won't be able to tell there. Creating a superflat world seems to make more villages spawn, and spawn more houses.
In my case, the village was naturally spawned. The structure I built was within a few meters of other naturally spawned buildings in the village - probably only 10-15 meters from the house I destroyed that was the original target of all the villagers. Any additional villagers were not "spawned" by me but were a result of breeding due to the additional doors. My building was most certainly considered part of the existing village due to the game's rules. When I tore down the original target home, all the villagers then swarmed to a single "corner" of my large cabin.
In order to reproduce this, the number of doors in houses does not matter. What matters is the relative locations of "valid doors" in the village and also where the villagers happen to be at the time they want to rush into houses, and of course the number of villagers. Due to villagers' behavior coding, they tend to be near each other and nearer to center of the village at day time, and then the algorithm to pick the door to get in at night fall has some "issues" that make the villagers even more concentrated.
In a small village, the random distribution of villagers after the day and the small search space end up covering large part of that small village, so it may look like it almost works, at least occasionally. But in a large village, the algorithms and statistics work it out so that the symptoms are seen more easily.
Without testing it myself (I did enough of that while doing and testing the code improvements listed in an earlier comment, here https://mojang.atlassian.net/browse/MC-78?focusedCommentId=44199&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-44199), I'll throw an educated guess what might be a good test village:
Make all houses smallish and with a single door, spread many around the "perimeter" of the village, few in the medium distance from the center, and one in the center. Make the village symmetric (aboutish, for the doors; house shapes/sizes do not matter). As villagers tend to be closer to center than the perimeter during the day, they will likely end up going into one of the houses near or at the center.
Getting the villagers spread so that they see all the doors/houses might be tricky, though, might need to block some of the villagers into houses at the perimeter. (Even in a normal large village, e.g. using superflat, the villagers can occasionally "forget" a part of their village). Or something. Can't remember well any more, 10 months past...
NOTE: IIRC, there has been some changes to village code since, so some of my findings might not be valid any more.
I will concede to the likes of Markku who has obviously had more experience testing this (I've only encountered it in a couple of villages when playing survival). I will mention that it's my recollection that a villager in a defined village (i.e. a collection of "valid doors") should be aware of the doors in the village, and not just a small portion of the village. Given that, is there any good reason why one couldn't have a villager simply choose, at random, a door to enter each night? I get the social behavior aspect of it, but it seems that could be re-balanced with a door picking algorithm so that such concentrations don't occur.
There is obviously a "spread" algorithm for players that ops can use for server games. Something similar (a dispersion algorithm) would be handy when having villagers determine what door to go to at night. Being a programmer myself, I know that it is far easier to say what to do than to actually do it (in particular when working with an algorithm that has been part of a program for some time) but this affects so many people for so long and the interest is so high, it seems like there should be more interest on the part of developers to fix it at some point. My village is largely useless as I can't trade with the villagers due to the chaos.
I have to concur with Dan's comment on this limiting trading in a serious manor. I have had to spend time building a (albeit very simple) villager trading system away from the village to enable me to make trades.
I would caution on just doing a random selection of a "valid" door for each villager, some doors may be valid in the village calculation but not be reachable by a villager. One that comes to mind is those leading to a fenced off garden. I also know people like to add second stories to buildings (or even make gigantic apartments) wherein only the lower / ground level doors are accessible. No doubt a spreading algorithm could take this into account (hostile mob AIs already know how to detect if they can reach an area by pathing), but it would add some additional level of complexity.
@Markku In your previous comment you mentioned changing the door selection from distance squared to distance linear. How did you determine distance? For instance, if a door was +3X and -4Z would the distance be 7 weighted by multiplying it times 4?
The squared distance was already calculated by the existing code, I just took square root of that. So +3 and -4 gives the classic squared value 3*3 + 4*4 = 25, and square root of that is 5 (used as the base distance after my modification). Multiplied by 4 gives 20. The big difference is the squared vs. linear growth of the resulting "weight"; squared value will grow very rapidly after real distance of about 5-6 blocks, making the search function very very biased to nearby doors. The multiplication factor of 4 was just something giving somewhat similar values for the nearby doors with my modified weight, in order to try and keep it working the same way with the restriction counter...
... But those distances and weights are only one minor part of the problem. A large part of the algorithm is played by a some sort of "restriction counter" (MCP terms?), but that counter isn't working well (read, pretty much not at all).
It was the "weighted" that through me off. It doesn't seem weighted to me at all. They seem to be using the square of the distance for efficiency. Rather than getting the square root of every formula and comparing it to 16; they were simply comparing it to 256 (16 squared).
That doesn't seem to be a problem. However, using the same variable to compare distance and "restriction counter" is a problem. Using two separate variables would not only be significantly less confusing but more reliable as well.
Even worse, as you say, the "restriction" counter fails to increment when a villager "goes inside".
I believe I have a solution, would you like it?
Indeed, if the distances were only compared against each other (that is, pick the nearest door and thats it), the squared would be perfect. (Note though, taking square root in this particular context isn't an efficiency problem, as it is not done that many times; compare to the horribly unoptimized and otherwise resource hogging path finding algorithm).
However, what the code tries to achieve is something like "a door that is near and/or has few or no other villagers in already". That is why it needs to give some "weight" for both distance and the amount of villagers already in ("restriction counter"). Some kind of weighting or mixing for both needs to be used, whether by math or logic; math is just typically an easy way to mix them.
Not only is the restriction not working well, the timing of the stuff happens to be such that at the moment tens of villagers pick a door, none of the doors are restriced... They only start restricting once each villager gets inside.
If you do have a possible solution, just tell it, no need to ask. Not that giving solutions (or even fixed source codes) affects anything in here
I only asked because I lack confidence in my own code.
Here is what I have:
/** * Find a door suitable for shelter. If there are more doors in a distance of 16 blocks, then the least restricted * one (i.e. the one protecting the lowest number of villagers) of them is chosen, else the nearest one regardless * of restriction. */ public VillageDoorInfo findNearestDoorUnrestricted(int coordX, int coordY, int coordZ) { VillageDoorInfo bestDoor = null; VillageDoorInfo bestDoorOver16 = null; int sqrdDistance; int lowestOver16 = Integer.MAX_VALUE; int lowestCount = Integer.MAX_VALUE; Iterator var6 = this.villageDoorInfoList.iterator(); while (var6.hasNext()) { VillageDoorInfo someDoor = (VillageDoorInfo)var6.next(); sqrdDistance = someDoor.getDistanceSquared(coordX, coordY, coordZ); if (sqrdDistance <= 256) { int useCounter; //someDoor.getDoorOpeningRestrictionCounter(); // Count villagers behind the door if(someDoor.insideDirectionX==0) { useCounter = this.worldObj.getEntitiesWithinAABB(EntityVillager.class, AxisAlignedBB.getAABBPool().getAABB(someDoor.posX-6, someDoor.posY-2, someDoor.insideDirectionZ<0 ? someDoor.posZ-5 : someDoor.posZ, someDoor.posX+6, someDoor.posY+2, someDoor.insideDirectionZ<0 ? someDoor.posZ : someDoor.posZ+5)).size(); } else { useCounter = this.worldObj.getEntitiesWithinAABB(EntityVillager.class, AxisAlignedBB.getAABBPool().getAABB(someDoor.insideDirectionX<0 ? someDoor.posX-5 : someDoor.posX, someDoor.posY-2, someDoor.posZ-6, someDoor.insideDirectionX<0 ? someDoor.posX : someDoor.posX+5, someDoor.posY+2, someDoor.posZ+6)).size(); } // Is this count better than previous counts if (useCounter < lowestCount) { bestDoor = someDoor; lowestCount = useCounter; } // The best door is the one not used, stop looking if (useCounter == 0) { break; } } else if (sqrdDistance < lowestOver16) { lowestOver16 = sqrdDistance; bestDoorOver16 = someDoor; } } return bestDoor != null ? bestDoor : bestDoorOver16; }One more thing. In EntityAIMoveIndoors.java, in the shouldExecute method, what is this line for?
That one is basically 98% probability. Considering the context, it will randomize the timing of when they decide to get in. That should reduce the chance of everybody rushing to the same door at once, but unfortunately, the restriction timers had their effect rather dysfunctional, so...
The best idea in your suggestion is the idea to calculate the villagers near the door (bypasses the currently failing counter). However, it also makes it either-or; either counter only, or distance only (for distant ones); the current math mixes both in order to do both: spreading villagers in houses and keeping travel distances short, in a smooth way. There is no need to adjust that mixing behavior, as long as the distance weight and villager counting work properly. (However, as a temporary adjustment, yours is just as valid as the changes proposed by me; it does improve the situation.)
Note that while your change may get better counting of villagers already inside, it does not count villagers still on the way to that door. That is one of the problems making the current algorithm near useless; villagers will go to just one to few doors, then keep fighting in front of for a while, until some time later possibly choose another one. Ideally, most of them should choose different houses before even starting to move anywhere for that night, and the few that end up choosing the same houses with another villager would consider the situation acceptable once they realize they have to share the house or to run possibly a long distance across the village; unless there is a vacant one nearby.
The thing is, if you want to try to "fix it good", you need to consider multiple bugs/design flaws/issues/improvements at once; while it might be possible to get a nice improvement by adjusting one part of it, the rest will come back haunting sooner or later. Hint: take a look at
MC-10841and think how it affects this issue, too.OK, I have another suggestion. So each villager does NOT look at the same door, I've added this as the first line in the method:
Collections.shuffle(this.villageDoorInfoList);It randomizes the order the villagers look at the doors.
Still present in 1.7.4.
https://twitter.com/jonkagstrom/status/174393910607622144 "Also we think it's the players task to build" -Jonkagstrom
agilerelic... that is irrelevant to the discussion. The problem is not over population, or villagers building new houses. It is the problem that in a large village, the villagers like each other so much they all decide to live in one house, even though there are LOTS of houses in the village.
The crowding also causes them to climb ladders to village roofs, or even into jungle trees, which they otherwise would not do.
There is code that was added when villages were first created, to make villagers 'socalize'. This worked fine for normal small villages. But there is no code to make villagers want a bit of elbow room and spread out to prevent overcrowding.
We humans, like to socialize, but we also do not like to over crowd. Even in a 'party' everyone has a personal space. Of course we learned to suspend that instinct in special situations such as for lifts, or peak hour trains and buses, but generally we try not to 'crowd'. Especially in a home or other social situations.
Villagers need something similar.
Anthony, yes in fact, it's generally in human nature (or pre-conditioned into modern society) to evenly distribute among options. For instance, in a bus or waiting room, people will often choose the seat furthest away from others. For instance, someone sits in the front, someone sits in the back, someone sits in the middle. It'd be odd to sit right next to a complete stranger when there aren't any other taken seats.
@Anthony Thyssen:
"But there is no code to make villagers want a bit of elbow room and spread out to prevent overcrowding."
Actually, there is a bit of such code. It just doesn't really work. My earlier comment(s) elaborate on that.
There is a slight problem with this too. The villagers are only supposed to fill about 2/3 the amount of doors i believe, so there will always be empty houses unless you destroy them.
hi i make some testing about the problem and i notice that in some biomes the villages work fine
like plane biome
the biomes that have the problem are desert and savana
Minecraft 1.7.4
No, the biome does not matter.
mad max - by any chance, do you also have issues with villagers constantly running? If so, I wonder if in your case the crowding and the speed are interrelated. It has been observed that the "always running" issue is potentially biome-dependent.
I have personally observed crowding in plains biomes as well as others.
I have seen both the crowding and speed issues in both (naturally generated but expanded) villages I have - one in a plains biome, the other in a desert.
David - that's good to know. Are you able to (or have you already) add your observations to
MC-17247? Perhaps also add your seed and coordinates of village(s) that are affected?yes they run all the time during day is the same bug with
MC-17247test it i create 3 villages one plain one desert one savana and only in plain work fine no problem
i have test it in SSP and on MSP same thing happen:
at desert and savana during day they RUN all the time in ONE bulding
minecraft 1.7.4 / minecraft server 1.7.4
I built a rail loop around my village to get villagers to the other side of the village, but they keep going back to the same building regardless of where I release them from the minecart. I even cured a zombie in one of the unused houses, and after he was cured he went to the other side to socialize with the rest. Interestingly they congregate in a house that I built, as opposed to the ones generated by the game. ver 1.7.4
Guys I noticed this bug is be fixed in the latest 1.8 snapshots with the villager AI updates! We're saved!
I noticed that the villagers have spread out as well in 14w06b, but in 14w07a they seem to hang out at one end of town again although in different houses. I will hang around to see if the door locator was just reset and they need to find the doors again.
I might create another village elsewhere to test this where closer to my current build site.
The new trade options seem to show up after making a trade with the old villagers. I am going to make some more homes to see what happens when they breed.
So, it seems, that last snapshot's villager's ai prevents crowding in single house, am I understood it right? Can anyone prove it?
Well, I set up 5 houses, each with double doors. 3 on one side, 2 on the other, small huts, equal size. I spawned about 20 villagers or so, and put a zombie in the middle to spread them all out. I waited a few minutes, turned the time to night, and all the houses had about an equal number of villagers. So basically what this means is that WE'RE SAVED!
@Paul Smith, the test you described is not quite a valid test for this issue.
The issue may have been fixed, but a better test would be simply to find a large naturally generated village (or create one, the more villagers the better), no zombies to spread them around (the villagers should spread all by themselves), and wait for at least one full day or preferable more than a day (can use peaceful to avoid night time troubles with zombies). There are two mechanisms that group the villagers, the other being the start of night, so rolling through multiple nights should amplify that to be easier to detect its effect.
Then check the results.
A lot easier way is to make a walled square in flatland world on peacefull diff. and surround it with a bunch of doors (like as a simple villager's breeding farm), then put some villagers inside and see where they like to hang most of time. With topic's bug, they would like to be in north-west corner, I guess, not sure, and without they have to spread all around, the density should be normal in this whole square area. It would be great, if someone tests it with the latest snapshot and makes some screenshots during the process, so the community will be able to make a conclusion
@Vit Musienko: That scheme would test another bug (the movement tendency to north-west). Also, single building (well, a "valid door") is not enough to test all the bugs in this issue, unless they are distant enough. The requirements for testing is large enough area for villagers to move around during day (large enough to get past certain distances in their AI code), and enough buildings spread over large enough area to chose the place to stay the nights. And also no other things messing up the test, like zombies.
Note that villagers do have (or at least had) a specific AI goal to gather a bit into groups (close some other villager), but they also have/had the ability to go away, too. It is the interplay of multiple mechanism, some badly implemented or bugged, that makes up the whole issue. My earlier comment should have some of the details...
i thought these bugs are pretty much related each other.. ok, need to see the code or do a lot of experiments ingame
I agree that this effect was likely the interaction of multiple rules in the Villager AI, and also that the behavior is much improved in the latest snapshot.
I have a pre-existing artificial village where I've evaluated this. It is a very large village, built under a 101 meter diameter glass dome to protect from mobs. Inside the dome are two concentric 5-story rings of apartments. Total is approximately 700 doors. (I can't begin to count the villagers, or even the iron golems with them moving in and out among the structures.)
With 1.7.4 the vast majority of villagers conglomerated, day or night, on the first floor on the northwest edge of the outer ring. With 14w07a they definitely spread out a lot more, some even venturing outside the dome. Large crowds will gather in the central park/forest, and others will gather at the north end of the dome where a natural river passes inside the dome. Some of these villagers will play in the water. (All we need now is a rubber duck. Where did I leave that chicken??
They do still seem to be biased to the northwest (even after many day/night cycles in 14w07a), but not nearly so strongly as before.
Part of me would like to see this AI taken a step farther where villagers would socialize during the day but would tend to associate themselves with particular doors (apartments) at night, generally trying to return to the same door (making it easier at night to find a particular villager offering a particular trade), and trying harder to spread themselves uniformly among doors within the community at night. Children at night would tend to go home with their parents. But, what I see in 14w07a is a huge improvement in the AI, and makes creating large villages more interesting than they were with the old AI.
Yeah, I've also noticed the AI changes have changed the way vilagers view village boundaries. In the snapshots, villagers seem to wander far more outward of a village then before, but there are boundaries farther out they will not cross, suggesting that village boundaries have been increased.
From tests seen on the forum so of the new 'spread' may be caused by farmers now migrating toward farms.
It is hard to say if it is fixed or not, except maybe in a village that has no farmers.
The general migration toward North-West is an issue with all mobs (and there should be a separate bug report about that). If villager AI is fixed this general migration should not be a problem with villagers.
From what I can see, I'd say this is finally fixed!
Over the last day or two I have taken a natural village and built up two apartment buildings with 6 doors on each side and two stories high and bred the population up above the 2 iron golem threshold, and they appear to be spreading nicely. There are often a number of people in the apartment buildings, but I would expect this given that they have so many doors. Before if they did decide to occupy such a building ( and generally they wouldn't since they all picked one building to crowd into ), they generally would all gravitate to a single door, but now they appear to spread around the building nicely, and there are still generally 1-2 villagers spread around in most of the other buildings as well. Almost more importantly, they no longer constantly slam the door open and closed!
Let's not jump ta conclusions until we get an official word in on the bug status first....
Don't wanna jinx it now....
I agree to Thomas, let the moderators decide
Breaking down the door of the building they are all crowding into causes them all to immediately target a different building, but they all target it together, almost like all the villagers are just one mind.
actualy, they are..
Someone seems to have found the issue. Apparently the algorithm for expanding the villages is not very effective and is causing villages to shrink instead of expand.
The analisys of the code seems very thorough, I will not copy it here because it is too long, but you can find it here:
http://www.minecraftforge.net/forum/index.php/topic,7351.0.html
I'm not sure if that linked explanation is actually correct; I did similar (and even wider) code digging couple months before that (see earlier comment of mine dated 07/Feb/13), and while the village size/location algorithm is indeed, shall we say, weird, there are reasons for some its behaviour, and it does work, at least to some extent. (I did observe its behaviour for quite a bit, as part of trying to debug/fix another bug/problem related to village size, and it does some really "wtf" stuff at times, but it did provide a usable village about all the time.)
Village size/position algorithm does play a little bit in the overall mess causing this issue, but it is not the biggest reason. Or at least wasn't back then. (I haven't looked at the code since, things may have changed, though considering Mojang's bugfixing history so far, quite likely the code leading to this issue is still about the same.)
EDIT: after reading rest of that linked forge thread; that earlier comment of mine provides some proposed code changes that I tested to reduce the villager crowding to manageable level. Not full fixes, though, as they would have required far too big code changes to be categorized as fixes and/or shown in a comment and/or too large a wasted effort.
It's been fixed in 1.8, I've seen many naturally generated villages in 1.8 and the only bug I see is an inbalance in villager professions. No AI issues like this, like in 1.7, it's finally fixed.
So I created a world a while back, and I encountered a village with this bug (which ALL villages might have) and I thought that I could fix it, since I was in creative mode I just made a bunch of Iron Golems. For about 2 minutes the villager's went on with there usual routine. Until suddenly they just ran back into there houses, it was day, there were no hostile mobs about, the only mobs in the city were the villagers and the Iron Golems. Have I possibly ran into something that could maybe, just maybe fix the bug? Or do we have to wait until somebody at Mojang cares enough to have this fixed so once again the villages can be another pretty atribute to this pretty and scary game?
This bug has been fixed. A mod should update the status.
Yes, everyone test this in snapshot 14w21b, it is finally fixed.
sup guys
tested it on 14w21b, and the bug is still present
added screenshot as a proof
That isn't valid villager housing Vit... you just have a bunch of villagers contained in a wall, with some random doors outside.
Vit stop editing you post 1000 times.
Vit Musienko, what you're seeing is
MC-10046, maybe that's still not properly fixed.okay, maybe you're right, that was wrong experiment
need to test more
btw, I edited post only 1 time, don't know whats wrong
Excuse me for that stupid screenshot. I tested for about half an hour watching a naturally generated village, turning night on and off, rain+thunder on and off, and almost all the houses were occupied by one or more villagers. finally, subj looks like resolved now.
I believe I am still experiencing this issue in 14w30c
I think it may be Villager AI. If not then there is definatly a problem. Or mabey a zombie is trying to get at them.
fixed in 1.8, also i confirm.
Bug confirmed partwise for1.8.1-pre3 it seems like villager don't recognize how much place is in a house, in theattached screenshot ("Villager house (1.8.1-pre3)") you see that most of the villagers wont toget in the one house which is obviously full, even the house in front has still space insideNo Marcono, that's not right. From your screen shot it appears that you spawned like 1000 villagers in creative mode with only 2-3 houses and so they just have nowhere to go. The number of villagers should only be about half the number of doors. In other words, if you have 10 houses with 2 doors each, spawn 10, maybe 12 villagers, and see if 5 or 6 of them crowd into a single house with several of them being left empty.
Oh sorry, didn't know that
Well you are right, sorry ;(
I can confirm this is an ongoing problem through 1.9, and was present for me in 1.8.x
I've been villager breeding, and keep my house on the edge of the village (Still part of the village).
The villagers for the most part - approximately 5 will go to one building, the rest will go to another.
There are approximately 20 houses, most of the walls are knocked out with lines of doors on all of them.
Worth noting:
All but 2 of my villagers died at one point, but I managed to keep them safe to breed back to capacity.
There are enough villagers now to spawn 3 golems.
I am playing on a Mac, on Realms, 3.06 Ghz Dual-Core Pentium Core 2 Duo, 16 GB RAM.
Java is up to date.
See
MC-89509for the current iteration of this bug.Fix Version/s:Minecraft 14w21b
this is incorrect, this bug is supposed to be fixed with 1.4.2 villager update, please confirm
No, this bug is even confirmed for that exact version and many after it. And 1.4.2 was not villager themed, Are you sure you're really talking about MCJava?
This bug actually returned during 1.9. the math behind Villager AI would have them all eventually all go to one corner of the village after several hours. I think it had something to do with how floating points work or something. Either way, it should still be fixed again.
If they crowd to one specific corner of the village i.e. always on an edge of the village, even worse if it is the same edge and the same edge in every village, then it is another bug, not this one (e.g.
MC-89509orMC-3944, both of which were of the north-west tendency -kind).If they tend to crowd in to one or few random houses (in larger village), possibly different houses each night, then it could be this bug (with possibly different root cause but the same symptoms, but this technical detail doesn't matter to us players).