Mobs going out of fenced areas/suffocate in blocks when loading chunks

Seconding this. Quit the world with 13 cows and MANY chickens in pens; come back to 8 cows and 5 chickens in pens. The cows were dispersed around the place, I herded 3 back in... but I don't know what happened to the chickens. In 1.4.2 on a server where their pens bordered on walls I'd sometimes see the animals' drops (and one or more animals missing) when their chunk re-entered memory, and playing 1.4.4 it looks like the issue still isn't solved.

I can confirm that this happens though only with pigs and chickens in my case. It seems to occur whenever the chunks are loaded because a similar phenomenon occurs when traveling around and coming back. Also, looking at the reports that this "duplicates", I have to say that this appears to be a similar problem.

As for the cause, I think it is due to animals butting up against cobblestone walls and wooden fences. When they're reloaded either at the start of the game session or being back in the area, the animals appear on the other side of the fence since animals right against fences appear to be inside them. The game mistakes the animals for being outside when they were inside.

Voted. This is a very annoying bug and it affects a lot of things (all walking mobs for sure). For example an iron golem farm. Iron golems or villagers can be found out of enclosed areas. When all villagers escape, the iron golem farm will be ruined. So you always have to use workarounds.

Voted, I also realized that I can kill chicken that appear to be outside the fence when they are actually inside. The drop appears at the correct location (inside). I also find eggs outside of the fence.

Breeding systems with minecarts also don't work because the animals are not. Cows are near the cart but not in the cart, they will also 'teleport' vertically if the cart was on a second floor of a barn e.g.

This bug is still present in 1.4.5.

It seems that the mobs can escape through all sort of blocks that do not cover the full block space, like fences, doors or glass panes.

I think the problem is, like Nicholas Williams already mentioned, that the mobs are running "into" the fences and when the chunk is unloaded and later reloaded the game can not say for sure from which side of the fence the mob was coming. So in some cases the game guesses wrong and the mob escapes.

Maybe the game just compares the integer values of the mob position with the positon of the fence block, without the fractional digits.

I believe it occurs with full blocks too. I travel a lot with ender pearls which most of the time land on chunks that have just loaded. Today I witnessed one sheep inside blocks of dirt taking damage and it died.

Issue in 4 pics.

Voted for this very annoying bug. I've got a animal farm with cows, sheeps, chickens and pigs. All of these animal types - but mostly sheeps - appear outside the fence - and they should have enough place inside the fence. And to bring them back is not that easy and very annoying. The animals does not only look like outside and "teleport" back, once I'm near them, they ARE outside and walk away from the farm if I don't have an eye on them. 😞

Please keep an eye on this issue. I hope this is solved very soon..

Yeah, this is exactly the issue, animals are REALLY outside. When they just seem to be outside whereas they don't is another issue (MC-10 I assume).
Hope also it will be solved ... So keep on voting for this issue in order to make it popular 🙂 !

I have this problem, but with solid stone walls. Stupid cows crows up my chicken farm, and kill my chickens.

The same thing has happened to me aswell. I went to the nether and when I came back, some cows were running around free from their enclosures.

Confirmed in 1.4.6.

The animals often still look inside the fence (not the block) when the chunk is loaded, but they can then walk right out.

I have also witnessed couple pigs dying inside stone wall after reloading... probably having the same root cause as for the slipping through. (And also have had my share of farm animals going AWOL.)

Note, e.g. boats can be at slightly different position after reloading; if they were right against the beach when leaving the area/world, they can be just a bit more towards the beach and start "floating".

I'd imagine this could be some sort of glitch between using double's for entity positions while the area is loaded, but some different data format when storing the positions. The difference between exact values of stored vs. running system may cause tiny shifts in position, moving the entity "into" next block and causing the symptoms described.
(EDIT: alas, this was not the case, it seems. Entity position are also stored as doubles.)

So far I have only seen my sheep escape from the north side of the enclosure. Building a fugly wall up against the northern fence (not replacing it) seems to have successfully worked around the issue for me. Is that consistent with other people's experiences?

I really only see it to the west.

Animals escape to the north. If you want to have an example, look at the screenshots with sheeps. That is exactly where they escape.

I can imagine that it varies setup-to-setup.

I have a similar problem with a crowded underground chicken bunker - if you step just outside, logout, then log back in, you can hear chickens squawking lots and on reentry there are a number of corpses & feathers along the walls. No particular side is favoured.

Since 1.4.x, I noticed that animals have the ability to wander inside solid blocks. To reproduce, dig a 3x3x3 hole and place a cow inside and push it. The cow will go inside the block and turn black when he reach the middle point. When you release him, he gets out of the block slowly (spring effect). If another animal push hard, it can even make the animal suffocate or die. The reason I say that they escape to the north is because of multiple witnessing of this bug. I built a reserve bin that is divided in cells. All animals are problematic for me. When they are in a fenced farm, they wander randomly, but when they reach the west limit of the farm, they push, push, push to the north and that is where death or escape occurs (I always see the animal in a specific bin, if I close the bin, I see pieces of meat in from of the cell. If it is a fence or solid block, the animal pass right thru. Go figure. If you have a thick wall, the animal suffocate and die. Of course, if you have an over-crowded farm, they may escape everywhere. I think the best way to fix this bug is to completely prevent animals from passing thru block and fences by reducing the penetration distance of animals of exactly one block (except for chickens, since they are smaller) or increase the spring effect to surpass any other pushing effects from animals, players and mobs when the penetration reach a gap of around half a block (still half of a block too much but better than a full block). The facet of the block should be the penetration limit, that's my opinion. Do you guys remember old versions of Minecraft? Everything was perfect in term of physical collisions. Now, it is very berserk.

I am sick and tired of hunting down those escaping animals. I am making engineering devices to trap and bring the animals back in the farm, it is spacious, noisy and ugly looking. The best fix I found is to build a reserve bin all around the farm but I am having difficulties to bring the animals back in without adding catatonic piston and water noises. Please, if someone finds a way to circumvent this annoying bug, could you post your ideas? Thanks.

This is still an issue in Snapshot 13w06a. Has anyone tested if hostile mobs can "penetrate" walls/fences?

To my experience, I never saw a mob (zombie, skelly, creeper, spider) penetrate a wall/fence except for a small glitch MC-2713. The skeleton will visually seem to be passing thru a solid wall and he will wander around but he is still trapped. He can't hit you or vice versa - he is like a ghost. After a few seconds (probably a chunk update) the mob freeze and slide directly where he is supposed to be. It happen when you stack hundred of skellies in a 1x1 hole in single player.

It was working ok for me until Snapshot 13w06a, now the animals keep "escaping".

I can confirm, it's a very annoying bug that I wish would be fixed.

Yesterday I noticed that zombies from (panda's / panda4994) mob spawn switch had escaped from their 2x1 enclosure.

I can confirm, it's still an issue in 13w06a.
It also happens to Cobble Stone Walls.
Please fix this. It's imo one of the most annoying bugs

confirmed for 13w07a

I can confirm this is an issue for solid enclosures as well as fenced enclosures as of 13w07a.

I created a 2-block high glass enclosure at my farm for my chickens, since they kept getting stuck inside fence blocks (MC-4661), and kept killing themselves when I didn't use transparent blocks (MC-9568).

On reloading the chunks chickens were still able to escape, even though they had to displace themselves by a full terrain block from their former positions.

I am also having this issue. So far it has only been with pigs, both adult and baby. The cows have remained in their fences.

I hope this gets fixed!

I actually wasn't having this problem at all until I updated to 13w09a/b (from 13w04), now, nearly every baby animal I get winds up suffocating to death when I log out and back in, unless they wound up being spawned completely outside the enclosure.

The worst expression of this however is that creepers are glitching out of my mob trap, located nearly dead center of my base. I haven't had one blow up and take out hours of work, yet, but it's only matter of time at this point.

I'm having this same problem in 13w09c. (Single player, survival) In my underground pens, the babies, or even sometimes the adults, will glitch into the wall and suffocate. In my above ground fence pens, they escape when leaving and returning.

I'am having the same problem, been testing it in creative, They will escape all fences except gates, and seem to escape the stone fences very easily even if you are standing or idling near by and not changing which chunks are loaded.

I posted a bigger more precise post in another thread (MC-9476)

I have moved back to 13w04 because I had the villager I had been trying to breed grow up and get killed when another villager kid pushed him into wall SIX times. I did not log off and back on. I did not load or unload the chunk. I am standing 10-20 blocks away watching this villager spawn, waiting for him to grow up, then staring helplessly as another brat runs by and pushes him into a wall and he twitches to death.

Obviously this was something intended to counteract some kind of player abuse because less than half an hour after stepping back to the older snapshot, no sudden death syndrome, and i finally have several of the villager type I was trying to get. There has got to be a better way than whatever the team was trying to do that caused this.

Still a problem in 13w10a.

seeing it on 13w09 and 13w10. Mostly my chickens are escaping. Oddly somehow a cow escaped, but I ended up with an extra cow. This is in an underground fortress so it wasn't just a cow wandering in. I always keep 8 cows and 6 chickens, so works with small numbers of animals as well.

I can confirm this for 13w10b.

Still in 1.5.

This still has not been fixed. I have tested this on the 1.5 Pre-release. This has always been an issue and seriously need to be fixed. Not only visually but they really do on occasion go through not only fences but blocks in general.

They can only escape through transparent blocks: steps, fences, "walls", glass. They will not escape through solid blocks. Animals which are standing very close to / inside these types of blocks may suffocate en masse when the world/chunk is loaded. (MC 1.5)

(Even with an enclosure of all solid blocks, and plenty of room to move, they will sometimes push each other into the wall and suffocate. Also, network latency can cause them to appear to "slide" out of their enclosure, then pop back in when the connection catches up. These are probably separate issues.)

Again Negative. I have posted picture. You can also test. Its cause when entities are half way through a wall and a chunk loads. This causes them to go to the other side. A permanent fix would be to make object solid. At the moment objects are not solid. Entities can pass through blocks. Call it what you want its bad scripting. Included in the first image is a temporary fix.

This shows the current issue and a fix. I belive if mobs where to freeze for a moment till after the chunk is loaded it would fix this issue.

This is an example of before leaving the chunk or exiting the game.

This is after leaving the chunk and when it is reloaded the entited go through the wall. This is because they are already partially through the wall. That is the main issue. Not only visually but in actuality. A solid object script wize would prevent this. Blocks in general are scripted wrong, verified by looking at the code and scripting a mod to fix the issue. Both solutions work.

Nathan Gorzelanczyk: My testing was done in SMP with a reasonable number of mobs in the enclosure (the average use case). I re-tested in Creative mode, and you are correct: if enough animals are in the enclosure that they are intersecting the walls (as in screenshot-2.jpg), reloading a chunk will indeed cause some of them to appear on the other side – regardless of the enclosure material. Also, packing in a ridiculous amount of mobs will also cause the visual "sliding" (MC-11086), even in single-player where lag can't be the cause.

I just hope this issue is resolved. I have posted this in numerous locations over the span of minecraft, without any resolution. I appreciate the advanced response and you verifying what I am witnessing. It truly means a lot. As I have seen this issue not only in Single player mode but on numerous servers I run. A lot of accusations of grief when in reality it is simply a glitch. An again I really hope that a solution is made and sooner than latter as I have been waiting for a patch for this since 1.0 when minecraft was young!

I really hope this issue gets fixed because it can be super annoying when it comes to animal farming

i can confirm this, what i did is use water to trap them into place.

David and Nathan, This is not only a chunk loading issue so long as no chunks can load or unload while you are right there working or idling.

I have tested it numerous times and they will escape while idling in the vicinity. It is not the visual sliding issue that I'm talking about. I have a creative world where I have been testing it and my single player map is what brought me to test it because while I was sheering sheep they were escaping from closed pens.

I have all 6 fence types (cobble, mossy cobble, nether brick, gates, and wooden) set up with a 3*4 space inside and 6 sheep of a specified color in each. There is a small flat of land around and a small trap that encircles the spit of land to trap the escaping sheep to verify they are escaping and not dieing.

Sheep have escaped in less than 10 minutes while idling directly next to the pens. The only pen that does not loose sheep is the fence gate. I have been testing it on and off in each shapshot for a minimum of 1 hour per snapshot. Some drastically longer. For instance 1.5 has been running for over 3 hours today. Wooden fences lost 2 of 6, gates 0 of 6, nether 3 of 6, mossy 4 of 6 and cobble 2 of 6.

Chickens (didn't test other mobs) seem to like getting stuck in the corners of fences. As more get stuck they are pushed around to adjacent blocks, in this case the surrounding fences over a period of time. See screenshot above.

I've also caught the suffocation in solid blocks on video. I have yet to render it (it was part of a lets play), but if that is needed I'll post the link once its up.

This bug returned when the corner fence hitbox was corrected ([MC-2666]), so maybe it has something to do wiyh that.

You might be correct Stefan with the hitboxes and it may not be limited to fences/walls. Here is a simple test for the suffocation:

1.Create a room say 6x6x2 of cobble/stone blocks (not the walls).
2.Spawn a fair amount of chickens/babies. Say 10.
3.Sit a watch (from above) for a few minutes as they tend to group in corners or along the wall.
4.Notice that some are nearly half way into the blocks (clipping).
5.Close the map.
6.Load the map.
7.X amount of chickens suffocate or rarely escape the block wall.

I tested this with sheep, creepers and zombies. The creepers are less likely to suffocate than the zombies. Creepers are slender compared to zombies as zombies extend their arms. Baby sheep are as likely to die as chickens and chickens/baby animals are smaller and or longer.

So it seems to me this is more of a collision issue with the game knowing where a mob is (or the mob model itself) than specifically the hitboxes of fences/walls. It could even be a client/server issue as both SSP and SMP use a server now. Like the server saying "the mob is here", but the client is saying "ok they are in the wall now".

This bug, whatever the cause, is more noticable to us since fences/walls are smaller (and transparent) than a standard block and the mobs can pass through them without suffocating (most of the time) when the chuck loads. I think there is a decimal number off in the code some where. 🙂

I can confirm animals escape through wood fence in 1.5 pre-release. I have yet to see any animals escape from cobblestone fence.

They can escape through cobble fence as well. The ones that are visually out of the box, become out of the box when the chunk is unloaded and then reloaded. The simplest method to reproduce this issue is to spawn a lot of them in a box, exit the game and reload a few times. This is the not just an issue with lots of spawns, but is simplest to reproduces this way. Please get your friends to vote this up!

Confirming. This has been happening for some time.
Building a good looking (fences only) farm is impossible now, because after some time all the animals are outside the fence or if blocks are used animals just die off.

Similar issues

MC-119 Going downward through solid blocks, causing suffocation, death of entries, and entities escaping
MC-2025 Going forward through solid blocks, causing suffocation, death of entries, and entities escaping

Final Comment.

The only patch that I can figure at the moment.

Making mobs solid.
Therefor making mobs stack like blocks.

The underlying issue is mobs are not solid objects and therefor many can occupancy the same space.
A possible solution would be to make only animals solid and keep mobs the same as they are.

The reason I have not uploaded a patch is this would entirely change game play.

i agree with nathan here, the root of the bugs are probably the same but i have not checked the code. and yes the mods can be very thick headed.

My observation is that when baby animals grow up their hit box changes and they can then phase/glitch out of the fenced in area.

That happened to me a lot of times before, I hope that bug is fixed too before 1.5.1 comes out.

think I found a work around for this. I dig down one block and then have all the edges fenced. since starting this configuration have notlost any further mobs

just to be more clear the fence in down one block from the surrounding area.

Also observed animals and villagers escaping enclosures made of fence, or suffocating in solid walls when pushed against the wall by water, when growing from baby to adult. Leaving the area was not necessary, this happens even when the chunk is loaded and stays loaded. Seen on 1.5pre.

Why this are not fixed in 1.5 ? 😞

Can't understand this as well.. 😞

Animals exhibiting this behavior after maturing and going through/suffocating in walls upon loading chunks confirmed in 1.5.

this was NEVER a problem for me until starting to use 1.5?

what gives?

You might just be very lucky.

Yeah….no chance of that.

It's got a lot worse for me since 1.5: my crowded pens of chickens are having regular escapes (walls of wooden fence, fence gates, and cobblestone).

dig one down in a square then put water in the corners so the the water flows into the middle, your animals will get stuck in the water. put a fence around it (one block above the water). they will not escape, plus you can put a hopper in the middle so that you can get the eggs in case of chickens.

I have had the same problem in 1.5! Mojang please fix😞

Mojang has to fix this...

The problem in 1.5 is probably caused by changes in corner fences - details to follow:
I had a few crowded pens with animals of different kinds. In 1.4.3 it was working fine, but after upgrade to 1.5 following things happened:

• Chickens started to leave its pen and overran my wheat and pumpkin farms (so this were real escapes, not glitching through the wall)

• Pigs did the same (altough they did not have farms to ruin in the neighbourhood)

• A wolf entered sheep pen and killed at least one animal.

I noticed that it happened especially when I left the area and came back shortly thereafter. Im not sure if the distance was enough to chunks get unloaded, or just animals dissappeared and were reloaded.

I also found a workaround: When I replaced all corner fences with 2-high 1x1 wooden plank walls animals ceased to leave. Hence my note that the problem is with just corner fences in 1.5.

+1.5 minecraft

Still in the PRE-1.5.1.

Why?

Because the developers haven't found a convenient way to fix this issue yet. I think that should be pretty obvious.

why isnt it assigned yet?

In 1.5, I built an egg farm, and chickens are regularly being washed down the collection hole, despite that being covered by a top-slab. I don't think it's just chicks, either, I find a lot of adult chickens too. I suspect that to be another manifestation of this same bug. Ironically, I built the egg farm to deal with the chickens escaping from my fenced pen.... It's good to hear the problem with that really is worse in 1.5, I wasn't just imagining things. Also, I don't think it was explicitly mentioned above, but the most common form of this from prior versions was when baby animals pushed their "parents" into the fences/walls.

Yes...

This could be easily fixed, use a full block hitbox on movement of animals/mobs. its an easy quick dirty fix that would make many people happy enough.

You want baby chickens to have a block-sized hitbox?

no.

@C.J. Wijtmans ... I wish it was that easy! Its a little more complicated than that... lol
It has nothing to do with the hit box as this is completely different,
If the hit box spoke correctly to the blocks this would not be an issue,

Think of it this way, sand falls on block and stops right....
Well entities when chunks are loaded stop within a block... Not before a block, when they are inside it.

One issue
However when a chunk is loaded no blocks are there... so they for a moment can go farther inside the block.
When the game reads where they are within the block they are pushed toward that side, meaning they can escape.

Another issue
is because they read a block when they are inside it, a slight lag issue can cause the math to go bad and
they could be again, closer to the other side, so they are pushed to the wrong side.

It's the way that the physics and blocks are interpreted by each other that causes this bug.
It's very similar to the way entities can stack in the same spot, think mob grinder,
instead of like in real life where they would pile up.

Hope this helps in the understanding of the issue at hand.

So what exactly is your suggestion again?

Setting to private to temporarely stop the spam.

Thanks @Nathan. I appreciated your explanations, even though the mods considered them spam and removed them. Your comment about slower computers having more lag, and therefore seeing more of this issue—particularly in 1.5 which is a bit slower—made a lot of sense. My FPS is around 20, so lots of escapes 8-(

Confirmed happening mainly with "baby mobs." Adults are out mainly because they were babies that have "grown."

Confirmed happens when leaving an area and then returning. That is to say, leaving the allotted distance within the game that the mobs are no longer active and returning. (essentially the same as disconnecting and reconnecting.)

Confirmed happens when breeding, disconnecting and reconnecting.

tbh i cant see how hard it can be to do this. for example an AI should have a vector called moveTo. which holds the coords where it wants to move to. During filling this moveTo vector it should detect hitboxes on its path, if it detects an obstacle it should put moveTo at the obstacle, which would resolve many bugs regarding AI movement. The CPU intensitvity should be OK and can be throttled down by making less moveTo modifications if CPU intensitivity is detected.

1.5.1 Update does not fix this. Still mainly baby mobs.

I added some images of villagers which have managed to become trapped inside walls. This is roughly the third or fourth time it has happened; fortunately the villagers themselves are Invulnerable and thus do not suffocate.

Ignore the spawner and custom textures; it's an adventure map, but everything is vanilla. Note the slab floor; this may be related.

I'm not sure what you did, but after watching so many of them die for hours, I know villagers are not invulnerable to suffocation.

I edited the villagers to be Invulnerable for the purposes of the adventure map - they can't be harmed by anything. That's a vanilla feature and has no bearing on them phasing through solid walls.

Confirmed happening with me in 1.5.1. This happens with my separately caged animals. I had cows in one pen, pigs in another, and sheep in a third. I come back later (did not breed any) and some of each of the animals are in each other's pens. There is a natural diffusion at work.

Started the game just now and the baby cow was out of my pin... Thought this would be fix in 1.5.1... Just put up two pictures showing my animals getting stuck on the corners of my fences...

Used to keep over 128+ chickens penned in a small area with none escaping in 1.4.7
In 1.5.1 my surrounding terrain is being overrun by escapees! I've had to discontinue my animal farming so far as having a farm on top a sheer side of a cliff makes for difficult work removing chickens on the wrong side of a fence.

Just thinking... In 1.2 I had no problems with escaping animals. In 1.4.2 they started to escape through fences to the north - placing double fence on this side was sufficient to keep them inside. But now in 1.5.1 they escape literally everywhere! It's really annoying ang getting worse :/ I would be sooo happy to have it fixed...

This always keeps on happening on my world so it is very annoying.

Added a screenshot. I put sheep in the area, reloaded the world 2 times and the baby sheep glitches into the fence and gets out.

this is fun

I've had cows escape through stone brick walls two blocks thick. I've seen a dramatic increase in this since 1.5 came out, with all of my active testing occurring in 1.5.1. I've recreated it in three ways. I've enclosed cows in a pen with 2 opaque-block thick walls (stone brick) on a server and in my creative world. Logging out of the server causes cows to escape if no one else is close enough to keep the chunk loaded, exiting my creative world causes them to be released, and going far enough away in either brings escapes. I agree with the others: any time the chunk unloads and loads, the animals can escape and/or be misplaced out of the pen.

This happens to me with blocks that take a full space too.

I've had chickens dying in the walls all over the place ever since updating to 1.5.1. I did not have this problem in some of the earlier 1.5 dev builds.

I had a dog die in a wall when I walked back in a chunk. Will miss you Yapper.

You have my most sincere condolences

RIP Yapper

R.I.P. Yapper. We love you!

It also happens with villagers and Iron golems.

I think I know why this is happening. When a animal/mob collides with a wall the game saves that mobs moment when you save the world or leave the chunk. The game generates entities first. That why you sometimes find mods bottom half's stuck in blocks. So when it generates entities the mobs start to move again causing them to go into blocks. Make sense?

I have watched this happen when I stood next to the fence. I held some wheat up for the chickens to see where the fence was failing. I thought maybe if I destroyed it and put it back it would help.
I SAW the chicken walk through the fence and I replaced that piece of fence. To no avail.
Please fix this bug, it's extremely annoying!!!

Merel van Empel said "I SAW the chicken walk through the fence(...)"
Same here. Moreover - it happened also with cows and sheep, although chickens' escapes are more frequent. Like Michele said - it happens also with villagers, they escape right in front of me. It's difficult to turn them into prisoners now 🙂 Fortunately none of my villagers managed to escape double fence, so there is hope.
Please fix this bug, thousands will be happy...

@ Aaron Loyd:
That's one of the reasons that I thought is causing this. That probably the game loads entities first then the blocks, but I suppose something like that would be to obvious and Mojang team would certainly have thought of something so simple.

This kind of bug happened only "relatively" infrequently in version 1.4.7.

However, as of version 1.5.1, every single time that I return to my home area, lots of animals are out of the fences. In the case of chickens it got so bad that we quickly went from 25 chickens in the chicken coop, to only a handdful, despite 1 breeding sweep each time we returned home.

We even had a sitting siamese cat seemingly disappear altogether (it was ordered to sit directy by us, and directly on the floor, not near a chest-bed-furnace!) Later we found that same cat again (we had only 1 cat on that map so there could be no mistake), it was still sitting, immobile, but it was not in our underground house but outside beside a river, only a few chunks away! I'd say it got "shifted" by an offset value of about [ X+50, Y+5, Z+10 ].

I'm not talking about animals "walking through" the fences, albeit that could also be possible. I'm talking about leaving the area, so that the chunks unload, then later coming back straight to the farm by running, and finding that animals have "magically been transported" relatively far away from the farm, as if they were not reloaded in their proper spot.

Weird and most of all very annoying. This completely "breaks" all farms using fences.

This is really annoying. In a new survival world, I wasn't able to get a proper cow farm going (starting with 2 cows) because every single time, the baby cow escaped or ended up suffocating in 2 thick cobblestone walls.

I really hope you can address all this buggy mob behaviour soon.

Assign this bug to Jeb or Dinnerbone. The community hates this bug so please get it fixed.

If this helps, animals are only escaping pens on the west and sometimes north side in my world. I have been playing in this world a long time, and I have about 188 animals in 19 different pens, so I am certain of this favoritism in the code.

I have posted a screenshot demonstrating that animals tend to escape on the north and west sides. Also note I have never seen a pig roaming the paths or in my cow farm.

Animals are actually not suppose to move when the player is more than 35-50 (dont know the exact number) blocks away. (As seen in SethBling's 100% undetecable trap.)

Don't see this mentioned in the notes anywhere: I've just witnessed a bunch of cows escape by aging. It looks like the same problem.

A group of calves pressed into a corner. As each one aged, the game seemed to lose track of whether they were supposed to be inside or outside of the fenced area, and outside seems to win out.

I have also had this problem as of late, which is frustrating because I have a home in the swamp biome and cows are almost nonexistent; I don't want to lose all of mine. I also noticed the get stuck in the corners of the pens.

I am on a Mac and it happens on both operating systems.

I can confirm it's quite annoying because I have a farm. Happens when reloading world.

http://youtu.be/0H7Fwol9sYU

Chicks receiving suffocation damage and dying during chunk loading; escaping their enclosure; entering the inside of transparent blocks (glass) which entraps them for ever. Holding seeds will only make them look at you but they won't move they won't leave the glass block for any reason (unless maybe when another chick gets pushed in the block, pushes an entrapped chick out of it).

31 out of 54 chicks survived.

Yeah, this is pretty annoying, also the animals seem to get suck in the corners and edges of the inside fenced area. Thanks to who ever is currently assessing and solving the issue.

I can confirm too that this bug has returned in 1.5. I've had a few of my cows escape their farms. It's even worse when some of them suffocate and die.

This sometimes happens to me when sleeping, cows would be suffocating when you wake up. (MC 1.5.1)

Odd. The 1.5.1 change log of the wiki says it was fixed in 1.5.1

@Aaron Loyd: If only. My cow exodus continues.

The wiki's not as clear as it could be: MC-2025 is listed under bugs still outstanding.

Chunk loading may make it worse, but isn't required; I can stand right outside the fence and watch the little buggers push through. It may also happen more frequently at corners. Replacing the corners with solid blocks seems to have reduced, but not eliminated it, though sometimes the animals suffocate in the solid blocks.

@Aaron Loyd: In the changelog MC-2025 is not under fixed bugs. It is under popular bugs of version 1.5.1
http://www.minecraftwiki.net/wiki/Version_history

Some corner in fenced areas are especially popular witht the inhabitans, for me parts of the inhabitants (cow&sheep) are pressed against some corners and they sometimes escap. Maybe through this cooperation?

This still happens in the 13w16a - not only on chunk loading, mobs glitch into blocks where they die (suffocation presumably) This is most common with baby mobs when they grow.

Baby Cows passing through glass and solid blocks, some of them were suffocated.

Interesting update: Everyone on my server is having this problem except one guy.
He has two properties, one due north of the other, along approximately x=512, with both properties in the - Z range (one is at z= -20, the other at z = -1024)

He has had zero cow, chicken, or pig escapees, and no suffocation deaths. He has pens that are free-standing fence enclosures as well as ones that are butted up against walls.

However, due south of him, in the positive Z range, I have cows and chickens phasing through walls. that's only 70 blocks south of him (it's our spawn village).

May I suggest that people report the location coordinates when they report the bug. There might be a pattern.

I'm so glad this issue is being addressed.
This issue is also present in PEACEFUL GAME MODE.
My duckin (duck/chicken) coop, I get only suffocations (no known escapes) in either of these natural, dirt & stone enclosure coops. Note that most of this natural enclosure is far more than 2 blocks thick - it's a small valley-like area.

In these relatively large farms, I keep about 250-350 duckins (measured by how much feed goes out before saturation). Some of the deaths are likely trampling deaths from my running about, but they continue whenever I am in the area. I can hear them, then run back to the coop to see the corpses floating - a one-to-one correspondence: pne "death cry" per corpse.

There is a thread on the forum about this (http://www.minecraftforum.net/topic/1725706-15-animals-escapeing/page__st__60 ), someone was able to capture the moment the sheep walked through the fence on video: http://www.youtube.com/watch?v=ATMmO-1OW2I

And this wasn't on chunk loading, this was in the middle of game play. Not sure if this means this is a separate bug?

And yes, this is a much larger problem in 1.5.1 than it was in 1.4.7.

Brad, that video claimns to catch the moment sheep escape fences, but it shows only the "before" and "after" moments, not when it happens! So its only good for wasting the viewers' time with mostly useless blahblah.

Personally, I actually saw a sheep escaqe from it's fenced pen during the game, right in front of my eyes, and only a couple blocks away from me! I was all "What the...? That's just weird!"

So the only important thing to know is that animals can escape even if the player is standing immobile and near the animals, i.e. like you said when no chunk are being loaded/unloaded. And that this escaping can occur even when the animal "density" in the enclosed space is not that big (sheep-to-'fenced area' ratio is less than 2/3). Or even without other animals right beside it.

We must have been watching two different videos. The one I saw showed two sheep blithely walking through fences.

Patrick, watch the video at 1:00 to 1:06, then watch from 2:15 to 2:25.

If there's some definition of "seeing it happen" that makes your experience valid, but that video invalid, I would love to hear it.

Moving on:
I would love to see a chunk-loading caused event, specifically the ones where animals pass through solid blocks, not just fences. I'll try to put some time aside tonight, and record it myself. Maybe in different quadrants of the map, too, to see if coordinates effect results.

The problem is still occurring in 1.5.2

and in snapshot 18C, animals push against fence boundaries before popping through them. If you use the old make a pit and place fences in the lower level the mobs get trapped between the fence and the block preventing player from clicking on them or killing them without destroying the fence.

This is really annoying, I have a survival world with all my animals fenced off and now they are wondering around everywhere activating my redstone contraptions, pushing my minecarts around and blocking the rails

happens without reload, too. I saw my pig walking through the fence as if there wasn't one. I killed it and the drops were outside, too. I used to have 4 adult and 2 baby pigs. Now I have only 2 adult pigs left. 😞

This is really annoying, please fix this soon.

why is this not on the top of the issue list?

Really thanks Workday Lobster for pointing how much I was in error there! And thank you Brad Corbin for giving us that video link (cut & pasted below), and very sorry for my blunder! It's my previous post which is totally invalid lol!

The video does indeed show the upper left white sheep moving out at exactly 1:03, and show the white sheep in the lower right corner escaping at exactly 2:22 (at night time but it's still easy to spot).

http://www.youtube.com/watch?v=ATMmO-1OW2I

I just can't believe how I totally missed BOTH of these 2 "escapes", despite having watched the video TWICE. "DUH-Facepalm-And-All-That". My eyes must have been playing really bad tricks on me that night lol! Again, sorry and thanks a lot.

Still, now that I have my full wits about me (should never post stuff when tired!), I must say that it is extremely interesting to watch the sheep's behavior here in the video when they escape, particularly the differences and similarities:

-> In the 1st escape, the sheep is more or less immobile, and there is a grey sheep that is being "pushed" into the white sheep, twice, and then the white sheep comes out, it's a very calm movement, but as soon as it is out of the fence it turns left (not abruptly , with the grey sheep (still inside the pen) bouncing back aside (toward the right).

-> In the second escape, the sheep seems to want to go left, but a sheep is already there. Again, it is the SAME grey sheep! Is that a mere coincidence? And then the white sheep seemingly has to very quickly turn back counter-clockwise ending up facing the right fence, again it occurs twice, and then the sheep simply walks out, and again turns as soon as it comes out, this time making a right turn (and again not abruptly).

Maybe we need another video? This time with 16 sheep instead of 10, and put inside a 6x6 pen instead of 5x5 (with the width including the fences blocks). Each sheep should be of one of the 16 possible colors, allowing easy "sheep tracking". In fact, each seep should be renamed using name tags to a number from 1 to 4 indicating the pen it originally comes from. This way sheep escaping from one pen to another could also be detected easily.

Also, to avoid night scenes in the video, a daylight detector would be set up to detect the slightlest lowering of the light, to power a Control Block that resets the time to the moment of the beginning of the day when maximum illumination is already reached.

Finally, instead of using only 1 pen, we should use 4 pens, placed in a 2x2 configuration, with shared fences in the middle parts. Thus, with 64 sheep instead of 10, we should be able to capture about 6 times as many escapes for the same length of video taken. A couple hours of video capture should be enough to capture lots of escapes, and ultimately trying to find some kind of pattern.

This happens to me too! It's so annoying... :/

This is a really annoying bug. It makes the game unplayable to me (survival). Please fix it asap.

I am having this happen without any chunkloading. I will simply turn around and there will be escaped chickens everywhere. Should I make a new report? I was not having this problem with 1.4.7. I am using 1.5.1.

Im having the same problem as jakobzucker too. I have 5 chickens in a pen, I go to my house then go out and 2 have escaped. The pen is in the same chunk too. I tried putting two fences round it but the chickens glitch in between the fences and get stuck.

I've just started having this problem with my sheep and cows. They are in a fully enclosed fence that is 1 block high and I have been having huge problems. I even saw my red sheep just walk right through the fence! I then replaced the sheep's fence with a two block high wall of cobblestone blocks, and it seems to be fine now, but I need to do more observations. I didn't have enough resources to do the same with my cows, so I just added a layer of dirt over the fence and seems to have worked as well. I just started the world I'm playing in a few days ago, and I'm now having these problems, which I've never had before. My house and both farms are on the same chunk too. Oh, and just sleeping at night seems to get my sheep/cows to escape. I have been containing the cows fairly well; when one escapes I kill it for beef/leather, then breed more, but I can't really do that with my sheep as easily because each one is a different color and they are more useful alive. I even noticed some sheep just flat out gone (probably just ran off after escaping) because my catalog where I keep track of my sheep shows some that aren't there (I keep VERY good track of my catalog being these sheep I made with dyes, and I don't want to lose or duplicate any. I hope this can be fixed, because the my sheep look like they're in prison, and fences are much easier to make than cobblestone is to obtain. I am also on Windows 8 with Minecraft version 1.5.3. Not quite sure what java version it is...

In 13w19a

13w21a: mobs can still escape out of fenced off areas.
_{my wonderful 16 colored sheep collection is rambling through the village}

This is a serious problem on my server. Every time anyone logs in, our animals are scattered throughout the area and whoever is there has to spend a half hour or so gathering all the animals back up.

fences are near useless now.and the issue has been made even worse from the hitboxes being reduced even more.

this also poses a serious problem for chickens,since opaque blocks can cause suffocation when they start crowding into corners, leaving very few choices on blocks usable for walling off chickens

This bug isn't limited to fences, and no block can wall off any mob forever. Unless you check on them every time you're in the area, they will either escape or suffocate, regardless of what blocks you use.

EDIT: For clarification, this is just referring to using any block to wall in your animals/villagers/whatever. Obviously, 7-long flowing water pushing mobs back towards the center of the pen will stop escapes/suffocation in most cases.

On startup, I just got a flood of console messages that seem to relate. (This world has a chicken farm nearby, which is a water-containment system.) Gameplay is very jerky, a reason for which is suggested by the messages.

ETA: PC version 1.5.2 on Ubuntu.
ETA 2, sorry: I had just started a new generation on the chicken farm, so these are all chicks.
ETA 3 (but new information!): And yes, a bunch of chicks (and within a few minutes, chickens) were completely outside the pen, while a bunch more were stuck in the fence. (This despite the water flow supposedly holding them in.) As it turns out, that generation of chicks was just growing into chickens, so now I've got chickens outside too. The messages and "lag" have continued from dawn to dusk. And just to make it clear, this is new: Even if I'd missed the console messages (unlikely), I usually have a bit of lag when starting up, but then it goes away once the nearby chunks are loaded. This is staying, and it's making the game nearly unplayable.

Here is a sample message:

2013-05-28 17:33:10 [SERVER] [SEVERE] Wrong location! qi['Chicken'/97234, l='Heavy Duty', x=299.52, y=67.00, z=-1002.52]
java.lang.Exception: Stack trace
	at java.lang.Thread.dumpStack(Unknown Source)
	at abw.a(SourceFile:504)
	at aab.a(SourceFile:1360)
	at iz.a(SourceFile:508)
	at aab.g(SourceFile:1314)
	at aab.h(SourceFile:1221)
	at iz.h(SourceFile:390)
	at net.minecraft.server.MinecraftServer.r(SourceFile:462)
	at net.minecraft.server.MinecraftServer.q(SourceFile:397)
	at bjg.q(SourceFile:122)
	at net.minecraft.server.MinecraftServer.run(SourceFile:331)
	at gp.run(SourceFile:573)

And ETA 4: Getting new messages – besides the above about chickens, I'm getting similar messages for zombies and even eggs!

2013-05-28 18:07:01 [SERVER] [SEVERE] Wrong location! sj['Zombie'/374175, l='Heavy Duty', x=289.70, y=66.00, z=-1006.30]
java.lang.Exception: Stack trace
	at java.lang.Thread.dumpStack(Unknown Source)
	at abw.a(SourceFile:504)
	at aab.a(SourceFile:1360)
	at iz.a(SourceFile:508)
	at aab.g(SourceFile:1314)
	at aab.h(SourceFile:1221)
	at iz.h(SourceFile:390)
	at net.minecraft.server.MinecraftServer.r(SourceFile:462)
	at net.minecraft.server.MinecraftServer.q(SourceFile:397)
	at bjg.q(SourceFile:122)
	at net.minecraft.server.MinecraftServer.run(SourceFile:331)
	at gp.run(SourceFile:573)
2013-05-28 18:07:01 [SERVER] [SEVERE] Wrong location! rh['item.item.egg'/375648, l='Heavy Duty', x=302.23, y=67.13, z=-992.13]
java.lang.Exception: Stack trace
	at java.lang.Thread.dumpStack(Unknown Source)
	at abw.a(SourceFile:504)
	at aab.a(SourceFile:1360)
	at iz.a(SourceFile:508)
	at aab.g(SourceFile:1314)
	at aab.h(SourceFile:1221)
	at iz.h(SourceFile:390)
	at net.minecraft.server.MinecraftServer.r(SourceFile:462)
	at net.minecraft.server.MinecraftServer.q(SourceFile:397)
	at bjg.q(SourceFile:122)
	at net.minecraft.server.MinecraftServer.run(SourceFile:331)
	at gp.run(SourceFile:573)

@David Harmon: Your world is corrupt, see MC-3766.

Tails: Thank you, but: "FFFFUUUUUU.....!" For future reference, here is a Forum thread where someone's trying to fix corrupted saves: http://www.minecraftforum.net/topic/137381-official-corrupted-save-recovery-thread .

Now I just have to figure out where online I can stash a 57M world file for them....

@Tails: You seem to be watching this issue a good amount. Can you tell us if anyone's looked into fixing it yet? I see there's no assignee yet, but it does seem to be a popular issue.

Thank you for reporting this, at first I wasn't sure this was a bug. I have a cow pen using only a wooden fence perimeter, and I noticed that after breeding the cows - which made the cow pen a bit more crowded and congested - when I left the area a good ways and later returned home, there would sometimes be 1-3 cows outside the pen walking or standing about. However, I had so many cows in my large pen, I was not sure if they were my cows, or randomly-spawned cows. (Cows did spawn in the area prior to me building a house and pen on the land). Unfortunately, I am ignorant to how the mob spawning system works in Minecraft, and I thought maybe "wild" cows were continuing to spawn, or that a large group of cows could possibly trigger the spawning of random "wild" cows. Oh, and in previous builds of Minecraft I've seen animal mobs (pigs, cows) walk/push half-way through fencing before, but never actually get through the fence or take damage from it. From this report I guess I can assume the "stray" cows are mine episodically glitching outside the fence when I explore outside the vicinity of my pen and then return home.

so has the issiue with the animals beying outside the fences been fixed yet because everytime i make a animal farm all my animals escape and its very annoying

No, cause the status would've been changed.

Mojang PLEASE fix this! This makes it almost impossible to set up automatic farms! This is ridiculous!

Forget automatic farms, it's impossible to set up any farm without animals escaping or suffocating in walls.

Forget farms, it's impossible to set up any enclosed area with any sort of moving mob, without them escaping or suffocating in walls.

And even with the upcoming leads, Docm77 has shown that they have a tendency to break when they're at the boundary of the render distance (his latest World Tour vids). So I have a feeling even lead-based farms are impossible, unless Mojang fixes that. Which would suck if they fix leashes, but still let our animals phase into the walls and die.

This is incredibly annoying and should really be fixed. It makes animal farms near impossible.

If someone here is going to visit the next Minecon, try to confront the devs with this issue on one of their Q&A sessions. I'd like to know their reasons for not addressing this issue all these years. If it's a technically hard thing to fix, or if they simply forgot about this, or if it even is a wanted behavior to make farming animals harder.
But this silence of the devs about this damn old and damn annoying bug is really going on my nerves.

You've actually just illustrated the problem with "all these years." It's not one issue, and in fact, most of the issues affecting older versions have been fixed (I didn't say all!) The reason for the majority, at least, of recent complaints is that this problem came back in full force when the hitboxes were changed for baby mobs. Something was altered in the way hitboxes were calculated across the board, or in how they interact with other blocks, and this became a serious problem again.

Unfortunately, it's the same report as an ongoing series of problems so I'm not entirely sure it's even being seriously looked into because it's just that same old issue. Watch the people doing Let's Play videos. See how many of them are dealing with animal escapes or broken farm setups. They're not making a big deal about it because whining and complaining does not make for entertaining video, but they provide ample evidence that this is a New problem.

Zaecus: Actually, the first I remember of this bug showing up was when they altered collision behavior, so that cats and dogs couldn't shove you off cliffs ad such. That seemed to affect all mobs' interactions with blocks as well.

Well recently I have opened up the code to check this problem out. I am 100% sure baby animals are phasing northwest every time the player saves, quits, and reloads. Their position is being saved and/or loaded incorrectly in the NBT format, probably due to their reduced size. In fact, place a baby animal in a fenced area and then repeatedly save and load; you can watch it move. With a few more hours of prodding around I could probably fix it myself. However, I cannot reproduce large animals phasing through walls, even on a copy of my own save file which has been plagued with the problem. They appear to be saved and loaded to and from NBT perfectly fine. I hate to say this for fear of being wrong and causing a legitimate bug to be ignored, but I am beginning to think the issue may be largely bukkit related. Has anyone had an animal phasing problem on singleplayer or an unmodded server? If so, I am wondering if time is a factor. For example, perhaps after a long period of having an entity loaded it gradually loses track of its exact location, thereby allowing it to phase through a wall upon saving and reloading.

What is bukkit? I only play unmodded single player and have adult animals phase into walls all the time, most especially on reload.

Daniel: I am playing on an unmodded Vanilla server, and have had this problem with adult cows, and occasionally adult chickens.

I know that the server is unmodded because I'm the guy that runs it.

I have had cows phase through stone block walls up to 2 blocks thick, without logging out: if I go far enough away for the chunks to unload, it happens. What is interesting is that this is in the server "spawn chunks", the chunks around the natural spawn that are always loaded no matter where you are in the over-world.

What I have not tested is if this only happens in the Spawn Chunks, or if it's map-wide. It may have something to do with the chunks operating when no one is within render-range.

Hmm, interesting. I play on a lightly modded server I run and I have this problem frequently.

What I have found without question is that baby animals save and reload incorrectly. What is odd to me is that in all of my control situations I cannot replicate larger animals phasing through walls, but I know it happens to me all the time when saving and reloading my actual game. Possibilities I have considered are problems associated with many entities going through memory or entities losing track of their exact position over time for some reason. Regardless, the tests I have done have not triggered animal phasing, even on a copy of my save which has this problem. I cannot figure out what is causing it.

Choc Wise it is an old/new problem. The initial problem was fixed and there was much rejoicing. When we had the original problem the fix was to dig one block down, fence the inside of that block and pen the animals that way which kept them, mostly in place. The developers addressed the problem and you could start using fences properly.

It does still seem to work but in the case of chickens they now get stuck in the small space between the fence and the block and you cannot interact with them. I haven't been on recently since I did this but I think it solved suffocation and escapees.

Unfortunately too much effort I believe has been placed by the developers in adding new features that many of us probably will not use such as much of the recent redstone items. Most of which are completely useless in survival. For me anyway since I have not built anything using creative type tools since before survival was released.

The performance of the PC in question, I would say, has nothing to do with the issue. I still have the issue but run into the hundreds of FPS. It is great that Minecraft is popular, and that time and effort is still being invested in it but recently I find the developers are going off into their own little world (polite way of saying) and the result is you have devs blaming peoples computers for the massive FPS drop of terrible coding. Rather than tweak the game to give people what they want, essentially more block types to build with they are changing direction in a way that is A) breaking the game or B) driving original players away.

"Unfortunately too much effort I believe has been placed by the developers in adding new features that many of us probably will not use such as much of the recent redstone items. "

Aaaaand you lost me right here. I use the new redstone stuff all day every day in survival, and I love them. And, I applaud the developers for continuing to try to advance the options and features of the game WHILE continuing to crush bugs in the game. Complaining that they're adding new features instead of placing their entire task-force on bug-fixing just because you don't use the new stuff is silly.

I have a feeling that this glitch is a very, very deep and intricate one that is very difficult to repair without causing massive performance drops. Likely, a robust solution eats up RAM like crazy, and the Devs simply haven't hit on an elegant solution yet. Don't jump down their throats for also trying to add new stuff.

EDIT: I apologize for being harsh, because I was.

Up until recently I have been frustrated with the 5 new feature - 50 new bugs thing Mojang has been doing, but I am glad they have stopped and devoted a lot of time to squashing bugs recently. The features are not bad; I really like a lot of them. It's just that I would rather have a more functional game. I can definitely understand frustration toward the lack of bug fixing. That being said, they have been spending a lot of time fixing bugs lately, and I am very relieved about that.

As for this bug, I cannot imagine the problem could be that deeply rooted. However, I did not start reading Minecraft code until yesterday. It would certainly be easier if they did not obfuscate the snot out of the code. I am trying to figure out exactly at what point in the code baby animals place themselves into the world incorrectly, and boy is it hard to figure out what ambiguously named fields are. I found the general area where it looks like they are setting their bounding box based on the wrong dimensions, but I am not sure what variables are supposed to be referenced.

In the mean time I am leaving my testing file on with my animal farm sort of half loaded in the distance. Hopefully (dare I say) this will cause my animals to phase out of their pens. Then we can narrow down the causes of the problem.

"Complaining that they're adding new features instead of placing their entire task-force on bug-fixing just because you don't use the new stuff is silly."

I have nothing against new features. But adding new features in one hand and breaking core stability of the game on the other hand is not good. Secondly it is unlikely a huge problem. It is very likely they know exactly what caused it as it has been fixed before. The fact that, after all this time, they have not assigned "anybody" speaks volumes. Yet they continue messing the game in various ways. I did not complain they were adding new features nor did I ask for everyone in the office to work on it. You were not being harsh you were twisting my words to suit your own interpretation. They can continue to add features I see as pointless as long as the game itself isn't affected. I can choose not to use those features.

The Devs put a lot of stock in the "Redstone Update" I am glad you find the update useful and use the content. I am sure many others do as well. Recently there has been many reports of them "squashing" bugs. Most of those bugs were caused by them not sufficiently quality testing the patch and pushing it anyway. This is a core problem with developers these days, releasing unfinished garbage without allocating time to test and troubleshoot. The Redstone update reduced my framerates by well over 60% to the point where I had to use a player created mod to increase frame rate and had the bonus of actually making the game look better at the same time.

Minecraft is one of the those games that never really needed massive new updates or content. I would place a fair bet that a significant number of players just want simple things like different textured blocks or coloured glass. Judging by the huge number of player created content.

Lastly a number of people seem to be focused on the chunk loading and unloading, or saving and exiting. I have stood and watched a chicken run at a fence post repeatedly pushing at it until it goes through it. The chicken, a full grown one, did not appear like that. It started in the middle of the pen and moved against it. If you notice the behaviour of all the animals they repeatedly push against fences. The problem does relate to smaller animals only as I've never seen it occur with a full grown cow or sheep. It is also prone to occur if your pen is overcrowded.

You are right about the issue not necessarily having to do with chunk loading. However, I will not rule out the possibility that this bug is actually a set of bugs which all have the same net effect to game play: releasing or suffocating the player's animals. In fact, based on what I found with baby animals I am certain it is at least two separate bugs. I placed 200 chickens in a 4x4 fenced in area and one escaped within a couple minutes. Was the chicken you witnessed pushed by any other mob when it traveled through the fence?

EDIT: I have now witnessed 4 chickens completely escape the inner pen without any chunk loading/unloading. Two on the east, one on the north, and one on the west. I am now convinced the apparent northwest favoritism of escaping animals is only a consequence of the northwest favoritism of movement.

EDIT AGAIN: I have done the same thing with 200 cows and they are indeed escaping as well without any loading/unloading of chunks. The cows escape much less frequently than the chickens did. Probably because they have to get more of themselves through the fence before the game pushes them outside the fence.

I agree, I think there are actually two issues here.

I too have looked into the code before (try MCP if you want to look at less obfuscated code) and had come to believe there were a couple issues. One where they would run through the fences which could potentially be attributed to the AI and/or the new moulded fence blocks. And a second issue where it's placing them in the wrong spot when loading them from NBT.

In the case of when they run right through it this could be an issue with AI, however they still shouldn't be able to go right through the blocks. The fence blocks are new and this is where I have noticed baby mobs going through. The fences have the exact shape now, there seems to be a hole in them (for some reason this also causes lag issues with the lighting transparency on lower end computers). Has anyone seen a mob run right through any solid block, not a fence?

In the case of them loading in the wrong spot, I've tested and seen they will load outside of the area a few blocks away. There is no running through the block, they just simply load in the complete wrong spot. They will even load inside a wall or wherever. I can't be sure if it's an issue with loading or an issue with saving but I would bet with loading. It seems this will happen when a chunk loads but not every time a chunk loads.

These two issues may not even be related in any way other than mobs are escaping fences.

Yeah, I think we basically have three bugs here:

Mobs walking right through fences (mostly chickens accomplish this, it may also be why items can occasionally fly through blocks, especially in mob farms)
Baby mobs shifting northwest every save and load
Mobs being occasionally loaded what seems to be a space or two away from where they should be (This is the biggest problem for cows, sheep, villagers, pigs, etc.)

I can say with confidence that walking right through fences is a problem in collisions, which I personally have no experience with and would not begin to know where exactly the problem is. It would appear that if a mob hits a wall hard enough at the right time they will phase right through. The effect is more extreme on smaller entities and thus is especially true with chickens. The baby mobs shifting northwest is a problem with loading from the files due to (I am nearly certain) calculating their position as though they were an adult. This is just a guess, but the same effect might happen if a baby grows up right next to a fence. And finally there is the loading inconsistently into the wrong location. I have no idea what is causing that. I am having trouble replicating it, but it plagues me during normal game play. Somehow it is occasionally writing or reading the location of entities wrong. It only occurs during loading and unloading of chunks.

Please stop submitting comments multiple times, and wandering off topic.

It may be worth noting that this is not limited to farm animals. Mobs also phase through blocks all the time. I have an xp farm where I frequently see spiders in particular phase through the walls, then snap back inside. It also happens with zombies, and I'm pretty sure skeletons, though now that I think about it, I don't think I've ever seen creepers do it.

The graphical glitch of mobs yoyoing back and forth between two locations may be related, but it's not the problem of mobs actually escaping, just a visual trick. The very first indication I had of the problem of mobs actually walking through walls was when a creeper walked out of my glass mob fountain in the middle of my artistic base so yeah, it happens with all mobs.

Phillip, nobody has been posting anything multiple times - you just get multiple emails when there's an edit, sadly.

Also, the last three posts (before yours) are definitely on-topic. I think I agree that there's more than one bug at work here. Although chunk reloads causing mob displacement is the easiest to observe (and perhaps most problematic), I'll admit I've also had entities wind up in places they simply could not have, even without chunk reloads. I had a villager gradually clip past a fence and stand on the outside edge of a balcony (a position inaccessible even to players without enderpearls or block placement), when my friends and I were in the village the whole time. We actually noticed him a few times up there - at first he was on the correct side of the balcony fence.

I've also had countless farm animals get stuck in fence corners and eventually escape the wrong way - even in spawn chunks, which are always loaded (I can tell they're always loaded because all of the grass has been eaten every time we return).

Lewis, I did not twist your words, and I take exception to the claim that I did. You complained about the devs focusing too much on "useless new features", and then said they were "breaking the game". I acknowledge that I'm off topic, and won't carry this further, but I was responding the the real, actual words you posted, and I don't appreciate you saying that I twisted them when they're right there.

It is a really good point that this might be multiple issues overlaid, I have to admit I hadn't considered that. I'm also wondering: Is the adult glitching happening in new worlds, or only old ones? Daniel King mentioned that he wasn't replicating it, but that it happens in his main world. I try to test it from time to time in new worlds, and it won't happen, but it happens on my server, in chunks generated back in september 2012.

If anyone else is experiencing adult mobs phasing through things, when was the map, and that section of the map, generated?

Not sure if this helps, but I have a CraftBukkit server founded 2013/02. I used the current version then and I've been updating to newest versions. When I've teleported to my home, I've noticed some baby animals have moved outside the fenced area or inside a wall. I haven't noticed adult animals have any issues. Is the issue related to the size of their hitboxes?

You guys seem to be bickering a lot, but then I'd also be off-topic...

I can confirm this happening to my chickens, sheep AND villagers (because I made a village in my backyard) on my world created back in August 2012. Hitbox size probably makes a difference in frequency, but it still seems to happen to most/all mobs every so often. I often find myself fighting with them to push them back inside their pens, but just watch them pop right out. It gets rather annoying.

An interesting note: I've been able to push myself into blocks under certain circumstances, such as the double chests in my storage room. So, in a way, the issue may persist in even the player.

I can at least confirm that the hitbox of blocks does make a difference. Try making a pen out of anvils two blocks high. I'm almost positive they'll escape very frequently.

Sorry to post yet again, but I have been actively working to diagnose and solve the problem the past couple days with MCP. Baby animals glitching through walls has a separate cause from animals in general glitching through walls. It is caused from their size not updating until the first game tick after loading into the world which causes their setPosition method to place them in the wrong location. I was able to fix that bug in my tests by moving the setPosition method in readFromNBT to after the helper method readEntityFromNBT and calling the size update method func_98054_a(isChild()) at the end of readEntityFromNBT in the EntityAgeable class. *** Mojang, please fix that

As for other mobs glitching through walls, there is a consensus that there are two distinct situations: Mobs, especially smaller ones, walking through walls during game play and mobs being spontaneously loaded outside of pens and inside of walls on occasion. I am still working on a solution for these. I have been reading loading, collision, and path-finding code.

Of the people who are having large animals glitch out (the third and arguably most annoying one), does everyone have their farms near the spawn? Workday Lobster mentioned spawn chunks behave differently from normal chunks, and I think that could be important.

If anyone is unfamiliar with the Spawn Chunks, but wants to test this (for science!!), here's a video that Queen King Happy did regarding them, including how to identify them. The identifying part is the first 10 minutes or so. http://www.youtube.com/watch?v=BqKaE4bkhfY

I've seen it happen at ranges anywhere from a few blocks to 1000 from the spawn. Happens in new worlds too.

I think the core of this problem may be that living entities don't get pushed out of blocks at all. If the tiniest miscalculation causes an entity to intersect with a block they just walk through. If you drop a block of sand on a chicken and just barely touch it the chicken will stay still and suffocate unless it is pushed out. I know which part of the code pushes items out and a different part of the code pushes players out, but I find no code and no evidence that the game makes any attempt to correct when an animal collides with a block.

I have seen this problem occur quite regularly on my server. It seems to be worse the denser animals are within the pen.

Daniel, your findings just reminded me of something very peculiar I once saw. I literally witnessed a villager walk right into a wall and suffocate on a server I played on. I hadn't thought of it until now, as it had been such a freak occurrence that I chalked it up to the server running Bukkit, but I never witnessed anything like that on that server (or any other) since.

Does the code suggest floating point error could actually cause a hitbox to intersect a solid block? If this is true, and entities indeed are not pushed out of walls, then it's entirely possible that the imprecision of floating point calculations could cause their hitbox to intersect a solid block at some point (extremely rarely, of course!). This, in fact, would explain why it can happen for any mob with regards to any block. It might also vie for directional favoritism, although some detailed analysis may be needed for that.

If FP calculations are the cause, then the problem would likely get worse as you approach the far lands, unless a mob's coordinates are considered relative to the chunk they're contained in (I know mobs are stored in chunk sections even at runtime). Furthermore, if there is a directional bias, it would likely be biased towards the origin and thus depend on your quadrant - northwest bias would only be expected in the southeast quadrant, which is when your coordinates are positive on both axes.

As to why this seems so common when chunks are unloaded/reloaded, compared to its rate of incidence when chunks are active, I have no idea. Unless the coordinates stored for entities get horribly rounded during the serialization/deserialization process (i.e. casting to Float anywhere along the lines - but afaik it remains Double the whole time), there's really no reason for the bug to be more common after a reload. There may be more to this bug yet - but surely, pushing mobs out of blocks the same way players are forced out would probably reduce overall incidence dramatically.

Whatever the issue is, it is a small, uncommon issue in the collision code which eventually happens given time and opportunity. It could be a cast to float but I would say it is more likely just some bizarre hole having to do with movement and updates. I have not used doubles extensively, is it possible to have a freak double calculation error? In every occurrence of this issue, it seems that the mobs occasionally shift just a little bit into walls and then either walk through on their own or are pushed through by nearby mobs. It is probably aggravated by mob AI which leads them to walk along/into walls. I have just been thinking that if and when entities find themselves in blocks they temporarily ignored entity collisions and are pushed from the colliding block these problems would both be resolved. That is, assuming the entity is able to realize it is in the wall before it moves more than halfway through.

EDIT: I guess such an operation should be attempted every update before the game begins doing suffocation damage. I would think that is often enough.

I'm experimenting with hundreds of cows in small pens, and from what I've gathered, there is a substantial bias in the direction of the origin. If you spawn cows in manually, the directional bias will be towards the wall/corner you spawn them against, but if you drop them via a downwards-facing dispenser at the center of the hole, they seem to split off into four groups (one at each corner of the pen), rapidly shuffling between these groups. When you reload the chunks, the escapees seem to be more common towards the origin, regardless of what direction that may be.

I'm experimenting some more and preparing a test world right now, but bear in mind this doesn't confirm the floating point theory - it could just as easily be that the cows tend towards the origin due to FP calculations, as clearly cows are always escaping more often in the direction where they are in higher concentration. That is to say, if you spawn cows in the corner opposite the origin, they will tend to escape away from the origin: it could just be that spawning cows at the center of the pen makes them automatically tend towards the origin when shuffling, failing to reliably confirm my idea that FP calculations are to blame for the bug itself. It does, at least, support the notion.

EDIT: I did some more testing, and it actually seems more or less random - sometimes the bias is towards two opposite sides. Sample results for each quadrant:

• + + 10N 1E 3S 3W; 6N 2E 2S 10W; 10N 6E 5S 4W

• - + 10N 4E 2S 3W; 7N 7E 3S 1W; 11N 10E 3S 3W

• + - 4N 6E 4S 3W; 5N 3E 9S 5W; 4N 2E 8S 4W

• - - 4N 6E 4S 1W; 5N 11E 6S 7W; 1N 3E 4S 0W

~200 cows per pen each trial; trial data separated by semicolons. No cows escaped through the bedrock until I teleported away and back, causing chunk reloads. Needless to say, 3 trials is too little to establish any actual correlations, and the numbers are fuzzy - nowhere near the high bias I had thought I observed when I only had two cow chambers. Just for kicks, averages:

• + + 8.6N 3E 3.3S 5.6W

• - + 9.3N 7E 2.6S 2.3W

• + - 4.3N 3.3E 7S 4W

• - - 3.3N 4.6E 4.6S 2.6W

With those averages, + + gets the expected northwest "bias", - + the expected northeast, + - the expected south bias but without the expected west bias, and - - gets the expected southeast bias. But the numbers here are so small, it'd be a mistake to trust them outright as support for a toward-origin bias - if anyone wants to confirm origin bias, I think we'll need many more trials. I'll upload the test world.

On that note Gerard, is it true or just a coincidence that animals (perhaps
chickens a bit more - maybe because they can move more easily because of
their smaller hitbox) tend to want to escape their confinement? Them going
for the corners (and a bit more towards the spawn) could be a result of
that.

If they do, them continuing through a wall might be made more prevalent
because of logic like that.

Great that some of you are looking in such detail at this!

The attached world displays the bug in 13w24b, but should work in most versions. To test:

1. Flip the lever which begins spawning, and check your entity counter on F3.

2. Flip the lever again to stop spawning once the entity count is four times the number of cows you want per chamber.

3. Observe that the cows do not seem to escape the center chamber on any quadrant, but seem to pool in the corners and rapidly shuffle about if you have hundreds. They may seem to escape occasionally, but snap back in-place.

4. Press the button to teleport away, and then press the other button to teleport back.

5. Observe that the cows have escaped the central pen, with various amounts in each pen north, south, east, and west of the central pens. Some may have died due to suffocation.

EDIT: It seems this bug isn't marked for 13w24b. Well, I can confirm it, as that's the version I made that test world in.

Part of the reason animals move toward the corners is because they bounce off of each other and their pathfinding starts freaking out when they get inside of partial blocks (fences). If you watch animals in corners of fences they can never figure out how to escape. Likewise, if you hold food right in front of an animal that is very close to a ladder or a fence you will notice it does not know how to approach the player. While it is a bug, I am not sure that it is related to this one. I have found if you disable mob collisions in the code the mobs preferentially do not run into the fence at all and spread themselves rather evenly on exact squares throughout the pen.

EDIT: left out an important phrase...

ArmEagle: I haven't noticed any AI code that aims specifically to let animals escape their fenced areas. Also, it would be kind of counterproductive to code and give players fences to make farms, then code animals to try and make those fences useless. However, read below; the normal "wandering" goal does work so that it looks like they'd want to get out.

Gerrard: Nice work so far. I think I already made a try on this issue on the basis of an idea of floating-point problems during save or load (format conversion or such), but I also found out that part of code to look ok.

For the movement bias, check this out: MC-10046.

The animals gather in the corners for the same reason as villagers do (in the MC-3944): statistics. Note, when "wandering", entities roll a target location randomly (and somewhat evenly spread around current location), without any consideration on how to get there or even if it is possible to get there. Then the path finding tries to find a path to that target, or a location as close to the target as possible. In a typical small square "pen", this leads to ending up a lot in corners. Also, once the entity is in a corner, the probability for the next movement path end point to be in that same corner increases. (For villagers this corner-gathering effect is amplified with their additional AI goal to go and chat nose-to-nose with other villagers.)

For both animals and villagers, their mutual collision "pushing", they way it is currently coded, causes (statistically) increased issues at corners, as it seems that while the pushing does consider slipping sideways when something is being pushed into a "wall", but once at corner, there is no "sideways" space left and the coding fails to prevent all movement in such situation.)

Okay, I found something interesting. I wrote a pushOutOfBlocks method for the EntityLiving class which is called every entity update. Basically, while entities are stuck inside of walls they cannot be pushed by other entities and they attempt to push out of the wall. It works great except that it actually amplifies the problem. All of the chickens in the enclosure became trapped inside the corners of the pen and many popped out, especially on save and reload. Markku, you are totally right. When entities are pushed into corners they can easily get stuck inside the block. Interestingly, I have found that once an entity has hit a corner the problem persists for that particular entity, and it can be fairly easily pushed into any wall. It would seems that it no longer associates its position and bound box correctly which leads to discrepancies between where the entity is and where it thinks it is. In theory, a entity could continually bump against a corner until it either manages to pop out on the other side or its position moves outside of its bounding box. This would lead to a shift in position on save and reload. We may have totally diagnosed the problem, but I won't say for sure. Excellent work guys. I will read the pushing code now.

Looking over the code in MCP, I can't find any moment where the entities position is adjusted without making the bounding box reflect the adjustment, or vice versa. Without such a moment, it's not really possible for an entity's actual position to be offset by a large distance from its bounding box, so that wouldn't explain it.

However, I decided to look into one specific detail: we know that this bug is especially prone to occurring when reloading a chunk containing an entity which is moving and colliding with blocks. Principally, there are two different methods at work here: setPosition, called when loading the entity NBT after a reload, and moveEntity, which is behind entity movement and collisions. I'm finding more support for the floating point precision issue here: setPosition takes coordinates as parameters, and constructs a new bounding box from them:

this.posX = newX;
    this.posY = newY;
    this.posZ = newZ;
    float halfWidth = this.width / 2.0F;
    float height = this.height;
    this.boundingBox.setBounds(newX - (double)halfWidth, newY - (double)this.yOffset + (double)this.ySize, newZ - (double)halfWidth, newX + (double)halfWidth, newY - (double)this.yOffset + (double)this.ySize + (double)height, newZ + (double)halfWidth);

moveEntity, on the other hand, will actually manipulate the bounding box directly, and derive the new position values from that:

this.posX = (this.boundingBox.minX + this.boundingBox.maxX) / 2.0D;
    this.posY = this.boundingBox.minY + (double)this.yOffset - (double)this.ySize;
    this.posZ = (this.boundingBox.minZ + this.boundingBox.maxZ) / 2.0D;

Mathematically, there shouldn't be any difference in which way things are done. Of course, when you're dealing with floating point numbers of limited precision, it does make a difference. Let's say we have an entity pushed against a wall - once all of the collision code is done, the game will have made certain that the bounding box does not intersect any solid blocks, and then derive the entity's new position from that data. Due to rounding error, the actual position values will typically be rounded towards the origin slightly, but of course can also be rounded away from the origin (I know "rounding" isn't exactly the right term when talking about IEEE floating point values; just trying to simplify the thought process involved here).

Let's assume the position was rounded towards the origin, even if only slightly. It turns out that the game will continue using moveEntity for quite a while, for most entities. However, let's say we reload chunks, while the entity is still flush against a wall and its bounding box is "flawless" whilst its position is less-than-accurate. The game will not save the entity's bounding box, and this information is lost when the chunks reload! Instead, only the position is saved, and the bounding box is rebuild about that position. If the rounding of that position meant that the entity was even infinitesimally closer to the solid block, its new bounding box will actually intersect the solid block, and the entity will no longer be forced out!

From what I've gathered, one theoretical fix for the chunk reload issue would be to serialize the bounding box data as well as the position. This would dramatically cut down on the incidence of mob escapes due to reloads - for example, when you consider my test world with cows, I've yet to actually ever witness a cow escape until the chunks reloaded, and reloading causes an absurd number of escapees. This one manifestation of the bug is likely the most common by far - I've only ever once or twice witnessed entity collision issues without a chunk reload, but I almost always get them with a reload. Even if it would only fix one of the 2-3 causes of this bug, that would certainly help a lot.

I have successfully created a mod which fixes this bug for my test world. It does absolutely nothing to stop mobs from escaping while chunks are still loaded, but does fix the bug flawlessly for when mobs escape upon chunk reload. It was actually pretty simple - exactly the theory I had in my previous post. I serialized the bounding box NBT with the following code:

writeToNBT, after Pos, Motion, and Rotation are written:

par1NBTTagCompound.setTag("AABB", this.newDoubleNBTList(new double[] {this.boundingBox.minX, this.boundingBox.minY, this.boundingBox.minZ, this.boundingBox.maxX, this.boundingBox.maxY, this.boundingBox.maxZ}));

readFromNBT, after the calls to setPosition and setRotation:

if (par1NBTTagCompound.hasKey("AABB"))
    {
        NBTTagList bb = par1NBTTagCompound.getTagList("AABB");
        this.boundingBox.setBounds(((NBTTagDouble)bb.tagAt(0)).data, ((NBTTagDouble)bb.tagAt(1)).data, ((NBTTagDouble)bb.tagAt(2)).data, ((NBTTagDouble)bb.tagAt(3)).data, ((NBTTagDouble)bb.tagAt(4)).data, ((NBTTagDouble)bb.tagAt(5)).data);
    }

It seems floating point imprecision when deriving the position from the bounding box (and vice versa) is exactly what causes this bug for chunk reloading. I don't know for certain what causes it when entities just clip through blocks without a reload, but as I said, this fix alone should drastically reduce the overall escape incidence.

I've attached my bugfix mod, mp.class, for others to test in 1.5.2. Dragging this into a 1.5.2 jar (after making a backup!), allowing it to overwrite the original, will fix this bug for entities which escape during chunk reloads. When used on my attached test world, you can easily observe the cows are no longer able to escape.

As a reminder to everybody: my mod does not fix the elusive cases where mobs escape without a reload (typically through fences), and as such, there's still very much left to be tested before the final nail can be put in this bug's coffin.

EDIT: And of course, I personally imagine Mojang's fix would not be as unprofessional as mine. Adding 6 64-bit values to the entity format is far from ideal, when it's more of a band-aid to the problem that position and bounding box do not reliably define each other in both directions. If, perhaps, position were forcibly rounded in the movement method in a way that the new position is guaranteed to avoid collision, it would have a similar effect of fixing this bug (perhaps even when reloads aren't involved!), without adding anything to the save file, but also may be considered a less-than-ideal fix.

What is the "correct" way to fix a bug like this, when the inherent fault is floating point imprecision? I can't say I know for sure, and perhaps there is no perfect fix that isn't at least slightly "duct tape"-esque, but I guess we can keep thinking or wait and see what Mojang's devs have to say.

Hmm, I definitely overlooked width and height being floats. I hope you are right about it being a big issue. I don't see how more precisely and explicitly loading the bounding box can hurt. That is a pretty heavy-handed approach, but it certainly is effective and probably better than saving the doubles in every instance that's running. Alternatively, a properly written method to push entities from blocks would (probably) fix the load issues as the floating point error would not be large enough to push the entity out the other side which might be a more "correct" way of dealing with collisions. I wrote a heavily modified version of the method which pushes the player from blocks, but I am not sure how effective it is because it aggravates the collision issues. I feel certain the collision code itself has some silly error that we must be missing.

My first tests in which I concluded that the position and bounding boxes must be diverging (which I am skeptical of now), I was sending a message to the console when an entity (chicken) collided with a wall. In my tests it only happened after the entity was pushed by a non-player entity into a wall, then it continued to happen when it ran into a wall for any reason. However, I recently tested to send a signal any time the position and bounding box became disconnected and I got nothing. If they did ever become disconnected it would be on load before the the onLivingUpdate method was called. Additionally, I am not sure why pushing entities would do anything that walking would not based on how it is coded.

So what I am wondering is, if those test did not mean that the position and bounding box were disconnected, what did it mean...? I am wondering if it was some sort of bizarre coincidence, but it happened very consistently. Regardless, I did show clear results that, inconsistently, touching a wall is sometimes a collision and sometimes not. (The collision is based on the worldObj.getCollidingBlockBounds). Sigh. Someday I will be able to play Minecraft again without spending half an hour walking around my farm putting animals back.

EDIT: I can reconfirm my collision test results. I did the same thing with cows. I also noticed that entities tend to register as colliding with blocks when they are pushed into corners (edges of blocks, not like enclosed areas, but those seem to have interesting behavior too).

See, that's what I meant the other day when I said the problem might be a "deep and intricate one that is very difficult to repair without causing massive performance drops. Likely, a robust solution eats up RAM like crazy".

I'm worried that the only way with the current architecture is to add a lot of bloat to the processing, and essentially lower the optimization of the game.

So, likely the Devs are totally aware of this bug, but can't actually do anything without completely tearing up the entire mobile-entity calculation and saving code and coming at the problem from a fundamentally different direction. I don't know, maybe someone here will have a really bright idea, but I've got a bad feeling the solution involves significantly more processing time.

When generating the bounding rectangle from the position, why doesn't it check for a collision then, and if one is found, simply adjust the position slightly to avoid the collision?

If it did that, would it still be possible to suffocate/crush mobs to death? Or would that make it so that putting a mob in a crush-condition would cause them to magically teleport outside the crusher?

Workday Lobster, I should note that my mod's fix actually doesn't cause any performance drops whatsoever. It changes literally nothing except world loading and saving, so while the world is running, nothing is different, and it still manages to cut the incidence of the bug dramatically (I've yet to be able to reproduce the bug at all while using the mod - I'd appreciate if others could try to reproduce it). That indicates that, even if fixing this bug in 100% of circumstances would cause massive performance drops, fixing it in 90% of cases can be done without any performance drop whatsoever.

Oh. Sick. Great work!

Solving most of the problem is nice, and it makes this much easier to deal with. But I still run into problems with mobs (primarily chickens) escaping without any world loading/saving. I suppose that would be the leftover 10%.

May I sugguest that when a collision is detected, the mob would automatically reroute itself to walk (in a straight line) to the last non-solid block (air, string, redstone, etc) it was on? As to prevent it from getting confused in fences and such.

Phillip's on the right track above, but I feel like simply adjusting the position could potentially make the problem worse. Then again, I'm not exactly a code junky.

From what I gather, the following still need to be fixed, even if my mod (or something similar) were implemented:

• Chickens and other mobs escaping through fences

• Chickens and other small mobs getting confused into fence corners and refusing to leave

• Baby animals growing up, so their bounding box intersects solid blocks, and walking through them

• Freak floating point miscalculations allowing mobs to even escape through completely solid blocks without the need for a chunk reload (may be related to the fence issue)

Daniel's trying to tackle the issue by forcing mobs out of solid blocks in the same way players are. This would actually tackle the bug on all fronts (except for mobs stuck in fence corners), including the part that my mod fixes. It would make up for freak floating point rounding errors, and in theory should fix mob escape on chunk load at least partially (my mod fixes that problem fully, but his may lead to an interesting circumstance where mobs try to be pushed out of walls and get pushed right back in by other mobs). Honestly, multiple band-aid fixes may be needed to get this bug "100%" fixed. The reason there's no "true, non-band-aid fix" is because the heart of the problem is that computers don't support infinite precision floating point calculations.

Also, I'd like to mention that on a server I used to play on, I had built a strange ladder in my base. Depending on the angle you climbed it, it was possible to somehow no-clip a block and start suffocating, but the game forced you back out. I'd imagine the only reason you couldn't fully pass into the wall is because the game forces trapped players out of walls - if, say, a mob found themselves in the same circumstance, they would've just gotten trapped and suffocated because the game won't push them out. I'll see if I can reproduce this freak no-clip ladder wall.

Ooh, Femix Zn. The last non-air block idea might be a good one as a sort of "band-aid" fix. The issue my push code has right now is that when mobs get stuck in corner fences they do not get pushed out properly, mostly because writing the code so that mobs can be pushed out of the corner of blocks is significantly more difficult, because traveling through a corner block is only possible in certain situations. If the last air block is recorded you know it probably moved there from a valid location.

However, recording that information is minutely more processor intensive (probably negligible, but Minecraft's performance is based on thousands of "negligible" things like that), and I would much rather fix the collisions themselves, as that is the purpose of having code that deals with collisions at all. I will probably try it in addition to my current pushOutOfBlocks code and see where it gets me.

EDIT: The other problem I have with that idea is that if you had, for example, a theoretical pen of four fence pieces right next to each other there would be no previous air block to be pushed back into. So it is not a 100% effective solution.

Great news. I scrapped and rewrote my modification to the entire workspace and slightly changed the function of pushOutOfBlocks. I am also using my previous fix for baby animals and Gerrard's fix for loading. My current test world has 100 chickens in a 2x2 pen and as of yet none have escaped. Now, if you increase the number of chickens to 200 they all clump into the corners and begin popping out of the corners. I am nearly certain the reason for this is because their velocity from all of the collisions gets so obscenely large they are able to, in a single tick, move to the opposite side of the fence without colliding at all.

However, the files I'm attaching contain the baby fix, Gerrard's loading fix, and my pushOutOfBlocks code. Test what you want, but I think the ultimate problem is that there should either be a motion cap or code which checks for collisions between positions every tick. Thanks to everyone for their feedback and a special thanks to Gerrard for the loading fix.

Let me know if you find any problems.

Here's Gerrard and my fixes

EDIT: Note that I did change the player's pushOutOfBlocks behavior to be the same as all other entities. This may have other ramifications, like no longer being able to jump, place a fence, and fall inside of it.

@Daniel, I suppose instead of trying to remember where it last was, you could just detect what kind of bloc it's "in" or bordering, at least, and try to make it walk away somehow. I know partial blocks like slabs, stairs and fences have issues with collision. I'm not sure if that would make the pushing code more difficult or not, but a little experiment could answer that.

Is there a way to tell what kind of fence (corner, wall, end, etc.) it is? Like, do they have separate values from each other?

Edit: Scratch that. Looks like you got it more or less fixed. I forgot to hit refresh on the page. xD

My pushOutOfBlocks method is not 100% effective, but it massively reduces escapes during gameplay, to the extent of (I am relatively sure) reducing escapes in any remotely normal density pen to 0. In combination with the baby animal fix and Gerrard's loading fix I do not imagine any escapes should ever happen unless one were to pack hundreds or thousands of mobs into a tight space. I am a little worried villagers in tight spaces could still have a problem (it's like they try to pack themselves into the smallest space possible).

I do believe I know the source of the issue now, but I am probably not the best person to fix it. Every tick that two mobs touch, their speed away from each other increases just a bit inversely proportional to their distance apart. If two mobs are located in the exact same spot, a tiny upset in the balance causes a massive spike in speed before a quick deceleration. This can be seen when one spawns a bunch of mobs with a spawn egg and then one of them moves. The stack of animals essentially explodes and quickly decelerates to a stop. If enough mobs were located in the same spot this spike in speed could theoretically be large enough for a mob to move all the way to the other side of the wall in a single tick, especially a thin one, especially for a small mob. Think of it like the animal goes into warp speed. I do not believe the code anticipates such movement. Based on what I can read it just checks for collisions at the destination. The only way to prevent it is to basically draw an artificial bounding box across the distance moved and check that for collisions. But it isn't really a bounding box because it is sideways, so it would probably be more like drawing eight vectors from point to point on the old and new bounding box and checking those for collisions. Alternatively you could cap motion at the width of the mob, but I am not sure what the units on motion are.

All of that said. I believe the additions Gerrard and I have made to the code are necessary in any case and should greatly reduce the problem. I hope that if there are still other problems they will be noticed quickly. If not, I hope Mojang will notice this page quickly.

EDIT: Just so people know, I am going to update the pushOutOfBlocks method because it currently assumes entities are two blocks tall. I wasn't worried about it when I wrote it because I was just trying to fix encloses, but it is pretty poor coding to leave it how it is.

I have gone ahead and reattached everything to avoid confusion. My new pushOutOfBlocks code is simpler, faster, and better. I wish it would preferentially push entities into air blocks, but you can't have everything (and that would probably aggravate the fence corner issue more).

I can see those attachments getting confusing - it may be worth re-attaching as a ZIP so the latest copy is always together. Also, nice work!

Thanks for zipping that; it did not occur to me the attachments would be that miserable to sift through.

Theoretically and hopefully my code renders Gerrard's unnecessary. Not because he did a bad job or anything, but because he altered the save format and I really hate to do that. So, I am attaching a new version of the mod which contain the old version, the new version, and the source code for both. If it proves that the change in saving was necessary, that is fine, and we can revert to the first version. Hopefully if/when someone at Mojang reads this or we need to do further stuff with collisions that will be helpful.

Daniel, I've done testing with your revised version, and I think it's safe to say you've fixed the bug without the need to alter the save format - excellent!

It's actually incredible how well it performs: I couldn't have hoped to do anything like, say, this in vanilla:
http://imgur.com/W9xhW4A

As of yet, absolutely no collision issues observed. No noticeable performance loss either!

Mod Tails, why did you remove every file relating to Daniel's bugfix mod? Surely the included source code and changelog could have helped Mojang fix this long-standing unfixed bug. Can at least the source of his fix be posted here? Or has some rule been violated?

...? Yes, why did that happen? If there was every a place to freely place source code for a bug fix I should think it was here.

I am currently revamping the pushOutOfBlocks method because it flips out when the player gets closed in a door, so I will have to update what I had anyway. I am thinking of using a helper method which ignores the points sent if they do not push the player out of anything. It should improve performance and the madly shaking screen when the player is stuck in a thin block.

Using the v2 version of the mod, it seems to not entirely fix the issue of mobs clipping into walls upon reload and has an odd tendency to knock the item frames off my walls.
EDIT: Perhaps modify your mod a bit to only apply to living entities?

The mobs still visually clip into walls, that's a render problem. Are you having them receive suffocation damage or escape?
And the code could not possibly effect nonliving entities unless they have a problem on load due to waiting to set their position until all their data is loaded into the game. Something I would not expect.
EDIT: Ha, yes I see. That is a weird side effect. I will see what I can do about the item frames.

Actually, it seems to be a problem with baby animals clipping into walls when they mature. I've experienced it with both mod versions, interestingly enough.

I found the source of the problem. My previous guess was wrong again. The code is making occasional double precision errors all throughout the moveEntity method in any of probably 50 locations. As such, entities sometimes "misread" collisions and walk right through walls.

I totally revamped my pushOutOfBlocks method for all entities (the player is now pushed out of doors and gates, I hope no one is offended) and created a variable that lets an entity know that if it is inside of a block it needs to be pushing itself out. I also changed the moveEntity method in a significant way. It no longer takes entity collisions into account. It never really mattered anyway, but it made a bunch of double calculations and increased the probability of phasing. The floating point errors on load a far more likely to push a mob out, but still very rarely do it. The code itself really needs a big makeover; that is to say, pushOutOfBlocks should work for any entity using no parameters and be called at the beginning of moveEntity every time, and the previous change I mentioned to moveEntity should stand. Additionally, I think isCollided is obsolete, but I will need to look into that. As soon as I have my source code cleaned up and functional I will zip it and upload it for anyone who wishes to test it. (Unless that is against the rules...?)

In the picture I've attached, there are 250 chickens in a pen with all of the greatest risk factors for phasing (small bounding boxes, thin walls, many entities close together, corners, etc). I kept a counter running, as you can see, which shows how often my code repositioned chickens that phased into walls. I think my stats look good. But something really should be done about them getting stuck in corners like that (MC-12427).

EDIT: I don't expect to upload anything for a little while FYI.

Just use pastebin or google docs to post the fixed code if its against the rules.

Ive also only noticed it with baby animals, its their hitbox being different isnt it?

It also seems to happen with there being too many animals in one place, is there something in the code that makes them try and spread out?

It occurs to me that there are game balance issues with some of the changes Daniel King describes. It's one thing to keep mobs from just walking through fences any time they like. But if you cram 100 chickens into a couple of blocks space, something really ought to give, and not just the frame rate! Consider this egg-farm design, and imagine it hooked to an automatic hatcher: http://www.minecraftwiki.net/wiki/Tutorials/Egg_farming#Trench_Farm , Do we want to allow that?

@David Harmon
For me minecraft is a sandbox (single/multieplayer). All tries to balance it are hopeless in my opinion. Things like extreme xp cost to randomly enchant, repair or even rename a item of your choosing and the anvil breaking after a few uses are a pain to play with.
Some people do believe these things are important and while I can't see the point of it, it is still their valid opinion!

Let me try and confince you that this bugfix is not a balance issue:
If you are holding all your animals in a small place it will look ugly as hell, selecting any specific animal will be impossible and you will have a problem with framerate anyway. At the moment only chickens produce goods by themselfs and eggs are already overfilling any storage method if you build just one small chicken farm.
Also please don't forget that in the current state no farm is working as expected anyway - it's still a bug and a nasty one, too...

Please do not remove my bug fix from the attachments, and if you do please explain why. I am fairly confident no animals will ever escape for any reason with this bug fix. I did some massive rewriting of the pushOutOfBlocks method and I think it works fantastically.

Every cow in that pen grew from a baby cow, so the collision code is solid enough to handle that. I have made some rather significant changes to the moveEntity method, so if you decide to test this fix please report any weird behavior from virtually anything in game that moves. Also, there were concerns about item frames popping off walls; that should no longer happen. Note that the player is pushed from doors now, which will be weird at first. It would be easy enough to undo that bit.

@David Harmon
This is not a matter of balancing the game: this is a matter of the game being functional in the first place. It can be balanced when it works. It is easy enough to write code that starts damaging mobs that are too dense, but that is not what this bug is about. But, I appreciate your concern.

EDIT: Keep in mind this is not 100% tested and I edited some high level classes so there could be unforeseen side effects.
Also, I can personally confirm rare instances of small entities escaping on load. I hate to say we may need to go back to Gerrard's heavy-handed save format fix, but that is looking like the only option (well, next to changing the width and height instance variables to doubles and increasing memory usage).

Tested out the newest version of the bug fix, and it seems to have done something very strange. Try sprinting anywhere in any direction and your movement will be kind of jittery.

Are you experiencing a noticeable FPS drop? I am not having jittery movement in my tests.

@BertHunter I beg to differ – it seems to me that animal farming is OP already (most of food is, but animal farming is top of that heap), and this makes it even more so. And there's already a mode for folks who don't want any pesky limits.

@Daniel King: I've been running a bunch of farms since 1.5.2 came out (and before that too). This bug is a major annoyance, but no, it is not a matter of "the game being functional in the first place". One could even argue that occasional escapes or suffocations are even "realistic", especially from overcrowded pens. I could still do without that much realism, but I'm bothered more by the type of escapes that don't depend on population density, and their sheer blatancy – animals don't even bother to walk through, they just glitch over to the other side, right in front of your eyes. (ETA: And for the other sort, saving and reloading changes the world.) And the kicker, it does mean that farms need to be attended regularly, and maintained. I could deal with having to provide sufficient space for a given number of animals, but I'd much rather that once properly established, a farm can be ignored while I do other stuff. (That, after all, is Minecraft's usual pattern --wheat doesn't go to seed, potatoes don't rot in the ground, etc.)

I'm also bothered by the developers not dealing with the bug – while I appreciate your efforts, why the he** is an end user having to fix this? And there's other longstanding bugs that they haven't dealt with: off hand, boat instakills and sitting pets teleporting out of unloaded chunks.

@Daniel King
It's kind of hard to describe, but at least for me, regardless of the world I go into, even if it's a newly generated one, when I sprint, it's like the game puts a wall in front of me every moment I move.

@David Harmon
Take your debate elsewhere. This isn't the place to discuss how you want the game to be. This bug is not intended behavior.

@David Harmon
Entity escapes are not based on population; they are based on miscalculations in the game code that happen more frequently as population increases, only because of increased opportunity. Most are a direct consequence of the moveEntity method not functioning as it should. Besides loading errors, the source of all collision issues is the moveEntity method running some calculations, saying "There is no block in front of me", placing the entity inside a wall, and continuing on as though it didn't do something wrong. As the code is currently written the mob, which is then inside of a wall, makes no effort to leave and will suffocate in opaque blocks. That can be in no way considered properly functioning, so I wish it to be fixed. I sympathize with your frustration at the lack of the bug fixing (why do you think I spent the last week or so learning and modding code?) as well as the OP nature of chicken farms for example, but please don't say this bug is a feature. I could easily go in myself and write a mod which checks the number of colliding animals and begins doing suffocation damage to them if they are too densely packed, but that has nothing to do with whether the game code is written well enough to prevent mobs magically phasing through matter. Again, I appreciate your concern, but this is not the place to voice your complaints about features.

@Inquisitribble
Are than any other mods to your save? I cannot figure out why the player's velocity changing should have any effect on how his/her change in location is determined in moveEntity unless the world itself is somehow registering a block collision.

EDIT: Ah, thanks for the "even in a newly generated world" comment. I see, it looks like the server's copy of the player is disagreeing with the client's copy. I will need some time to find out why. Try playing in creative; it doesn't have that issue.

Please do not re-upload attachments that have been removed by a Moderator, as they were removed for a valid reason. Please remember: this is a bug tracker, not a file hosting service and, as a result, we are not equipped for handling file uploads properly. Please only upload attachments and link to things that are relevant to helping Mojang reproduce the bug reported. These include: screenshots, small videos, small world saves and resource packs (though this is not an exhaustive list). Since we cannot ensure the integrity or safety of an uploaded or linked to file we have to remove any uploads or links that do not meet this requirement for obvious security reasons.

Tails, would "code implementing a fix" be considered "relevant to helping Mojang"? From a programmer's perspective, source code like that can be very helpful.

Can Daniel re-upload just the source code alone (raw text files; not executable)? Clearly, he's shown that the bug can be drastically reduced in severity (to the point of nearly being fixed in all cases) without major performance hits, and he's been working on resolving the side-effects. Considering some people here carry the sentiment that this bug must be impossible to fix efficiently and thus Mojang should avoid trying, this mod is actually pretty valuable in disproving those notions and actually giving some firm ground from which Mojang can develop their own fix.

Tails, like everyone else at Mojang, is obviously not reading these comments to any great degree or he would have seen where Daniel said in an earlier comment "(Unless that is against the rules...?)" and responded with something other than a completely silent removal of the file. I suspect that only changes when someone gets assigned to the bug.

This is not intended as a slight against Tails. I'm quite sure he's doing an excellent job as far as this part of his job goes. No one can read every comment, that'd be insane on hundreds and thousands of bugs. However, this happens to be the second most popular issue on the bug tracker--neatly bracketed by two other issues that are huge visual glitches that don't actually make it impossible to play the game. I'd think that would warrant some kind of actual attention when some users with actual skills get tired enough of the problem and start trying to fix it for you, with submission for testing of the fix.

@Tails
I appreciate that you are doing your job, but, from a programmers perspective, nothing could be more useful than source code which not only identifies specifically where in the code the bug is occurring (that should help reproduce), but also contains a fix for that bug. It's like saying to a doctor "These are my symptoms, and here is the illness I have, oh, and here is the vaccine, but I need you to give it to me." I am not saying my solution is perfect, but it is at least the beginnings of exactly what needs to be done to eradicate this bug for good. Collisions and pushing from blocks really need to be overhauled (a minor overhaul), and this code, if nothing else, demonstrates the direction in which that can and probably should be done.

I admit, I cannot promise my mod will not harm your game (btw, I fixed that weird sprinting behavior, thanks Inquisitribble), but I can guarantee the source code demonstrates how this bug can be reproduced in addition to providing much more useful information. I believe my source code at the very least is a perfectly valid thing to be posting. However, I understand your interpretation of the rules, and as of right now I will be waiting for permission before posting source code.

EDIT: So, this is a link to an actual file hosting service. And I think I am required to say "Use at your own risk." Tell me if you have crazy issues (with the mod).
https://docs.google.com/file/d/0B89TxHEJMb4BWTMtVXhJT3lnTkk/edit?usp=sharing

@Daniel King
If I'm not terribly mistaken, you could provide links to the normal mod in here: http://www.minecraftforum.net/forum/51-minecraft-mods/
Just give the topic title something that includes "fix", "MC-2025", "animal", "escaping", so everyone interested will find it.

And niiiiice job nailing the issues (or at least sweeping them under a really heavy floor mat). I had wanted to dive into this one for quite a while, as it is my number one reason I'm not actually playing at the moment, but instead only tinkering with the MC code.

@Tails
(off-topic, but since there is no other communication channel to do this...)
"Since we cannot ensure the integrity or safety of an uploaded or linked to file we have to remove any uploads or links that do not meet this requirement for obvious security reasons."

I think you can deliver this message "upwards": That "rule" is B.S. If players are allowed to produce and distribute unchecked arbitrary mods in the official forums, the "security" is already gone. There is absolutely no point in trying to keep it in one place (here), yet not have it at all in an even more public place (forums).

Kinda braindead situation with the policies, but then again, to keep mods (no pun intended, mods) out of here does have its good sides - The atlassian servers are already pushed to their limits and often beyond, even without giving them a new task about file hosting.

Also, is there somewhere a page that tells about those rules? One that can be found easily when surfing this JIRA. If not, it might be nice to quote the relevant rule(s) when undoing/modifying (the first time) things done by users. Otherwise things like above can happen; the user can not know if it was just a mistake or intended moderation action. (Personal interest, how much of source code is considered ok when showing fixes? I've kept my fixes as limited/simplified as possible to keep that amount low.) P.S. Answers can be provided as PM's on the forums, my usernames are the same in both places.

Confirmed for 13w25c. Can somebody please update this ticket to acknowledge that it's on the latest snapshot?

Sometimes I wish non-moderators were able to do this, as it can take a while for a moderator or the ticket submitter to get to it. The ticket hasn't been updated since 13w24a (4 snapshots ago); Mojang is generally more likely to look at tickets which are actually happening in the latest release of Minecraft.

To me it just seems to defeat the purpose to hand the modifications to the community when this site gives an almost direct link to the people who can make good use of the source code. It's not new features; it's a bug fix. I get that they are probably excited about fixing bugs relevant to 1.6, but I don't understand what the excuse is for not fixing an infamous bug that has a possible solution in source code posted here. Speaking of which, I just uploaded a less broken version. If you guys have any feedback from testing, commenting should be enabled on the Google Docs. I am fairly confident it does not break anything in vanilla Minecraft, but I don't have much time to be testing it right now. This will probably be the final version unless I find a problem with it or feel the need to tweak it a bit more. I'll be watching, but I'll try to stop commenting as frequently. Maybe I can play Minecraft again without raging =).

Here's the link to my fix again:
https://docs.google.com/file/d/0B89TxHEJMb4BWTMtVXhJT3lnTkk/edit?usp=sharing

Okay, call me a perfectionist, but I couldn't help myself. I fixed item collisions too. No more items going through walls and stuff. I just scrapped the original pushOutOfBlocks method and replaced it with a very modified version of mine. Then I just got rid of my method. Ooh, that feeling of solving multiple problems with the same solution. This is pretty much the minor overhaul that I wanted, but didn't want to do. I did have to edit a couple more classes so it's a bit bigger (xp orbs and items). I just can't stand to look at code that doesn't work or isn't organized well.

Click here to try out the fix.

Does that break the piston powered "push up into solid column" item elevators?

Because I really like those for moving stuff in bulk quickly, and I kind want those to stay.

If the aforementioned movement method required the use of the buggy item pushing from blocks and the noclip "feature" which allowed items to enter the collision box of one block and think the best way out was traveling through a bunch of other blocks, yes. While I can see why that might be cool to abuse, it also breaks more "legitimate" abuse of Minecraft, like mass mob killing machines, which have items flying out of them in every direction, no matter how thick the walls. I actually removed noclip from the item code because frankly I do not believe it functions anything like it was intended to. So, actually, while possibly breaking your glitch abuse I have improved the stability of mob farms.

Except that I'm fairly certain that that "bug" was purposefully added to deal with the problem of drop-items getting stuck inside transparent blocks. That aspect of the behaviour seems to be intentional, so that drop items try to move upwards, and "stay on top" of the placed blocks.

That means I can stand at the lip of a hole, mine down 3 blocks, and then place different blocks in the hole from the bottom up, and the drops (say cobblestone, or coal) from the blocks I mined "squeeze" up to me. It' supposed to do that, before they made the change the items just stayed jammed in the block.

I concede. The noClip feature is broken in that it allows items to go through walls, but it has purpose in pushing items out of the ground. I have fixed it so it only noClips when the item is traveling upward. This means that the piston thingy should still work as that is how Mojang intended for this feature to work (even if that isn't exactly the purpose of it). If anything, I may have assisted you in ensuring items are pushed straight up. Although, I do think they travel about half as fast now, as I opted for a slower, more consistent speed.

Click here for my bug fix v7

Still present in the 1.6 pre-release.

Confirmed for 1.6 pre. It's even worse with horses. They walk into blocks and suffocate very often, even without reloading any chunks.

Weird that they haven't bothered to comment on this. What is this the gazillionth post regarding animals not working right? And it is as Daniel King says: More than just an animal problem. Ever since the game was made to use individual textures... "sumthin ain't right." Ever tried to press a button while sitting in a cart? Good luck. For now, I'm ignoring survival until it's not glitchy with all the Mob. I don't know. It just seems like this is the biggest bug out there and no one at Mojang can be bothered to even comment. I guess horses are more important... even if they die right away upon their introduction into the game.

Oh I can't wait until 1.6 is released. It will be so much better with dying horses.

I've had this problem with baby villagers.

still present in 1.6.1 pre

Confirming this problem in 1.6.1. Cows and chickens mysteriously escaping from secure fences.

Why is no one assigned to this problem, and why have no comments from Mojang been made? It is the second most infamous bug on Mojira, and some of us have worked to demonstrate in source code where the bug is and fix it a week ago now. There is no reason to let it sit with no comment. Is there some other way to draw Mojang's attention to this issue? I will take this opportunity to post the link again in case it is too far lost in the comment history for people to notice.

This is a user-created bug fix: MC-2025 Bugfix v8
I would really appreciate testers and feedback in the Google Drive comments. My interest is in permanently fixing the issue.

I would like to formally ask the moderators if I may upload a zipped folder of my mod to this site. It helps diagnose the problem by resolving it almost completely. The changes in the code show what in the original code was a problem. Therefore, I believe it follows any possible rules for upload, and it might be easier to find than a link in the comments. Also, it is only 101kb, so it is no more of a burden to the server than one of my own screenshots I have just removed.

That is the most absolutely baffling part of this bug: The fact that it apparently hasn't even been acknowledged by the developers despite the massive user interest in a fix for it, as well as having most of the work for a fix already accomplished by said users.

I mean, maybe there's some huge problem with the fix that nobody here has spotted (though I doubt this). Maybe that's the reason for a delay in fixing it. But it's the silence that just doesn't make any sense. Some kind of communication breakdown is happening, whether from the users to Mojang or vice versa.

It might be worthwhile trying to contact Dinnerbone or other devs on Reddit or even Twitter. They seem to be fairly active there.

I've tweeted Dinnerbone on this issue twice and linked this page. No response 😞

@Daniel King & others:
"Why is no one assigned to this problem, and why have no comments from Mojang been made?"

There are plenty more issues in this JIRA with fixes already provided, with no apparent activity by Mojang. 40+ issues of them by me alone. Most of those issues have now been in that state for several months (since 1.4.7), and couple of them are "years old", been reported in at least 3 previous "official bug reporting sites" (forums, wiki, GetSatisfaction), as Mojang mostly ignored each one in turn. 90% of all that for nothing. The 10% keeps me going. Barely. Not for long.

So, there is nothing special why this particular issue hasn't received any attention; almost none of them have. Also, Mojang has the habit of simply reporting "fixed" at some point; they do not announce by who or when an issue is started to be worked on. Sneaky.

There is no point in making comments here about that problem (i.e. of no activity from Mojang); if they haven't reacted yet (e.g. by checking the very clear list of most popular issues), one more comment here will not make a difference to that, but only buries the more useful comments (like the ones with fixes) in the history. (Lets see if I can help with that, link to the latest comment with the fix: https://bugs.mojang.com/browse/MC-2025?focusedCommentId=78730&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-78730)

Oops, I think this comment falls in the category of useless comments, too. My bad. *Turns back to email to delete last day's worth (read, tens) of new JIRA notification emails for issues still waiting their fixes to be applied.*

Woooow, and in one swift move, Jeb crushes it.
I'd like to give my thanks to the people here, for the hard work they did looking at the code and problem solving this issue. You've really helped the whole community. And a big thanks to the Mojang crew for helping us out with this!

Hooray!!! Finnaly fixed! =D

Thanks Jeb, thanks. That was the most annoying bug, and it gonna be fixed. =D

Hooray! Right after I was a huge jerk! I'll have to be careful not to take the wrong lesson from this.

=D huzzah! But I did JUST figure something out. The reason my fix only 99% resolves the problem is because (it would appear) the client sends packets to the server to tell it the entity's location. Then the server misplaces the bounding box just like it does on load (bit of a guess, but that is the only thing I can imagine to explain my results). So the server disagrees with the client and pushes the entity through a block. I think width and height need to be changed to doubles throughout the entire code, or bounding boxes need to be saved to file and sent to servers. Obviously the former is less undesirable than the latter.

Also, I have significantly rewritten my code and I have a barely tested new version. It only pushes the entity once for every bounding box it intersects with. Then it pushes the entity's center from the bounding box's center. I am convinced this is a very good way to approach it, if not the best. It is very functional with fences, doors, and normal blocks. It even works with doors in front of walls (with enough space to walk between). However, it is very new and untested. It might get some entity stuck somewhere, but only if one really works at it. Also, my bug fix accidentally fixes most visual bugs. I don't say all this because I don't think that Jeb can handle this himself, but I do think this is a reinvent the wheel situation.

This is a new link; I had an issue with the old one. My code is still 1.5.2: MC-2025 Bugfix v10

Thanks for getting to this bug by the way =)

EDIT: I made a small, nearly insignificant update. It should stop items from falling through the ground and flying into the air sometimes.

I know this should not be used for spam like this, but I can't resist:

Thank you Jeb. The next pre-release will be one I'll eagerly test!

@Daniel: Thank you for a 152 fix. Is it compatible with Forge? (something to ask anytime there's base class overwrites now-a-days.) If not, can you make a forge compatible?

We've got a few forge mods on our system that we (ebxl, mystcraft, etc) just can't let go of.

His fix doesn't work for Forge; it modifies a few of the same classes, and it crashes if you try. Might have to wait for a Forge version for 1.7.

It sounds like it is fixed in vanilla 162, so it's just a case of 152 backdating until everything is updated for 1.6.3.

Oh! Last time I saw it was Future Version - 1.7. Thanks for calling my attention to that.

Edit: Official fix works very well as far as I can tell.

Edit 2: Double checked, uploaded a zip with some sequenced screenshots to confirm the bug is still present; however, the incidence is definitely reduced. One image I've uploaded shows just how many baby chickens I packed in a 4x4 area. A more reasonable number of chickens never had a single escape over twenty save/load cycles. So basically, yeah bug still present in 1.6.2, but it's not nearly as bad. Normal farming in the course of survival gameplay is at least possible now.

I can confirm that the bug is still present in 1.6.2 pre-release. If someone else can confirm this that would be great. With 200-300 chickens in this pen I almost immediately saw a chicken escape during gameplay. After save and reload this began happening (this is after no more than 1 save and reload, no more than 30 seconds). Note this is really no improvement from my previous tests.

I have a 1.5.2 mod and source code which does resolve this issue and other small issues (visual bugs, bizarre item behavior, not pushing out of transparent blocks like doors and fences). I would appreciate if it is reviewed by someone at Mojang. The link is at the bottom of this post. It would be my pleasure to explain what I have learned from reading the code. I do not know what Jeb did to resolve the issue, but it appears ineffective. If Mojang will not read my code at least read the issues I have found:

• Floating point precision errors on load - (Gerrard actually found that)

• Double precision errors during movement

• Babies shift northwest due to a discrepancy between width before and after load.

• Babies grow into walls when their width and height increase

• Recently, I've found what appears to be floating point precision errors from client-server disagreement

This was basically my solution:

• I wrote a better general method for pushing all entities from all blocks with collision boxes (look at this if nothing else)

• I reset movement if a mob is found to be colliding after a move and isn't being pushed from a block

• For baby animals I added another call to set the position on load.

It does not "fix" either the load or the client-server problem, but it does reduce them insanely (as in, reduction from thousands of instances to just a few in my tests). The most reliable fix would be to convert width and height to double precision variables in addition to what I have done.

This is a link to my mod - not Forge compatible, only works with 1.5.2. I will update if necessary, but that seems silly.

EDIT: The picture I posted is titled BugStillPresent. Yes, I am asking for this issue to be reopened.

EDIT AGAIN: I just ran a decompiler on 1.6.1 and 1.6.2 and compared them side by side. I see no changes to entity movement, no changes to living entities in general, and no changes to pushing out of blocks. It would appear the only changes relate to setting size. This means that, ideally, Jeb fixed the issues related to baby animals. It is possible he could have fixed client-server discrepancy, but that is mostly wishful thinking. At best only a couple sources of this bug have been fixed; nothing else has changed. Adult animal escapes do not appear to have reduced at all. I have no intention of being rude, but this bug is definitely not fixed.

Bug still present. I am asking for this issue to be reopened, too.

tested with Map "Mob Escape Testing"
Image 2013-07-06_01.17.46.png

Confirmed in 1.6.2 PR with 200 chickens in a 1x1 area.

Oh, that's not so bad as it was, as "Ryan Rinehart-Taylor" said normal farming is must be not a problem for now. It only happens when animals pushing each other as they don't have enough space, now if mobs escaped it's your fault that you didn't made enough space. I can't imagine I have in survival over200 chickens in 4*4 fence, so for me it is fixed. =3

P.S. Only one problem left, chickens stuck sometimes in fence corners. =3

@Dranitsin Roman
I've been working on this a while, and I know what causes the problem. Frequency goes up with population and smaller spaces only because the number of chickens which come into contact with fence goes up. Play Minecraft for a few days and a few animals will escape. It is random chance which lets them escape and it has not been reduced. However, a few weeks ago I began working on this and I have a fix for 1.5.2. If Mojang addresses the problem just as I did, or even in a better way if they can think of one, it will resolve the issue for normal farms almost certainly. However, from what I have witnessed and read directly from the code, in 1.6.2 nothing which causes animals randomly to escape over time has been resolved. (see my previous post for causes and how I fixed them) If you have not been experiencing issues with this yet: congratulations, I am happy for you.

As for the chickens getting stuck in fence corners, that is a pathfinding bug I am also currently looking at the code for. I have it all explained on MC-21109.

I am sorry if I come off as irritable, but I have not played Minecraft in quite a while due to my very large farm being impossible to maintain. I do not have 200 chickens shoved in a 4x4 space, but any number of entities in any space will eventually phase through a wall. Every time I play the game I must spend literally fifteen minutes to half an hour placing different varieties of sheep in their pens, checking multiple floors and fighting with pathfinding to put them back in their pens.

Daniel King I know. That's looks more rare now. IDK what they did. but, looks like little chickens not move anymore after reload. I'm too thinking it's not completely fixed, but better than nothing. Some more work about that bug would be good.

Confirmed for 1.6.2, but I'm having a hard time reproducing it.

Rare or not, lets put this into perspective.

When I first tried using pens of sheeps of different colors, I found it impossible – my early videos include pictures of animals jumping up 2.5 blocks off the ground trying to jump over fences – and constant leaks every time I restarted the server. I gave up and just cheated the colored wool in as a bug work-around.

Somewhere around 1.4.5, I think, the leaks reduced greatly – enough that my strategy changed to "kill the escapees, and just breed new babies" – keeping 3 in each pen (as the escape rate went up when it was 4 in a pen – fence length 4 around a 2x2 open area). That mostly worked – occasionally I was down to 1 in a pen, and trying to lure someone back in as a replacement was ... just not working 🙂. (It was basically built in the first place as two people, me luring sheep, and my friend putting fences up around us.)

Fixed, in survival? I had a 151 test world with a giant pen, filled with cow babies. Over time, most grew up, and leaked. It's currently got 5, I think, and it's something like 6 by 9 in size. And everything beyond those few have leaked. Yes, they leaked as adults over repeated starts/stops (chunks were very close to spawn, so as I understand it, they never unload.)

If the basic issues – mobs thinking that they are at their corner instead of their center, floating point precision issues, and collision issues – are still un-adressed, then the basic bug is still there, and it still is an issue in survival for even a basic farm.

After some testing I couldn't say it is fixed, but mostly better. Baby animals sometimes like to ignore fences anyway... XD

Added some screenshots. Still Exist in 1.6.2. Can confirm.

Confirm still broken in 1.6.2 Pre-release. Playing with Java 7 in Linux.

This image I uploaded is only chickens, but it has happened with other mobs that are less crowded.

If Jeb is reading this, I would really like you to consider my fix for the bug that was last updated in 1.6.1. An earlier post explains what I found to be the causes of the issue and how I fixed them. This is a link to that post. A brief list of what my mod fixes (in 1.6.1).

• Animals almost never escape. The rare escapes are caused by something I have not fully diagnosed but I believe to be client-server disagreement

• Items and XP orbs are pushed out of blocks better, and animals are actually pushed out of blocks

• XP orbs, items, and animals are pushed from blocks with odd collision boxes like fences and doors.

• Most visual bugs (animals popping in and out of walls) are completely gone, with the exception of ones that happen on load.

If Jeb is not reading this, can someone send him a tweet or something before 1.6.2 is released and tell him to read this?

EDIT: I did just update my code to 1.6.1 instead of 1.5.2. Hopefully it even syncs with the server better because I moved where some of the code was called so that it fit better with the profiler. Click here for my 1.6.1 fix

EDIT AGAIN: Apparently something about 1.6.1 or where I inserted my code is causing some weird response. I am rolling back to the 1.5.2 version until I fix it.

I found the source of the issue. The "rendering errors" you witness when mobs are packed into cages are the server miscalculating the position of the entity and rendering it there. This becomes a problem when the server decides to "correct" the client. This is due, I speculate, to the information which the client sends the server. I tried recording width and height as doubles and it didn't fix it, so I can only assume it is the position which is rounded off and lost, not the bounding box.

The reason my fix is 99% effective is that it corrects the server most of the time when it makes a position miscalculation. This means that the "rendering errors" are almost entirely resolved. I went ahead and removed my fix for double miscalculations on move because it is rare and minor, and I believe the pushOutOfBlocks method is correcting it anyway.

Entities need an adequate pushOutOfBlocks method, which I have written already; it just needs to be added to the code. It is also very important to reset the entity's position if they make a double precision error and walk into a wall, something else which my code does. Additionally, in order to say this issue is totally resolved the client and server must always precisely agree on an entity's location. I have not read any of the code pertaining to this, so I am not sure what all is necessary to fix it.

If just what I have coded is added to the game the bug will not be totally fixed, but it will be reduced so much that it is unlikely anyone will encounter it in normal gameplay. (But still not fixed. The perfectionist in me is annoyed.)

Here is a link to the 12th 13th version of my fix. It does include my fix for baby animals shifting northwest on load as well: MC-2025 Bugfix 1.6.1 v13

And in case this was not understood for anyone just joining in on this conversation, this is not fixed in 1.6.2.

Confirm still broken in 1.6.2 release! please fix it, it's soooo annoying! 😞

Nathan: Click "Stop watching this issue" near the top-right of the page. We cannot remove you from the mailing list.

Mod GrygrFlzr, can you please re-open this ticket? As several users have said, it is not fixed in 1.6.2, the marked fix version and latest version of Minecraft.

Reopened due to reports that the issue was not fixed.

I don't want to be "that guy", but I do have the causes of the issue and the issue itself explained and essentially resolved for 1.6.1 in a previous post. I don't want to say that no one else can benefit the discussion at this point, but I think what is arguably most beneficial right now is for people to try not to further spam emails and leave this older post easy to find:

The causes and 99% fix for the bug as of 1.6.1.

If you wish to try out and discuss my fix please comment in Google Drive instead of here.

Honestly at this point I would be very disappointed if Jeb began writing a fix without reading my explanation or even talking to me. I have spent too much time diagnosing and fixing this to be disregarded. And I will probably insist on this being reopened if the client-server disagreement is not fixed and the bug is marked as fixed as opposed to "hardly noticeable".

Your efforts to diagnose and fix this bug are appreciated by a great many players. I am sure just as many were disappointed when Mojang claimed to fix this problem, and it turned out that they had not. But none of this gives anyone any claim upon Jeb's time or attention.

They may wish to solve the issue themselves, without looking at your code, in order to avoid any legal claims upon them. Also consider that the deobfuscated names in your code are almost certainly not the same as in the actual source code, so it's not like they could just copy+paste it in anyway. [https://mojang.atlassian.net/browse/MC-2025?focusedCommentId=83781&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-83781|Your summary] of the specific problems and solutions should be sufficient.

@Torabi
Sorry, I don't mean to be a jerk about it all. I understand it is not my job to debug Minecraft. I'm a pragmatist, and I would really like the issue fixed. I do understand that the code is not the same, so in my newer upload I have significant code snippets, which can practically be renamed, copied, and pasted into the code.

I have no issue with any of my code being added to the game, but I would appreciate some credit. Honestly I see no point in them spending the time to write their own version of my method which pushes entities from blocks (one already exists in the code, but it doesn't work as well). Although, I can understand them modifying it a bit.

For readability sake I will go ahead and make a table that explains what I have found that causes the problem and what I did to fix it. To me it looks much more effective than my previous posts. The mod, source code, and useful snippets can be found below. Note that it is probably not Forge or Modloader compatible.
MC-2025 Bugfix 1.6.2 v15
MC-2025 Bugfix 1.6.1 v14 (I will probably remove this soon)

I will ask again that people avoid commenting so that this is highly visible. Thanks

EDIT: Sorry for the email spam, but I went ahead and made a 1.6.2 update.

I've been keeping track of mob glitches in Minecraft as well. A couple versions back I already made a mod called BetterSMP to fix smp-exclusive permanent glitches and reduce the amount of temporary/visual glitches. The algorithm was reworked by the bukkit team and later incorporated into Minecraft, along with the other fixes.

Anyways, I also did a lot of investigating into the current issues, but haven't gotten enough time to put everything together until now. I found the source of two different bugs and was able to fix them (100% glitch free now as far as I can tell). I created a github repository containing an explanation, the mod, the source code and test worlds:

https://github.com/taurose/Unglitch

Summary of what I found:

• Race Condition: When the collision boxes of certain blocks are generated, the min/max coordinates are sometimes saved to fields of the block object, and shortly after read again to create the AABB object used for collision checks. However, in SSP (or SSP opened to public), both the server and client threads do collision checks at the same time, using the same block objects. This can lead to false bounding boxes being generated (for example, server generates bounding box based on client's calculations on the same block but at very different coordinates).

• Floating Point Error: During collision checks, Minecraft mainly works with the min/max coordinates of the entity's bounding box and writes the average (= center) to the entity's position fields at the end of each tick. When an entity is loaded, the min/max coordinates of its bounding box are recreated using those center coordinates. However, in certain, rare situations the recreated bounding box could slightly differ from the original one, possibly making mobs glitch into blocks.

My fixes:

• Rewrote the code where the bounding boxes are generated to not rely on any values stored within the object.

• Introduced an epsilon value for collision checks, which causes entities not to ignore collisions with blocks if they're barely inside of them (like 10^(-14), depending on the magnitude of the current coordinates and thus the possibly caused error).

@Daniel: I tested your mod with my worlds as well, but I found that it doesn't fix either of the problems. I took a look at your pushOutOfBlocks code, but since it relies on isBlockNormalCube() I wonder how it could work with fences and other blocks that are collidable, but return false for that method.

@Alexander
Fantastic work! I have long suspected many causes of this bug. That was why I wrote the pushOutOfBlocks code in the first place, a sort of catch-all for small errors. Basically it pushes the entity away from the center of any collision box it collides with and toward any block that looks more reasonable in two dimensions simultaneously, while locking it out of any other movement. It is and has been part of the code for a while, I just improved it and applied it to living entities (which I thought it used to work with). I can explain it in more detail if you wish, but I do promise it is functional. Unfortunately, enough large errors are made in ways I have not understood up to this point that it is not 100% effective, but you will still likely never have problems in normal gameplay (as in, I have been putting hundreds of chickens in tiny pens and averaging 1 or 2 escapes per hour).

My testing has shown that during the moveEntity method an entity can calculate that it will not collide with a block, and then collide with a block anyway. Now, the moveEntity method only works with the bounding box itself, not the position of the entity. Additionally, the way my code is currently written the moveEntity method knows if a collision exists before it begins. This means there must be a tiny double precision error made during those calculations (and there is a lot of adding doubles of different magnitudes, so it is not surprising) and/or, in light of your findings, it could also be a thread issue. My fix was simply to reset the bounding box in those instances, which drastically reduced escapes. As you said, in other cases, like on load and when the server tells the client to update, entities set their bounding boxes off of floating point precision because entities record their width and height as floats. I simply relied on my pushOutOfBlocks method to fix that. With those two fixes alone the only time I have witnessed my pushOutOfBlocks method called during gameplay is by the server (in SSP), although I acknowledge the possibility of it being called by the client.

What I found most recently is that the packets sent between client and server which determine an entities movement are stored as bytes, which are converted to doubles. Now, if I am remembering my Java primitive types correctly, this means change in location, which needs to be precisely accurate to calculate collision reasonably close to correctly, is being stored in 8 bits instead of 64. That is far worse than a floating point precision error. What I also found recently is that on rare occasions entities can exit a pen without any indication of ever being inside a wall. In one case I was printing all collisions to a file, and when a chicken escaped the pen I checked its ID to find it had no record of colliding. This sounds like the bounding box problem you described.

I noticed that in gameplay the escapes often follow the visual errors. For example, I watched a line of chickens pop out and go back in about 10 times and then suddenly an entire line of chickens popped out and stayed there. Therefore, I have recently come to the conclusion that these visual errors are client-server discrepancies (perhaps predicted out into the future a bit by rendering) and my pushOutOfBlocks method is fixing those at the server level at least most of the time, which would explain why most visual errors are gone with my fix.

I do like your epsilon value fix. It seems less heavy-handed than my fixes, and I can imagine it being a good catch-all in much the same way my pushOutOfBlocks method and moveEntity modification have been working for both floating point and double precision errors. Great work on the bounding box issue especially; I think this is what my fix has been lacking. I did not think about an integrated server issue like that. I do still maintain that the pushOutOfBlocks code is necessary, but I am very open to a better alternative to resetting bounding boxes during movement (which you seem to have). I am testing your code right now with great success. However, an adequate pushOutOfBlocks method is necessary in the event that an entity spawns inside of a wall or is buried, or even manages to slip by your epsilon value. Or, for example, if one were to place a fence post on either side of an entity, thus resulting in them being inside of a fence, they will be pushed out. Additionally, if entities die or lay eggs beside a wall the current code is unreliable about pushing the items out correctly, but mine is not. It does have the potentially annoying effect of pushing entities out of doors, but I think it should have always worked like that, and it could be removed.

I honestly think though you have successfully shown me up and created a better general fix through the epsilon value and addressed something new through the block collision fix. Never has being shown up felt so much like Christmas. 🙂

Here is my code with the moveEntity fix removed. In conjunction with what you have done I believe this issue and loosely related visual and position issues to be very resolved. There should be no conflicts as your code focuses on blocks and collisions and mine focus on how entities process blocks and collisions. You have my permission to add it as an optional part of your stuff just so it is all in the same place.

MC-2025 Unglitch Add-on 1.6.2 Let me run through what it does:

• Pushes out entities which are spawned in blocks, animals and items alike

• Fixes most if not all visual errors that make entities appear to escape pens

• Pushes animals out of sand if they are buried, just like the player.

• Pushes entities out of transparent blocks like fences and doors correctly (doors feature could be removed if it is annoying)

EDIT: @Alexander The only issue I have found thus far with your code is that I think you messed up the trap door's bounding box. I can walk through it in certain orientations.

Daniel King, just tried your fix. And I'm not gonna say anything if they made it official. This push out things looks like they must be there. Not always perfect, but I like the idea. =3

Thanks for giving it a try and letting me know about the trap door issue.

Argh, I screwed up the installation of your mod before. Now who's feeling stupid? 😉 Great job! I still wonder why it works with fences and other non-"normal" blocks, or is the position reset doing all the magic? However, I don't think fiddling with the server logic is the right way to go, unless it's really necessary. I kinda enjoy glitches and abusing them, as long as they are predictable and not totally arbitrary like those. Moreover, I doubt that the visual glitches are related to server-side misplacements.

Visual Errors - Cause
You're right, they're caused by the server sending bytes/ints instead of doubles. Bytes are only used to send differentials though; if an entity moved too far to represent the distance using bytes, the game will send integers instead. The way this works, the position received by clients may ultimately be off by up to 1/32. Although I haven't backtraced it, I think this glitch was introduced in beta 1.6, where the changelog states "Compressed network traffic more aggressively.", at which point they probably started sending bytes/ints.

Visual Errors - History
As I already said, I made a mod called BetterSMP some time ago which mitigated this issue as well. It was working quite good, though not as good as yours I think.
Back then, there was also the issue that the server applied the "rounded" coordinates to the entities, which you apparently assume to happen right now. So after chunk reload, the misplacements became permanent. BetterSMP fixed that, too, as well as a slime-specific glitch. The mod was then integrated into bukkit, but they found it too slow, so they came up with their own algorithm.

Some time before the client/server merge or even at the same time, their algorithm as well as the two fixes made it into minecraft (I guess they had to come up with some solution, otherwise SSP would be much worse today).

Visual Errors - Current Fix
I haven't quite grasped that algorithm yet (see EnumEntitySize.java), but the way I understand it, it relies on the size of the entities and the measures of common blocks to correct glitches in certain common scenarios.

For example, it might have been programmed so that when, say, a chicken is pushed against a fence to the south, it will notice this by the fractional part of the coordinates (which are always the same in this scenario no matter the integer part) and round the right way. And in the same manner, it might have been tweaked to fix other scenarios, or at least that's how I imagine it 😉. As you already know, the problem with that algorithm is that it doesn't always work, even in common scenarios. But what's worse is that, in uncommon scenarios, it totally fails. For example, try putting some villagers into a small area enclosed by skull blocks.

So if I'm right, this seems like a very hacky fix/workaround which is likely to cause even more glitches with future blocks/entities or those added by mods.

Visual Errors - Solution?
However, as I said before, I'm pretty convinced these position errors remain client-side, and do not affect the server at all anymore. But I also think there should be a better fix to this than the current one. Yours running client-side only could be a great solution, but there are still a some issues left. For example, chickens sinking into water, or mobs who end up falling down a cliff due to the position shift (unless your mod already fixes that). I'm gonna try to merge this on github as well, once I catch some time.

I've also tried a different approach. In a way, sending ints/bytes instead of doubles to save traffic when the whole communications is done via memory feels kinda stupid. So I tried making it send doubles again. It's working perfectly. I haven't played around with it for too long, but I wouldn't be suprised if that fixed or improved other things as well. However, the problem with this could be that it would again separate SSP from SMP, so things working in SSP might end up not working in SMP or the other way around. So maybe this might be better suited for a mod.

Float gibberish
I've also done some more testing with the floating point errors. It seems it mostly happens if the mobs' coordinates are close to a power of two, like 32, 64, .. , at which point the min and max coordinates of the bounding box have different precisions (floating point internals...), so adding or subtracting values from them may cause them to diverge, and that error can be propagated. Using doubles for width and height didn't seem to change a lot though. In my test map, the golems are at 512. I honestly wasn't aware of that back then.

Anyways, the epsilon approach based on the precision of the coordinates still feels like the right way to go.

Now, let's hope Mojang picks this up 😉

@Alexander
My code that I have reworked as an add-on to your mod is just the pushOutOfBlocks method, not the position reset. This resolves visual bugs almost entirely if not entirely as well as fixing item collisions, animals buried, etc. My pushOutOfBlocks method does nothing but move entities out of collision boxes. I have only just recently began looking at Minecraft code, so I am unaware of the history of visual errors, but due to my pushOutOfBlocks method resolving them I am convinced the visual errors have their roots in actual position errors and predictions extrapolated from them. I will see if changing the pushOutOfBlocks method to a client side mod still fixes the problem and if it has bad side effects. You are right that there are still other related bugs to tackle, but I honestly think those can wait.

Truly, the difference between your fix and my fix is that your general fix is better conceptually while part of my general fix happens to resolve many other small problems and is very important conceptually. Then you also fixed another cause I was unaware of, which is the biggest difference, and together with a general fix the problem is resolved. I am impressed and excited to say the least.

I ran a test for 6 hours with your code and my pushOutOfBlocks method. In a 2x2 pin with 350 chickens there was not a single escape, visual error, or egg which appeared outside the pen. I couldn't ask for better results.

I am not suggesting we change server-client interaction at this point. In my experience messing with width and height and the server never helped. I am simply stating your fix plus my pushOutOfBlocks method fixes this problem and other related issues with Minecraft which need to be resolved. I am so tired of my mob farm shooting items out the top and sides, seeing visual bugs, having animals escape, and animals suffocating because they do not move out of solid blocks.

Since you seem interested I will go ahead and explain my pushOutOfBlocks logic. The entity asks the world for a list of colliding block bounding boxes. Then each bounding box on the list adds to the amount of push the entity receives. For each bounding box the entity uses the same logic. If there is a column of blocks with partial or no collision boxes as tall as the entity that is a valid place to move. Then the entity chooses a direction to move in both the x and z direction. If there is a valid place to move on opposite sides of the entity it chooses the closest. The speed at which the entity is pushed is determined by a linear function with a minimum at 0.05 and a maximum at 0.1, and it pushes faster if the entity is closer to the edge. This allows it to mathematically weight its decision. When the entity is colliding with a partial block, like a door, it is treated as though the center of the door is the center of a block. The end effect is that an entity is pushed from all collision boxes to the nearest, seemingly most reasonable location. The only downside of this is that in rare circumstances this can lead to an entity being pushed into a wall which it cannot move through, something which was already a property of the original pushOutOfBlocks method. Additionally, it takes into account whether or not the space which the entity is in is a block with a partial bounding box. Then it sort of says that the entity can move in any direction it wants. Also, if the method is told that the entity can move up and it cannot move sideways it will turn on noclip and gain a vertical velocity. It will then turn off noclip next time it finds there are no collisions.

All that said, I think the best solution to this problem as a whole is your solution plus my pushOutOfBlocks code which is linked in my previous post. Together that code will make Minecraft run like it was always supposed to. Hopefully Jeb reads the comments next time and doesn't just try to tackle this himself, though I can understand why he would not read 300 comments. Repost once you get your code tweaked and try it out with my code added. Great work again.

@Daniel King

How does that pushOutOfBlocks logic work with mob traps/crushers? I guess it depends on how far does it look around for a large enough empty space.

@ArmEagle
It doesn't really look for an empty space as much as it pushes away from a not empty space. If the pushOutOfBlocks method can push an entity out of a mob crusher they could also walk out on their own, which is not a very effective mob crusher. It works like the player's pushOutOfBlocks method that it replaces, but more effectively (as in, you cannot be stuck between blocks, and you cannot be stuck inside of blocks with partial collision boxes). It should have no effect on gameplay except for making the game make more sense. It actually helps mob grinders because the current method sometimes shoots items through layers of walls, but mine works correctly.

It is not game-breaking; it is game-fixing.

So a quick comment/question on that pushOutOfBlocks: Right now there is a "push upwards if fully encased" behavior, that can be used for rapid vertical (up) item movement, as a counter to "hopper down" elevators.

Does your version maintain that? What would happen to something that was fully inside a solid wall with yours?

When an item is fully encased in a wall which it cannot move out of sideways, it moves up at the same acceleration that it did before my mod. My intent is not to add or remove features but to fix features that work unreliably and fix quirks with collision that never should have existed (in principle, one should not be able to occupy the collision box of an object). With the previous code, items were pushed from blocks unreliably, and living entities were not pushed from blocks at all. With my code, items work as they were intended to, including noclipping up through blocks, and living entities are pushed from blocks as the player was (and is), but using a more effective method. The game does not work differently as much as it works better.

Speaking of which, I fixed a few issues like items spawning inside the ground when an entity dies in a more recent update:
Unglitch Add-on 1.6.2 v17

Please move further comments and questions to the comment section on the download so we can fix update type news here where Mojang will hopefully read it. Thanks 🙂

Alexander, I mean no disrespect, but I have made a fix based on your findings which simply synchronizes certain key methods. I was able to only add a single word to 8 block files. I also found that my pushOutOfBlocks method makes your epsilon value unnecessary. So using your findings on the race condition and my pushOutOfBlocks method I have created a multi-bugfix which thus far seems 100% effective at fixing this bug as well as correcting item behavior, reducing visual bugs, and pushing animals from blocks much the same way the player is.

Here is the download. Questions, comments, concerns go in comments section on the download please.
MC-2025 Bugfix+ 1.6.2 v18

No worries. I actually mentioned this possibility in the repository readme. I chose not to do that for a couple of reasons.
First, because there are several other places calling setBounds(), for example arrows. So the collision could still get screwed up. Checking every possible method that may eventually call setBlockBounds and see which thread they could run on to get an idea what could go wrong seemed too cumbersome. You could also use a synchronization object for that, but that would make it a lot more complex in the end.
The other thing is the performance impact. I don't know by how much, maybe even on slow PCs not noticeable, at least in normal worlds But I fear it could go worse if there are lot of mobs with a lot of collisions going on. And also, I think it's a bad programming style, since there's no thread communication, so it seems unnecessary. And for the mod, it doesn't reduce the number of edited classes, unfortunately.
But yeah, it's faster to write and avoids copy & paste errors and such 😉

I have a similar problem, I turned on my game, and I had a tamed wolf sitting there for a long time now, so I decided to let it walk around for a bit, it had no problems following me into my quarry, fighting mobs and a few other things, but then when it came time for me to go through one of my chests, my wolf just glitched through the iron bar barrier I had in front of my fire place and died in there... Is this the same bug or is it a different bug but related to this one?

@Alexander
Yeah, see I thought about those things, but I don't think setBlockBounds is ever called at a problematic time besides that (I'll eat those words eventually). I was also thinking about exactly how the problem is caused, and I realized it only affects blocks which have multiple bounding boxes. That made me think to just correct those eight classes instead of the seventeen or something. After that, I thought it sounded like fun to read about threads for the first time, and I changed them to synchronized methods. Then, when I realized my pushOutOfBlocks code might work as a replacement to your threshold of collision concept while additionally fixing other issues, I thought I would just release all the code I had as a little mod hybrid. I have been running a test world for three hours quite successfully. I wish there was a more excited looking emoticon. 😃

@Joshua
Sounds like it. Especially if it was SSP. Although it could have just teleported there I guess. Try out the community fix in my previous post and see if Minecraft is less trollish to your pets.

Well, I generally prefer fixing the root cause of bugs. In this instance, it seems the whole concept of storing dynamic block bounds in the block object seems to be the root, and may probably cause other bugs, which are very hard to find because of threading. If not now, maybe in the future. So ensuring that at least the colliding blocks functions are always working correctly is what I was trying to do that with that fix by making the methods not rely on the object's block bounds at all. There may also be mods that could call setBlockBounds.
So in the end, I think this approach is much more robust (though again, there might be other places besides collision logic where setBlockBounds could cause race conditions; so the very best thing would probably to make the fields of the block bounds final and only set them during instantiation for non-dynamic blocks).
But yeah, yours is much faster to write, and since you tested it, I do think it's suited for a mod, but I honestly hope Mojang doesn't go that route.

I'm pretty sure you're wrong about this bug only affecting blocks with multiple bounding boxes. I'm not sure why you'd think that. As pointed out in the repo, the problem is that the affected blocks store each of their dynamically generated block bounds to the same fields in the block object and rely on it not being changed before retrieving it again. But when both client and server generate the bounds of the same block at roughly the same time, one may override the generated bounding box of the other. This is not only caused by a block consisting of multiple block bounds at the same time, but also by different bounding boxes being possibly generated for the same block, depending on their coordinates, orientation, meta data, adjacent blocks etc. (I call them "dynamic"). It's just more likely to happen with multiple ones, because then the game has to spend more time for that so the chance of the threads "overlapping" at those checks is bigger.
I also tested it out just now. Try enclosing some villagers with full blocks in a 2x2 horizontal space or so, and put open trapdoors (vertical) on the walls. This way, there will be a lot of collisions going on with open trap doors. Now, make something like this: http://i.imgur.com/AK3dRZw.png , where the villagers (or other mobs) can escape their cage by glitching through a closed trap door. Since there's a chance that the closed trap door can be treated as an open one, you should see some villagers glitching through and falling down

Edit: In case you want to try that scenario with my mod, you have to change the first if condition inside getBlockBoundsOnState to "if ((meta & 8) != 0)" instead of "if ((meta) != 0)" to fix the bug you discovered.

Man, you are so right, I did not realize the implications of all blocks being the same instance until very recently. Every Block class operates under the assumption that it is running in a single thread, which is a problem when it is not. The best fix would probably be store blocks in a ThreadLocal object, but I cannot imagine the work that would go into changing every reference to a block so that it works through a ThreadLocal object. So instead I changed min/max X/Y/Z in the block class to ThreadLocal objects. It looks like this fixed all possible thread problems relating to bounding boxes, and some rendering issues. 😃 I'm a little busy right now but I'll upload the new code within the next few hours.

EDIT: The mod's up and ready for testing. This one should be pretty solid:
MC-2025 Bugfix+ 1.6.2 v19

Oh, now I see why you were thinking that way..

That's an awesome solution, great job! 🙂

Daniel, careful with the threadlocals! The way the block class have been designed is based on getting it to be fast (and single-threaded). Of course, there are some flaws in the current implementation. (This issue is not the only issue getting bitten by the assumption of working in single-thread and then getting messed up due to using member variables statefully...)

However, threadlocal vs. direct field access can be e.g. 10-20x slower (results of one test on a 1.6 jvm), and depending on how often those variables get accessed, can become a small burden.

This is why threadlocals are typically used to hold just one or two specific objects, accessed at high enough level (e.g. in the begin of a longer running method thus reducing the number of accesses per time unit), and those one or two objects are then used to get more data with direct field access.

Markku, I trust your judgement, but I believe the threadlocals are a necessity. I completely understand why the block class is designed the way it is, but it is not designed to take more than one thread. I think the best option is likely a very high-up rewrite of the code to make two different block classes. Unfortunately, I do not feel inclined or qualified to change how some-odd thousand lines of code access blocks. I am, however, considering packing the 6 doubles I modified into a single object which just simply contains bounds. Then I could stop dealing with autoboxing, it would do away with the annoying @override code I had to write, and I could reduce the threadlocals and increase performance.

I appreciate all you guys who have been very helpful by the way.

EDIT: Well, I did it. I would have preferred to put, essentially, the entire Block class into threadlocals, but I am just not going to go to the effort for a mod. I wrote a couple simple classes to hold the bounds, so no more weird method code blocks and no more superfluous threadlocals. The perfectionist in me is pretty satisfied. Here's the link again. Please post questions, comments, concerns, etc. in the comments section of the download link.

UPDATE: There were some initialization issues I overlooked. I had to edit 37 different constructors to get blocks initialized correctly. There were weird effects due to the client and server disagreeing on block size.

MC-2025 Bugfix+ 1.6.2 v21 🙂

@Giurgiu Razvan
I greatly appreciate your reports. I believe I have fixed the source of the problem. But, in the future, please leave comments in the comments section of the download link. That way my link stays visible and everyone can focus all their anger at me for spamming them with email as I constantly post updates here 😉.

Karma dictates I that if I say this is probably the last version I will have to fix something, so I will only say it is very stable. I hope this mod improves everyone's Minecraft-ing and helps Mojang.

MC-2025 Bugfix+ 1.6.2 v23

I have a fairly simmilar Problem and i have made a seperate bug report, but i am commenting on this so maybe it may be seen.
My problem in 1.6.2 is that Mobs (in particualr animals such as sheep/cows), when fenced in an area with fence, glitch and pass through the fence. they do so when simply attracted by a piece of wheat. i have tested it on creative and i have shown that it takes about betweet 5 and 30 seconds for sheep (in particular) to be attracted by on a straight wall of fencing, to pass through the fence. No chunk loading, or even re-logging; the mobs just go through the fence.

@Tyler Boudrias
Is MC-10 what you are experiencing?

Bugfix - Please read this post before commenting

This bug report has, unofficially, come to encapsulate both mob escapes during gameplay and on load. The reporter of the bug had been inactive for a long time, but much discussion about the bug and its causes has been occurring in the comments. I will say the symptoms you have experienced sound a little extreme, but I would encourage you to try this unofficial bugfix (link at the bottom) which has the following features:

• Animals do not escape during gameplay or on load

• Item behavior when being pushed out of blocks is greatly improved

• Animals are actually pushed out of blocks

• Visual errors (MC-10) are mostly if not entirely resolved

I do not wish to appear like a conceded jerk who believes himself the only one with a right to post here, but the comments which confirm the occurrence of this bug are unnecessary. I would appreciate it if the download link can remain visible to everyone who finds themselves on this page. That way, Mojang can clearly see what needs to be fixed when the time comes to fix it, and, in the mean time, everyone else can play Minecraft without stressing about animal escapes. If this bug is not being worked on in the next snapshot I will probably post the link on the forums to bring attention to the issue.

Any questions, comments, or concerns about the bugfix should be posted in the comments section of the download link. If it is not working or has weird side effects, let me know, and I will fix it. Thank you for reading.

:red_star: MC-2025 Bugfix+ 1.6.2 v23 :red_star:

Bugfix - Please read this post before commenting

Mr. King: I tried using Magic-Launcher to add your zipfile, but it wasn't recognized as a mod. Would it be possible for you to put out an archive organized as a mods?

@David
I have no experience with Magic Launcher. I can not change the organization of the zip folder because it is technically two mods: one for just the client and one for both the client and server, but I did add some basic instructions to the readme on how to reorganize it yourself. The information I found was essentially taken from the Magic Launcher thread on the forums. I do expect compatibility problems with a lot of mods.

@Daniel
Thanks! Magic Launcher at least accepts the divided files, so I'll be trying them out!

I did some more investigating, and discovered some more (easy to fix) bugs, mostly related to client-server synchronization of entity positions. Also, I revamped my epsilon fix to rely directly on integers, which should make it much more efficient (though still slower than a simple comparison of course). I also had to increase the tolerance a bit, because I found some setups which caused higher errors. Most noticeably, when entities are being pushed upwards (eg by water) at certain y-coordinates.

I also decided to do redo the server position adjustment algorithm (responsible for mitigating temporary client-side glitches). I already attempted to do so in the past, but I wasn't satisfied with the results. However, now that all the other bugs are out of the way, things are looking much better. I don't wanna say visual glitches are fixed 100% by the mod (they're not), but I think it's pretty close now, and certainly a major improvement to the current situation.

Here are the links:
Repo: https://github.com/taurose/Unglitch (thorough explanation, test worlds, source snippets)
Direct Mod DL (Client): https://github.com/taurose/Unglitch/raw/master/Mod_1.6.2-v2.zip

What it does in a nutshell:

• fixes server-side permanent, entity glitches on load (MC-2025) and during gameplay, hopefully 100%

• mostly fixes temporary, client-side entity glitches (MC-10)

• fixes client-server synchronization issues (cause for MC-19331, probably more)

• in contrast to Daniel's Mod, this mod does fewer changes to server-side game physics by not relying on an universal pushoutofblocks method. It doesn't fix the glitchy behavior of items or xp orbs, and presumably breaks fewer contraptions than Daniel's. On the other hand, Daniel's fix might be able to account for some rare or future glitches.

I would like to remind everyone that the JIRA is used to discuss issues in vanilla Minecraft. Please bring discussions of mods to their respective pages.

Nathan, it's actually a valid request to have discussions regarding the mods be posted on the mods' pages. While I'd argue that it should be alright for a bugfix mod creator to post about their mod and updates to it (and most importantly, details on how it fixes the bug - this is what will help Mojang the most!), users shouldn't post about problems caused by said mods here. Daniel himself has said we shouldn't clutter this page with discussion specific to issues caused by his mod.

Link to Daniel's post because it's getting buried again

Proper place to discuss issues and suggestions for Daniel's mod

Proper place (I assume) to discuss issues and suggestions for Alexander's mod

Signed up for github so I could leave a comment for Alexander, and deleted my comment above. @GrygrFlzr: Happy?

Having this issue in 1.6.2
Mobs getting stuck in fences, constantly running, escaping pens! My farm is a mess! Cries in a corner My perfect line of rainbow sheep's ruined >.<

I made a mob spawner in skyblock, so now there are like 200 mobs in a 1x1 area. When I stop the (bukkit) server and restart it, they escaped.
This bug is not fixed for bukkit. I don't know about vanilla though.

Alexander Gundermann and I have been working on a fix in which he has mostly found and eradicated all the little causes while I have backed it up with a method which should prevent any rare and unpredictable cases mostly due to client-server discrepancies. Until we have totally worked out all the kinks, here are the links to the most recent forms of our individual mods. My mod changes the game mechanics a bit so that animals are pushed out of blocks just like the player is, and not just solid blocks, but fences, doors, etc. Alexander's mod mostly has low-level changes to the code to prevent phasing through walls ever happening. Both of them change calculating of block collisions for integrated servers, but in different ways.

Alexander's Mod
My Mod

Keep an eye out for a collaborated release.

Can we stop making mods to fix this and resurfacing the links because that qualifies you as spamming.

Sounds like an excellent idea to me, as soon as an actual developer gives some kind of indication that they've seen them. After that, reposting the links becomes redundant. Until then, it's topical, not spamming.

Btw, Alexander and I did some work together, and the finished product is on the forums.
http://www.minecraftforum.net/topic/1920678-162-unglitch-fix-for-escaping-animals-and-more/

I will no longer be "spamming" this page, and I promise to make no effort to resurface this link. Hopefully, if the mod gets enough awareness and support Mojang will notice. I request that people refrain from posting here so that the download is visible to those who make their way to this page. Adieu. 🙂

After successfully using Daniel's bugfix, I can confirm he and Alexander offer a valid example of how to eliminate this and a few other persistent bugs. Thank you Alexander and Daniel.

oh come on mojang! the answer is right here --> http://www.minecraftforum.net/topic/1920678-162-unglitch-fix-for-escaping-animals-and-more/

As with 1.6.2.:
putting 50 chickens into a 1*20-Space, in smp on a internet server, let's them visually glitch out all the time, but that's just a visual error.

But when I move more then 60 or 80 blocks away (so that the chickens aren't displayed anymore), wait a while, and then come back, then some of them are for real out of the fences (disconnecting and new login doesn't change it).

So, it doesn't happen when the chunks get unloaded and loaded again, but also when you walk 80 blocks away and come back again.

unless you place the chickens near the spawn. Because spawnchunks are always loaded.

This code works perfectly! It needs to be implemented.

http://www.minecraftforum.net/topic/1920678-162-unglitch-fix-for-escaping-animals-and-more/

Still noticing this issue in 1.6.2 - Adult horses are getting stuck in blocks and suffocating upon re-entering chunk.

Noticed this with large amounts of animals in a small area; they are being pushed through fences by the other animals. This problem is possibly related to zombies being able to attack villagers/players through fences/doors.

I've noticed something... odd since Jeb announced he had fixed this. Everyone noticed that problems with baby animals stopped, or at least reduced, but I have three animal pens in my spawn chunks, and both the cows and chickens regularly break free of their pens, but the sheep are packed into a very small pen, two of each color, and I haven't seen a single escapee. Not one. And they're packed in their so tightly they vibrate like they're about to explode.

Zaecus Celestis, I have had a nearly opposite experience. Without the "Unglitch for escaping animals and more" mentioned above, my sheep escape almost exclusively. Mine are not packed into a small space tightly. They have plenty of room and should not be forced together causing some to be pushed through the fence.

It is curious that we could have such opposite experiences with this bug. For the record, since I have started using the "Unglitch for escaping animals and more", I have not had a single escapee. I intentionally over bred my pigs, cows, and chickens to cause overcrowding in their pens and not one ever escaped. For me, the unglitch has resolved this, and a few other problems. I hope our Mojang friends give it a serious look.

I'd like to state that the same problem is still occurring in both my computers (1.6.2 on both, one Mac and one PC). I had cows and chicken glitching. It might be hard to measure if the mobs are glitching more often or not, because it's happens so randomly, being many in a compressed space or not. After running my Chicken Farm for some hours now, I have to say that I can't really notice any difference when comparing to prior versions.

I've noticed it happens far more frequently with newly born animals, the amount of calves, baby sheep and chicks i found outside their double stacked wooden fences where far far higher than adult ones. in over four weeks of this I happened almost every time i went on a breeding EXP spree. so it was happening right as i stood there and watched. along with getting stuck in the corners of the fences. doesn't seem to happen with solid walls. haven't tried stone walls yet.

This happens with chickens more often than any other mobs..... Probably because of their small size. One of my chicken escapes its pen every 3 minutes and my sheep do this every... Humm I don't know... Maybe 20 game days?

This is definitely a bug and I've been dealing with the issue since 1.7.3 Beta when I started minecraft. I like large-scale ranches. Unfortunately I can't think of a simple way to address the issue since the root cause is block coordinates--any lag in communication has the chance of this happening. At least in my case, I get hardly any escapees on single-player with the exception of chickens occasionally. It is on multiplayer that I see significant escape numbers. I think this is because of communication lag as it's worst client-side. Though it has improved significantly since the latest "fix".

I've experimented a lot with designs that minimize escapes, especially in the case of colored sheep as the ideal number is 2-4 for each color in my case and if too many escape the process of transferring and re-breeding takes longer. My solution was to use transparent base-blocks for the pens but not fences as they seem to have a higher incidence of escape. I use glass bases as it still allows grass to grow underneath which will then spread back into the pen, making sure the sheep never completely defoliate their pen and stop regrowing. This also has the added benefit of removing suffocation deaths and since the base blocks are transparent animals stuck inside aren't forced back out like in a solid block. I believe this to be the main root of solid-block escapes when loading a world. For the most part animals cannot venture far enough into the glass to be forced out the other side, though chickens will occasionally sit inside for long periods I've never observed them escape out the other side except in the case of breeding or throwing eggs but this is a breeding-spawn issue. I put a solid block layer on top for a 2-high pen with a ladder that allows the player to jump in and climb back out quickly for shearing--but not the sheep. Since this design I've repeatedly quit in the vicinity and re-loaded and also ventured out and into the chunk quickly while flying. I have observed no escapes throughout several hours of gameplay. If you have the same problem as me try this design for escape minimization though I'll admit I have not tested it on my multiplayer server yet.

This has always been an issue in multiplayer, but has never been a major issue in single player until the implementation of the internal server. Since then, I have observed the issue happening even with lone animals, chickens especially.

Problem still exists in newest snapshot. Experienced on single player hard survival. small fenced in area 1x7, both chickens and cows escaping for no apparent reason.

Minecraft 13w41b. Horses suffocate when creating worlds with these seeds:
-7235924328332066140 - very close to spawn, you can hear them
-3684484393121089528 - close to spawn. walk just a little bit to see the area

In the latest snapshots, I have a skelly spawner farm at my home base. The farm uses a drop chute to damage the skellies before I kill with 1-2 hits for xp. Upon reloading, some of the skellies are out of the drop chute landing zone (a 1x1, encased in stone area except the for the kill slot which is not big enough for them to escape and is at their feet level). Sometimes they are wandering around my base, sometimes they are outside in the lake. They are clearly escaping the drop chute upon reload.a

It happened for me in 1.6.4.

Continues prevalently in 1.7.1

All my animals stay within the fences, except cows.

They're doing this even when the chunk is loaded and hasn't been reloaded! It just happened a second time.
The first time, it was a Zombie Pigman. Just now a chicken escaped.

Happy birthday Bug. 😞
Can we maybe get the same attention put into this major gameplay issue that was put into getting 1.7 released so quickly?

I'd be happy if it got the same attention as the structures not saving bug (witch huts, nether fortress, etc.). Both have player submitted fixes. One is fixed, and there's no indication the fixes submitted in the comments here have been looked at beyond a mod saying they couldn't be posted as attachments.

I don't think Mojang actually looks at player-submitted fixes at all. They "fixed" this one without looking at the player fixes, and their fix was too incomplete (namely, it didn't actually fix the problem for many players), which is why this ticket was reopened. I asked Dinnerbone, and it doesn't look like they really bother due to MCP != sourcecode, so I don't think it actually makes any difference whatsoever that people have fixed this already.

Happened to me in 1.7.2.

Continues to be a problem for me in 1.7.2. For now, I put animals in two deep holes and use a trap door to get out. That keeps them contained. Eventually, I build a barn around fenced in pens on ground level. It sucks the bug hasn't been fixed but there are ways to deal with it.

If fellow bug reporters want to complain about bugs, please do it elsewhere. I don't need notices everytime someone wants to berate Mojang or their staff. If there's valuable information about the bug, confirmation of continuance in a new version or potential ideas for fixes or workarounds, post away.

If you punch the mobs, they go back, the reason why this glitch happens, is because there are too many mobs in the area, so Minecraft keep rendering them as "out"

I've personally seen them escape from pens that were by no means overcrowded so pretty sure that this is not the problem.

Yeah, it's not the problem. I've seen single sheep escape pens. It may be more frequent with overcrowding but there is a defect at the root of the problem. Not sure why punching makes any difference. If the mob is out punching it just makes it run around.

This has happened to me without logging out or unloading chunks. I was in a village, and walked around my pig's "house", and when I came back, a pig was roaming free. I'm just glad villages have carrots.

3 months without a fix? rly??

Still present in 1.7.4.

Still present in 1.8's snapshot # 14w02c I don't know to add that to the "affects versions:" list.

Only the original reporter or a moderator can update the affects version/s list.

Confirmed. Still an issue.

That bug is a must to fix!!!

Because it ruin all effort to maintain a farm into the game. I was having a sheep farm of every colors, with that bug their is no way to maintant that kind of farm, sheep are escaping their fences or die.

This is realy anoying, this is probably a mob's hit box problem.

A post in MC-119 has me running a test of both errors. Is anyone able to replicate it on an unmodded 14w07a? I have not yet.

Able to replicate on an unmodded 1.7.4.

Still a concern in 14w08a.

More than just "still," this has been made worse by the change that made leaf blocks able to cause suffocation damage. Animals now spawn in (and pets freely teleport into) blocks which trap them and cause their death.

I am using piston pointing upwards with pressure plates, my farm is underground. The entrance is made of a iron door and a button.

Confirmed for 14w10c

MC-49701 has been marked as a duplicate of this bug and I think it is describing a different problem. Can a moderator please reopen MC-49701. Alternatively, can the description and labels of this bug be updated to include:
Animals spawn in and pets freely teleport into blocks which trap them and cause their death.

I would also consider this a separate issue from the MC-49701; this is about small position changes during save/load of chunks (and in some cases even without that save/load), MC-49701 is more about bringing a mob out of nothing or from far away into completely new area which happens to have leaves.

Instead, I think MC-49701 might have something to do with MC-2102.

I tested it once again on 14w11b. I left my Minecraft unpaused for half and hour near a small room with 7 pigs inside. In previous versions one of them would randomly walk into a wall suffocate within a minute, but now they didn't. I thought the issue is resolved, but after reloading the world one of them briefly got hurt near the wall... so it's still unresolved.

I see no easy solution to this problem.
If additional checks or constraints would be implemented at chunk loading time, it could lead to lags.
The players should let the animals have enough space to enjoy their life and don't push each other into the fence 🙂
Imagine you are in a crowded elevator and it gets stuck for several hours.

it doesn't matter what size of pen it is, even large ones cause suffocation damage or glitch through. and on servers where space is restricted for Player villages as well as claims. there is no option, they have to be small. one of my fav servers has wild mobs at scarce settings so finding mobs is a rare thing and are highly valuable. only to hear them die or wonder off your claim and get stolen because of this bug.

Agreed; this bug isn't even limited to fenced-off areas. You can have animals dying by walking into natural terrain. It's not so much a matter of "enough space" as it is "have an endless completely flat plane", if you want to avoid this bug. It doesn't help that AI makes animals gravitate towards the edges of enclosures essentially regardless of the enclosure's size.

Also, more checks at loading time wouldn't always be the end of the world. Whenever Mojang adds a new NBT tag to an entity or tile entity (such as when the naming feature was added), that's an extra check.

I've seen this issue before (< 1.7). But in my two small latest pens (1.7.4 bukkit server) I've never had a cow or pig escape. They aren't totally packed, but still.
They are in the original spawn chunk. But the spawn was moved and I'm pretty sure that this chunk is now being unloaded.

Suffice to say, this is a long recognized bug, not yet fixed, and it happens with all mobs. I see villagers and all other mobs dangling like spiders as they glitch through a floor or wall and then snap back- or perhaps they don't snap back during chunk load.
Mojang, we don't need more features right now. Please dedicate a build to fixing these widely recognized annoyances. Thanks.

Still happening at 1.7.9!

Animals stuck in the fence, reloading the chunk/server move then to the other side, and so on.

still present in 14w11b

Mojang, we really want this fixed. it's actually making minecraft kind of unplayable, at least for the farming field. for now, we can't make egg farms, slaughterhouses, or trust that any of our horses are safe and let them stay in the house with a diamond horse armor on.

Everything in life has good side and bad sides. This bug seemed to be an exception... But now I realized that it allows me to obtain feathers and meat without feeling guilty killing chickens 🙂
If you fix this bug and when I die, if I spawn in the nether, I will say Mojang forced me to kill the chickens! I'll bring you into the nether Mojang!

Still a huge problem in 1.7.9, actually seems to be WORSE than in some recent releases.

I have a Skyblock world with several animal pens and a mob farm. Every time I log in using 1.7.8 or 1.7.9, I have animals out of their fences and hostile mobs running all over the place, when they were safely contained upon logout.

Please fix!!

This is a HUGE issue mojang. none of our animals are safe.

I have a suggestion. why not, make a code that gives every individual animal an assigned number, and that way the game will say, "ok chicken (number) is on block ❌ 👍 (z). data saved."

@@unknown: The game already does that. It's not enough. The problem is with rounding, physics, collision detection, client-server miscommunication, and chunk management. It's not a simple problem with a simple solution. It's still a problem not because they haven't tried, but because it's a difficult problem to solve. You spamming the comment section not only doesn't help, it sends an email to everyone watching the issue, which is sure annoying. I imagine most people are watching the issue because they want to be notified when it's been fixed, and spurious messages only bring false hope and irritation.

I realize this is not nearly as good as a fix by mojang but I did some testing in 1.7.2.

http://www.minecraftforum.net/topic/2598764-surv17xthe-end-of-skyblock/page__st__60#entry31713095

If it's a TLDR build this fence 2 blocks lower than the surrounding land. (pictured it's only one block lower for clarity)

http://i.imgur.com/s4VGErS.jpg

My thread explains why other designs were scrapped and why you cannot just build a pit of dirt/stone/etc due to wall suffocation from pushing animals. Suffocation and glitching through fencing happens REGARDLESS of whether your farms are big or not. Saying we're not giving them enough space to roam or we're overcrowding, etc. etc. is moot as overcrowding only speeds up a behavior that would happen inevitably. Animals, sheep and chickens especially, will attempt to escape even if they are given generous areas to roam and this is why this issue remains today.

I've come to find you have to use a combination of everything including the lay of the land to trap mobs and animals successfully.

Though I hesitate to wager a 100% workaround on this issue I feel this is as close as one can get.

So using only fencing, only the lay of the land or an incorrect combination of the two will mean your animals will either suffocate, glitch out or a combination of both.

Anyways hope this helps.

About workarounds.. I am not 100% sure how safe it truly was, or is now, but a while ago I happened to try putting another round of fences around the inner fences, immediately adjacent, no gap in between. At least back then I didn't ever notice a single death (judging from counting the animals occasionally when visiting the area or working there for longer periods). Some of them did get stuck in corners, and it required some work to release the victims. Usually I just left them stuck unless I needed them to move (for breeding or counting).

It is a bit more pesky to get in and out (two gates needed, too, unless using some more exotic means to get around the fences).

I haven't played with survival mode at all lately, mainly due to these animal farming issues, so I have no idea how that arrangement would work now.

@Markku - keep in mind (if you haven't dealt with it recently) that simply putting a carpet on top of a fence will allow the player to jump over it but not any mobs.

@[Mod] fienxjox - Is the carpent on top of a fence method still valid in the latest snapshots? I revisited one of my "old" worlds that took advantage of this and I experience as mass exodus of cattle and sheep...

Anyway, back to the discussion topic. I believe the entities are able to escape because when they are pressed up against a wall or fence, their hitboxes partially merge with the wall, making it so that they are partially inside the block. When you leave the area and come back, the entity is rendered inside of the block and can move around within it freely until it exits, similar to you pushing a block into your feet with a piston. However, this is just my theory.

that doesn't matter. animals don't "jump" over the fences, they generate somewhere else.

I'm sad this isn't fixed yet. Its part of the reason I stopped playing MC. (See my last comment above 1 year ago)

Confirmed in 14w26b, and probably still in 14w26c.

Cant they just see what they changed in 1.4.2?

Confirmed in 14w27b. Jesus man.

Confirmed for 14w27b. Jesus, mojang, I know youre busy but come on.

It's sort of insane for Mojang to not make a determined effort on this issue but to ask people to confirm that the issue is still present in each new snapshot. I mean, we don't need to confirm the issue is present, we can assume that's the case until told otherwise, so don't bother reporting the issue as still present in every single snapshot. They can setup a test as easily as any of us. Mojang, how about You make an effort to address this specific issue, rather than playing with bunnies, and then just tell us when this one looks finished, eh?

They haven't been spending a lot of time on "content" (bunnies were something @unknown made in his spare time), or concentrating on specific bugs, because they're currently busy ripping out and rewriting core parts of the game code, and may inadvertently fix numerous bugs in the process without specifically attempting to. There's not much point in spending time and effort "fixing" bad code that you're going to replace anyway.

The work they're doing on how blocks are defined, stored, and loaded may fix this issue, as well as numerous other bugs. Or it may require them to rework entity physics, or how they're loaded, which would also solve other bugs as well. Regardless, they're trying to spend their time efficiently, so that more bugs get fixed in the same amount of time. That does mean that some of the more complicated bugs will take longer to fix, and this bug has already survived several focused attempts to eradicate it.

Even if this doesn't get fixed as a side effect of other work they're doing, that work will still make it easier for them to fix this when they next make a specific attempt to do so.

Seen in 14w28b. Horses spawned in the walls of a church and suffocated as approached a village (flying in creative mode).

Each time a new snapshot is released, I see "We have a new bug tracker website! Please report any and all bugs you find in Minecraft to bugs.mojang.com. If nobody reports a bug, we can’t fix it!". And I hope.

But I hope they will fix another bug, not this one. (I feel guilty if I kill animals but if it happens...)

Is anyone seeing this in 14w29b? I haven't finished testing, but my current experience is that this problem may have been reduced or eliminated, at least in brand new worlds. Anyone testing this in an already existing world?

So far, the only problems I've had in my testing is that a small number of chicks pop through the fence of a seriously overcrowded past regulations pen when they grow up. No other escapes. No deaths.

Still happens in 14w31a, but the likelyhood has been reduced.

I still see this in 14w31a too. I think the reduced likelihood that David Wheatley mentions may be due to strange MOB pathing in this snapshot in general, more than anything that resolves this bug.

If you build a 1 wide fence pen, they escape through the less than full blocks when the chunks unload/reload. If you build a 2 wide fence pen, they still escape by moving to the middle on one chunk reload and escaping on another.

An alternative is to pen animals in a 2 deep hole, but MOBs can still move into the solid block walls when chunks reload. This causes them to escape unless the walls are 2 or more blocks thick, then they suffocate instead.

This bug still exists in 1.7.10. The pens need not be crowded. Animals just get out when chunks load.

Did the fix to MC-67127 change anything regarding this bug? (Just thought since they are both entities behaving strange when not around)

still happening in last snapshot (14w34b) on mutliplayer. Just logged off from my server and a couple of animales with name tags were roaming around out of the fenced areas.

I confirm

Hey guys,

the bug is ongoing and is worse in multiplayer (though happens some in singleplayer) due to the more complex terrain loading states.

However, you can get around it and prevent escaping animals AND suffocation death with some clever pen construction. I will share with you my workaround for the bug and the reason why I haven't griped about this bug in 2 years:

First, I did a test a while back in beta, the problem is less commmon now, but back then I'd lose all my animals. Even doubling walls, etc. did not work. So I finally decided there was no way to pen them efficiently with walls/fences above ground.

Step 1: dig your pens into the ground. I make all of mine 2 deep and inset into the ground like a shallow bowl. This keeps any animal from escaping because over the 1-2 seconds even if they wander through the walls there is no unoccupied blocks so the code snaps them back into the pen as the closest safe area.

Step: Dig out the bottom wall edge of all around the dug out pen and replace it with glass. This does 2 things: 1 it prevents animals pushed into walls by a crowded pen from suffocating as glass is non-opaque and they can breathe in it. It also allows them to move back out later when they can. 2 for sheep it is a nearby source of grass they can't eat and therefore they can't defoliate their entire pen so you can keep colored herds more compact.

I've been building these pens for the past 2 years and no animal has escaped or died since. I'd recommend spacing dugout pens 2-3 blocks this ensures they won't mix via the glitch.

Ive tried this with bunnies, villagers, and sheep, don't have this problem anymore.

Sheep are being affected for me. Today I found 2 of my blue sheep roaming around close by outside of their pen.

Still happening in 1.8-pre2. If someone could update the affected versions, that'd be nice.

wouldn't a good fix would be to make them stay away from fences unless their being lead my the player with weat or whatever then all a player would need to do is to make the fenced in area big enough for a certain amount of animals.

As I think this happens because the game loads first the entitites and after the block's hitbox. The animal goes around when loading the hitboxes and thus gest inside or outside of the blocks.

Good things about having a crappy computer.

That makes me think about this as being a rather simple matter - probably complicated by the realities of the code. When unloading a chunk, I'd think the order should be 1) stop all entity/block actions, 2) unload entities (mobs, animals), 3) unload blocks. When loading, do the opposite: 1) load blocks, 2) load entities, 3) activate entity actions. As to actions across chunks, any action that involves another chunk needs to get put into a hold queue until the other chunk is loaded. So an active mob in a chunk that was just loaded shouldn't be able to move into the first block of the next chunk until that other chunk is itself fully loaded and active. Doesn't that solve the problem?

@CaptainStarbuck i dont think thats the solution to the problem. 1 + 2 = 3, as much as 2 + 1 = 3. The way you unload the chunks and entities doesnt really matter imo. A valid solution could be that entities inside a transparent block as fences al teleported to an adyacent free air space. If we say the entitie is at X: 3.4, Y: 70, Z: 3.47, it should be teleported to X: 3, Y: 70, Z: 3. This would be just a quick fix that i can think of as im writting this. No idea of its aplicable or not. What Im trying to say though is that it doesnt matter the order in which you unload stuff. Or at least it shouldnt 😛

Of couse im saying this taking into account that entitied shouldnt move before the chunk is loaded. Otherwise you would find dead chicken, cows, even villagers everywhere sofocating in walls and stuff. Again, unless transparent blocks are not even seen by entities, in that case they could just traverse them. But, right here is where I at least hit the wall as im just talking off without even knowing the source code. We could be right or we could be as wrong as it can get, hopefully mojang fixes this soon. As far as I've heard, in the last patch overhaul, they did some intresting patching to the block data itself, so might finally be seeing the light at the end of the tunnel here 😛

@Alejandro - as a software developer who writes this kind of stuff every day, I'll confirm for you that the method I described is exactly how we do things - we unload software in the exact opposite order of loading. For example, you walk into your room, boot your system, start your game, and play. Then you stop playing, turn off the game, shutdown the system, and leave the room. It goes 1,2,3,4, then 4,3,2,1. Anything other than that is either impossible or problematic. The order I proposed suggests that for loading, solid objects get placed first, movable objects second and Then that movable things can start moving - once the solid objects are firmly in place mobs won't move into/through them. For unloading, mobs need to stop moving before solid blocks are removed. Otherwise when everything comes back their location will be where a block was and they'll suffocate when blocks reload.

As to your statement "Otherwise you would find dead chicken, cows, even villagers everywhere sofocating in walls and stuff" - that's exactly the problem that needs to be fixed. That's what this whole thing is about. 🙂

And all that said, obviously Mojang knows their own code and doesn't need us to analyse it - but then again this issue has been around for 2 years now so I'm not sure what kind of nudge they do or don't need anymore. 😉

They thought of that. There's an explicit condition that checks if all chunks within a certain radius (32m iirc) have loaded before an entity is updated. Of course, there could still be a bug in the way that implemented it, but it's not like they completely neglected it.

For what it's worth, I've done a lot of debugging last year in July for 1.6 to narrow down this issue (as have others). My main findings can still be found here https://github.com/taurose/Unglitch , and in the comments above. To sum it up, there were a lot of different problems leading to this issue (and related ones), some of which were really easy to fix (ie changing 1 line), while others seemed to be conceptual problems that would require a lot of changes and compromises in terms of performance or even network bandwidth.

This is precisely right.
Please listen to to CaptainStarbuck
You must load and unload soft ware according to a LIFO queue. (Last In, First Out)

And, even if you ignore that software rule, you have to recognize that this is a LONG term issue, many people have studied it for a long time. So, ou cannot continue on assumptions like "it shouldn't behave like that". There may be facts, seen in another light, that will uncover things what we thought we knew, but didn't. There is obviously something wrong with your approach, otherwise it would have worked by now - or proven why it doesn't.

Give in to "I don't know" with this proposal. Prove that this is not the problem. Only then can you move on with clear conscience on to the next possible solution.

I wish there was a Thumbs Up button on this, would save me from saying
Very well thought out, Very well said. Good Job Capt'n! etc...
Reason and Logic always solves the problem, This is the same way I have done things in my programming life with databases and business apps.

for a temporary fix,dig 1 block into the ground, build the desired pen size,outline it with fence posts/cobblestone walls,then place carpet over the fence posts/cobblestone walls. this should allow you to enter and exit the pen and the animals will not be able to escape.

This sort of glitch seems to happen all the time with non solid blocks, most notably the hitboxes that don't cover the full 1m by 1m block. It also seems like there either won't be a fix for these issues or it is very difficult to fix the code for it to work properly.

anyone know if mods like forge micro blocks can salvage fenced pens with the pannels without having to dig 2 blocks down or glass blocks or the other fixes like Aaron stated.

Mods are very unreliable and should not be used to solve your problems. Besides, the temporary fix I mentioned works just fine and isn't that big of an inconvenience.

@unknown: The "temp fix" as you mention is not a fix at all. It is quite seldom people just use regular pens for animals. Also this is not only a concern for animals, but for all living entities. Other entities might not be that much of a concern if you load/unload chunks by moving away out of range in the overworld since they will despawn, but much bigger so if you use nether portals and thus unloading the chunks without despawning hostile mobs.
An example of things that happen because of this is that zombies bug through walls and get in to areas where you have villagers.
Another example is when you have a mob farm storing up mobs and if you go in/out of a nether portal they might just suffocate and die.
In these cases (as in most cases) you can not just dig down one block to solve it...

This is supposed to be a highly effective temporary fix/alternative, and all I'm doing is providing a useful technique for people to use until the actual issue is fixed. Try testing this yourself, or at least provide some better advice than I did.

This issue also mainly relates to animal pens, which is what I provided an alternative for. I have not worked on any of the other problems you mentioned, and I'm not sure I will be able to.

For me this is happens much more often in 1.8 than in 1.7.10. I decided to stop playing, until this bug is fixed. I'm tired of killed villagers and escaping animals, whatever the reason for it is.

Yes, most animals seem to be able escape in 1.8. I think even horses.

And rabbits, if they don't escape, they can get stuck in fences.

The "issue" is density. To many MOBs in a given area will cause these results. My main experiment was done with a chicken farmso far a two per square seems possible no deaths or escapees. Farm consists of top floor built of hoppers with rugs covering them into minecarts for transport could use a dropper or such instead if you wish to hatch on the scene.

A single mob with plenty of room to roam can still escape its enclosure during chunk loading/unloading. This is incredibly frustrating.

Even with a large pen, sometimes mobs will just clump together in one corner and clip each other through the fences. I've also logged out, logged back in, and rabbits were outside of the pen.

TBH I've had similar problems with fences across every version of Minecraft since sometime in 2012. I've just stopped using them, because there's always something weird happening with them.

The corner thing has to do with their AI, which although a different issue, does exacerbate this one.

The corner tendency seems to be caused by a few problems.

1.) The push back effect when entities collide gets multiplied when mobs stack.
2.) Because of the high density of mobs in the pen, many of the mobs will be pushed and held in the corners and along the edges.
Since there is no force pushing them back towards the center, they get pinned down.
3.) When mobs are pushed into a corner, their coordinates become: (x.5, y.y, z.5).
4.) When they are in this "fixed" position, they can not move towards the adjacent edges, and they can not overcome the push back effect of the
other mobs pushing them into the corner, and they are therefore stuck in the corner.

There are way too many comments off-topic and about other bugs. In order to keep the developers focused on this one issue, I'm hoping people will keep comments focused - though really there's nothing more to discuss on this until it's fixed.

This is Not about density, we see this happening with just a few entities. The AI (gathering) issues are already documented in other tickets. This is not about glitching - whether the snap-back type or getting locked into fences, though it's probably related. Technically, while it's in the subject, this also has nothing to do with "suffocating", since that's just a consequence of where some entities happy to reload.

This is only about entities which are in one location when a chunk unloads, and somewhere else when the chunk reloads. That's very simple and it's easy for the developers to see for themselves. After a couple years this ticket doesn't need any more analysis. Thanks for your time.

somtimes mobs still glitch through (wood)fences in multiplayer when i run a own server on my desktop PC
i guess that the bug orrcures if nobody is on the server or then the first player join / leave the minecraft server

if u need a savegame + server konfiguration pls tell me

actually we are using minecraft_server.1.8.2-pre1.jar for the server and the client(s)

1.8.4 Cows/Sheep getting out through SOLID blocks. Suffocating and dying every time I log back in. And they just get pushed out like this by other mobs. I've seen then literally walking out too.

I can't believe this bug has existed for so long! Wow guys what are you doing??

I am currently playing Minecraft 1.8.3 on a server.

There seems to be some kind of inadvertent race condition occurring between the chunk blocks loading and the mobs loading and being subject to the world's effects (such as gravity, and/or not being able to go through blocks normally). I have lost all manner of livestock as well as villagers due to getting stuck in blocks or sinking into the ground and suffocating.

One time it even happened to myself while logging in, that I sank down into the ground before the world was loaded, and then was stuck in the ground suffocating. I logged out and logged back in, and then I wasn't stuck in the ground anymore.

Please fix this bug, it is wreaking havoc on my enjoyment (lost 3 or 4 villagers).

Still experiencing the problem in 1.8. Seems to happen when a chunk reloads, causing animals to get loose by glitching through walls.

Confirmed in 15w34d.

This bug is also present in 0.12.0 Windows 10 edition.

Rather than getting a notice that this issue is present in every weekly snapshot over the last three years, it might be better if we could just get a notification when the issue is actively being processed by developers. Then we'll get a single "we/Mojang think it might be fixed in snapshot X" rather than a field report equivalent to "we were hoping it was accidentally fixed by some other changes in this snapshot but it didn't work out that way".

So perhaps Mojang can temporarily lock this issue, and just re-open it when They believe something may have changed? Thanks.

I think this problem worsened in 1.8. and had become more noticeable (particularly noticeable with drop style mob grinders) due to it.
It is an annoying problem, especially on servers. I hope it is resolved in a future update. a patch for 1.8.8 would sure be nice too...

i don't see this error anymore since i started playing a heavily modded version of 1.7.10, wouldn't a easy fix for this would be making animals stay away from fences unless lead by the play or the thaumcraft way with how they codded the block of warding works better than fences when making animal farms nothing enters and nothing leaves ever

Confirmed for 15w43a

mobs (cows, rabbits and chickens) glitch into the edges and die because of that. 12w42a multiplayer. see 15w42a.png

i havent had that behaviour in 1.8

Gerhard Pillow:

Water flows and similar things make it much worse, but I certainly have experienced it in 1.8. With all mobs, having many of the mob in the pen makes it much worse, but I noticed it with Villagers glitching out of a Iron Farm design, too. They were not glitching through the floors, but through a head hight wall designed to separate adult from baby villagers. This suggests weird processing of the hitboxes on chunk load perhaps. It certainly only happens when the chunk is unloaded and then loaded again. For critical farms I have had to implement keep-alive mechanisms tied to a world-clock in the spawn chunks, or resort to locating the farm in the spawn chunks, but spawn is very crowded these days, with things like Iron Foundaries making door placement... problematic.

Jordan Davis:

The problem seems to revolve around chunk loads. Maybe the best way is to move mobs away from fences and other blocks on load, but I am not sure how that would work. I didn't see this bug for all the time I was on 1.7, but since 1.8.1 dropped (when I first started playing 1.8 on my primary server) I have noticed it. It has prevented me constructing many farms under 1.8 as I don't want to build the farm and have to restock it every few days, especially if the farm involves farmer villagers: it's such a pain to breed 50 villagers to get the 3 farmers that you need (OK, not 50, but it feels that way). The only solution I have found so far is to locate the farms in your spawn chunks, but spawn chunks are already pretty busy, these days, or use a keep-alive mechanism tied to a world-clock at spawn. That's a terrible solution because it means chunks I would happily let unload are loaded all the time, increasing server load and producing lag.

And, at this stage, it's not fixed on the 1.9 track. It's very frustrating. Jeb is actually assigned to the bug, so I would suggest it will get resolved in short order. That seems to be how bugs go: they may sit idle for some time, but if it's actually assigned you can be sure someone's actually looking at it. If a bug isn't assigned you can't assume someone at Mojang isn't watching it, but you can't assume someone is, either. Do a search on assigned bugs: you'll find that it's an amazingly low number when compared to the total number of open bugs.

Captain Starbuck:

It's a good suggestion, but's it's unlikely that Mojang will change their system: I've seen many good suggestions made in the past, and I don't recall ever seeing or hearing about one being implemented. We'll have to wait and see. I certainly am sick of the 8 or 9 e-mails I get every day about issues I am watching on JIRA, seeing as 90% of the time the e-mail was generated by someone posting a comment along the lines of "This bug is 2 years old, why hasn't it been fixed?" to which I can only reply "I don't know, we get no feedback or indication when bugs will be resolved". Another 5% is a Mod saying "This is old and the OP hasn't updated it recently, can I close it?" And about 0.05% of the time it's actually a post about the issue being fixed... So, yeah, lots of frustrating noise drowns out actual feedback from Mojang.

I get the distinct impression that Mojang don't particularly want people to know that they are looking at a bug until they are actually going to fix it soon, an impression I have been given by Moderator commentary. I, personally, wish that it was more like a traditional helpdesk where jobs are assigned and evaluated quickly. The assignee then communicates with the user community an estimated time to resolve the problem (setting the end users' expectations). This allows the users to evaluate if they will wait for a fix or find a work-around themselves. I certainly would have skipped 1.8 altogether if Mojang had honestly communicated their intentions: much of what I have been trying to do in Minecraft for the last year has revolved around mechanics that are currently hopelessly bugged, and many of those issues have had zero feedback from Mojang for over a year. Some of them were recently assigned for resolution in the lead up to 1.9.

I would have been better off not starting a new world for 1.8, and sticking to the much stabler and better supported 1.7, and then start a new world in 1.9. From my perspective, 1.8 broke more features I use than it introduced. Administering a 1.8 server has become an increasingly frustrating experience as not only am I frustrated by the numerous bugs, but I also have to investigate user complaints, and then prove to the user that it's a bug and not a problem with the server. I then inevitably am left with the responsibility to both report the bug and track it, or find an existing issue and track that, all adding to my workload in administering that server.

With Mojang, you just have no idea whether or not a bug will be fixed until right before it is fixed. Thus, bugs can sit for years with user after user posting comments like 'this was reported 2 years ago, is there an estimate to when it will be fixed?' to which the official answer is almost always silence. All it would take is one comment from a Mojang staffer or Moderator: "This is linked to core game design. We need to change the way many things are done to fix it, and each of those things has other things contingent on it. We'll address the first set of issues in the lead up to the next version, and the second phase in the version after that. So, about two to three years". Then people would have something they could work with. Maybe it would be useful for Mojang to mark some bugs as "On Hold" while they establish what is involved in a fix or while they wait to resolve other bugs or implement other features that are holding up the fix. What Mojang does now is inherently deceptive: you just don't know when your bug will win the support lottery; it may be tomorrow, it may be two years from now, it may be never. You just never know.

Is this issue fixed in 15w44b? Only asking because MC-119 was fixed.

Sonic: That was only marked fixed because nobody's reproduced it in a while.

I bet it is because of a mob does not save info on which side of fence it is at the moment when data is saved. Then when a chunk is reloaded the mob is put on random side of the fence.

For the recent comments making guesses why this issue exists: open old comments and scroll to around 14/Jun/13 to 03/Aug/13. The issues were mostly figured out (and even fixed for relevant versions at the time as mods) by a number of users. There is pretty much no reason to consider any other reason until Mojang indicates there was a significant effort to try and fix this issue properly (hasn't happened so far in the two years+ after those times), or having done other changes that could have affected the reason (e.g. a rewrite of related backing features/code, which would possibly invalidate the old results).

In short: the reasons and the fixes were not simple. There could be simpler workarounds (in the code level), but proper fixes are always better (in almost every way) than workarounds.

Christopher Martin:
"Jeb is actually assigned to the bug, so I would suggest it will get resolved in short order. That seems to be how bugs go: they may sit idle for some time, but if it's actually assigned you can be sure someone's actually looking at it."
This has been assigned to Jeb ever since he tried to do a fix first time (01/Jun/13)... So no, in this case it doesn't mean anything. (And with that I do not mean he is not looking at it, either; we just can not know it from the assigned-thing any more.)

Grum pointed out that this bug may have been fixed when we corrected some blocks' bounding box calculations. Please update the report to include the latest snapshot if you are sure it still happens in the latest snapshot.

This issue has been fixed in 15w45a
At least to me. 🙂

• Screenshot

I just did some new testing that contradicts my previous claim via Twitter – I can NOT reproduce this bug in the latest snapshot. I would suggest this bug to be considered fix.

–

A visual glitch where a considerable amount of entities went missing after a teleport did occur at one point though. After relogging, all entities returned. This can be seen in this horrificly boring video, at 01:30 – https://www.youtube.com/watch?v=1QZzKhCSrpU – available momentarily.
(And yes, the video is very jumpy, didn't bother shutting down all applications, rendering the computer way too slow to keep up.)

I confirm this as fixed as well.

Tested in 15w45a with a 3x3 area enclosed by fences and a bunch of randomly spawned animals inside. Bug still occurs, simply logged out and in again and some animals got on the other side of the fence. Definitely no graphical glitch, i was able to lure the escaped animals further away with the appropriate food.

Just out of curiosity Björn, was the world created in 15w45a or a prior world? Shouldn't make any difference, just interesting to know.

But mobs can still glitch throug fence by growing up. To reproduce fill fenced area with sheeps, than type:

/entitydata @e {Age:-100}

Reproducable 50% of times after typing this command with about 150 sheeps in small fenced area.
Mostly they glitch through the south/east corner.

Just out of curiosity Björn, was the world created in 15w45a or a prior world? Shouldn't make any difference, just interesting to know.

Created in 15w45a just for the test.

Can also confirm this is fixed.

@@unknown Cannot reproduce with given method. Made cows babies, teleported away, made cows adults, teleported back, everything was fine. See MC-92524

@unknown: Separate issue. Create a new ticket for it if you want.

Marking as fixed somewhere between 15w45a and 15w38b, likely fixed with MC-73302.

@redstonehelper, created MC-92524 with record. Also found same report marked as duplication of this: MC-68433

3 years to solve that... nice....

This isn't fixed. It is still happening in 15w47c, though admittedly it seems to happen less. Still, I often find my cows or chickens have wandered right through the fence when I come home.

I can confirm that this still occurs in 47c

Can anybody confirm with mobs that were grown up before the area was unloaded?

I have it occur with Adult mobs where the fenced area is quite full of Adult animals and every so often i come back an notice escapee's which i then kill so as to make sure i keep track of when others have escaped

sigh... reopened.

It seems to be acting differently from how it used to be. I have been seeing only baby chickens and adult cows escaping, everything else seems to stay in. I wonder if it is different depending on where the farm is located.

Yeah, It happened to my survival world when I was farming Rabbit and escaped from fence and I killed escaped rabbits and once I knew this issue was repeating. On history, minecraft 1.6.2 There was "Fixed animals escaping their pens", I made the fence more thicker to prevent this :<. Thanks for reporting for me. : ]

It's still happening in 1.8.8 and it's not only with baby animals either. I've seen an adult sheep walk straight through a solid fence. Yes, I saw the bug as it happened, so I know it's real and it's not just an issue with animals growing up.

I think that sometimes, animals suffocate when they try to pass through some blocks. I've found dropped passive mob remains next to large jungle trees while in peaceful mode.

I can confirm this for 1.8.9 with pigs and horses, for me it happend when loading a saved game. It also happens in vanilla 1.8.9 without extensions and resource packs, but using OptiFine with an increased render distance seems to increase the rate of the incident...

It happened in Peaceful on a farm full of pigs glitching throug walls and eventually leaving a piece of meat after dying. I also lost 2 (of 4) horses this way, unfortunately i wasn't near when it happen so i couln't collect the saddle and armor...

Bug present with full blocks in SP 1.8. Occasionally I see some raw beef/mutton and leather/wool on the ground where an animal seems to have died from nothing, a couple of villagers I cured get stuck and suffocate in walls upon loading, and a sheep escaped from a 5x5 pen being only one of four individuals. Sheep and cows escape their two full block high enclosures (not sure if the corners being cut out have something to do with it), however my egg farm with 200+ chickens crammed into one space above a hopper seems to be fine.
EDIT: one of the villagers just died. Now I'm going to have to find another villager zombie to make my city :\ EDIT 2 (update 1/25) For some reason, this bug doesn't seem to happen if one of three things are met:
1. if the floor 'inside' the enclosure is at least two blocks higher than 'outside' the enclosure (I assume this is because mobs are coded to try and not jump down from heights)
2. if the 'enclosure' is a 1x1 space surrounded on all adjacent and diagonal sides (because they won't try to move around, even though they will push eachother into corners)
3. If the walls are two blocks thick and are made of a transparent block like glass, they will still glitch into the walls but they will get back out on the right side without taking suffocation damage

This bug has been happening to me a lot on 1.8.9. I can't really say it's gamebreaking, but it makes it extremely frustrating when I have to worry about horses glitching into solid walls AND fences (so basically any traditional horse enclosure you would build) and dying and their armor and saddle disappearing. Same with my cow farms depopulating overnight because they either escaped or glitched into walls. What a broken mess. The Xbox 360 version of this game didn't have this problem 3 years ago. This is happening to me on both single player and on a server; I've tried vanilla Minecraft 1.8.9 and Spigot 1.8.8 with both having the issue.

Bug still present in 1.9 pre-4. I've had a lot of villagers die or escape from this bug. It needs fixing.

1.9.1-pre3: Didn't experience any glitchiness with 1024 chickens in a 5x5 fenced area.

Several people sais this issue is fixed, several said it's not.
Maybe there are two different issues here ?

Under what circumstances do mobs still go out of fenced areas ?
Is there a scheme ?

this seems to be fixed with chickens but still happens with cows, sheep and pigs.
I used the attached map "Mob Escape Testing" but added chickens, sheep and pigs.
EDIT: 1.9.1pre3

Hi killerpommes,
You are dropping spawn eggs?
What happens if you make the walls 4 block high?
What happens if you make the walls 4 block high and you drop mobs instead of eggs?
In your screenshot, do I see a pig in the sheep area? It is interesting because no pig escaped into the "freedom".
Thanks.

Hi Ioan Vira
I am dropping spawn eggs.

"What happens if you make the walls 4 block high?"
It happens the same as before.

What happens if you make the walls 4 block high and you drop mobs instead of eggs?
i don't know. What should be different?

"In your screenshot, do I see a pig in the sheep area?"
Its a pink sheep.

Confirmed for 1.9 villagers; I had villagers disappearing in a safe fake village too small for zombie sieges, and assumed they were entering walls and suffocating, so I replaced my solid block walls with half-slabs hoping to fix it. Well, looks like I was right, because now I have a villager stuck inside the half-slab wall in the corner.

This is probably how it's happening:

1. The villager (or other mob) pushes its hitbox into the wall (this is observable in "empty corners" or corners with empty diagonals; a mob can push or attack you if you stand in the corner)

2. When the chunk is unloaded or loaded (can't see results in between an unload and a load without looking at raw save data), the villager is considered "inside" the block, and as we all know, you can move around and/or stay inside a block once you're inside it...

As for the specifics, that's for the devs to look through the code for, since it could be any number of things, like...

...the chunk saving between an entity's movement and it's movement correction if the game uses that type of system, which would effectively remove the part where "the wall pushes back" (most likely of my guesses)

...a rounding error during save/load, particularly if different variable types are used

...any number of other floating point physics engine glitches.

In either case, some workarounds that should help would be...

...after finding whether the glitch occurs during unload or load, add a bit of code that pushes entities into the CENTER of an adjacent air block (only during the chunk load/unload, where the glitch is occurring). There would have to be air blocks (and other non-physical blocks) directly adjacent that fit the hitbox as well as a steppable block below them.

...simply add some (very reasonable!) behavior to the AI...like...
if (suffocating in wall) then {try to move out of wall}
...which would make a lot of sense even if we didn't have this glitch, AND would help with the glitch (though they would still take some damage, and could still die with repeated glitching...and if they're stuck in a corner like mine, they still wouldn't be able to escape anyway)

In 1.9 this happens with not just fence blocks but also solid walls. Making a drop grinder for zombies or other hostile mobs is a harrowing experience on login now. Literal zombie explosion!

Can confirm 16w15b. Chickens run away from my farm through glass walls

Cannot reproduce in 1.10. I created a superflat world, built a small 4x4 fenced area, spawned at least 100 chickens, and then flew back and forth to unload and reload the chunks, and also closed and reopened the world multiple times, but I couldn't get any of the chickens to escape. Perhaps this bug is finally fixed?

Cannot reproduce either.

This is still happening in 1.10. Have an iron farm with 20 villagers stored in 2 5x1x2 glass containers. AFK for several hours, no villagers come out. Walk away from farm, come back, my 20 villagers is now down to 10. I am certain they are escaping, because I see them outside the farm. They tend to cluster around one side of the enclosure. This is really difficult to deal with, because getting villagers into the enclosures is not easy.

Could you provide a world download? I'm curious as to what conditions cause this bug. And also, do you tend to experience lag on your world? it might only happen when there's lag. Also, are you using any mods whatsoever like Optifine? Performance mods like that are known for making alterations to the math and loading calculations in the game, so it could be a mod problem, not a vanilla one.

Its still happening with cows, sheep and pigs. Chicken seems be fine and villager not that bad

I had huge issues with my farms on 1.8 due to this bug; animals escaping, villagers getting stuck on walls... I started playing MC again yesterday with vanilla 1.10, and I see that it seems this bug has somehow become worse than it was before. I have a cow farm set up that involves pushing baby cows into a grinder, and the same old issue of animals sometimes clipping out of the walls, PLUS, they suffocate on walls while being pushed by water and I see ~2/3 of them dying before they can even get into the grinder. Really annoying :/. Rest in Pepperonis Minecraft, time to put this game away for a while again.

Still happening in 1.10.2
i attach a world download for testing different animals

Hey,

I recently found and fixed this bug. This is caused by the numeric precision of float/double and is a round-off error caused by the re-initialisation of an entities bounding box when loading the entity from its NBT-Data.

An example-fix would be to save the current bounding box of an entity to the NBT Tag. But there are other ways to fix this too.
Video of the Problem in SP and the working solution on my server: https://youtu.be/jSJGQAGSmPo

Entity.java

public NBTTagCompound e(NBTTagCompound nbttagcompound) {
        try {
            nbttagcompound.set("Pos", this.a(new double[] { this.locX, this.locY, this.locZ}));
            
            // kade this fixes the fences bug
            nbttagcompound.set("AABB", this.a(new double[] { this.boundingBox.a, this.boundingBox.b,this.boundingBox.c,this.boundingBox.d,this.boundingBox.e,this.boundingBox.f}) );
 [...]
}


[...]



    public void f(NBTTagCompound nbttagcompound) {
        try {
[...]   
            this.setPosition(this.locX, this.locY, this.locZ); // kade this causes the problem
[...]   
            if(nbttagcompound.hasKey("AABB")){            
	            NBTTagList aabb = nbttagcompound.getList("AABB", 6); //kade edit this fixes the fences bug
	            boundingBox = new AxisAlignedBB(aabb.e(0),aabb.e(1),aabb.e(2),aabb.e(3),aabb.e(4),aabb.e(5));
            }
[...]   
      }

Still an issue for the latest test map attached even with the above code.

@md_5 cannot reproduce with that map within ~5minutes of teleporting.
Im guessing you did not have the exact order?
setPositon(...) in the loading method MUST be called before loading the AABB data - not the other way around.

Kademilla, you providing one fix (to an issue which historically has been a mess of multiple reasons and fixes, check in there in the older comments) does not mean it gets fixed instantly (or even slowly) into the game... and mods only test the latest vanilla/official version (if at all). Apparently (or by now obvioiusly?) it still has the bug.

Providing fixes for bugs is certainly nice, but after that, it needs patience, looooooooooooooooooooooots of it. Like years...

Definitely fails with the above patch (otherwise unmodified installation).
I also don't give much credence to the roundoff in this particular situation being an issue, as they are double precision floats, and the discrepency is very small to even be a compounding rounding issue, eg:

Before box[9.092755006626248, 56.0, -8.114562491839603 -> 9.99275498278439, 57.39999997615814, -7.214562515681461]
After  box[9.092755006626248, 56.0, -8.114562491839616 -> 9.99275498278439, 57.39999997615814, -7.214562515681449]

Before box[8.026707492862702, 56.0, -7.903891919762822 -> 8.926707469020844, 57.39999997615814, -7.00389194360468]
After  box[8.026707492862702, 56.0, -7.903891919762818 -> 8.926707469020842, 57.39999997615814, -7.003891943604685]

You're talking a ULP of 10E-12 minimum.

Hey,
I would still argue there is a .setPosition() in your methodflow. Try adding it right before the end of the catch block.

roundoff: Yes that is the definition of a numeric precision problem. The amount of difference is not the point. Example:
0.00000000000001 to -0.0000000000001 would completely change your program logic.

The same goes in this case.
An Entity standing somewhere at 0.5XXXX
and a BoundingBox up to 0.62499999999999998
Will be rounded to 0.625 or higher. Thus changing the actual block-location of the bounding-box test code.

In this case 0.62499999999999998 would be the maximum to not get treated as "standing on Block 1" (possibly blocktype dependent)
By rounding this up to 0.625 on re-initialisation of the BoundingBox the Entity will now be treated as "standing on Block 1" before it was only "standing on Block 0"

Updated Video with the mentioned Test-Map and latest Build: https://www.youtube.com/watch?v=-m2zcTQJ7gk

If it still happens to you if the loading-code is at the end of the method I would bet on a CPU type dependency (fastmath, SSE...) but that would really surprise me.

@unknown, I am not sure if teleporting away really proves that this fix works. As far as I know it takes some time for a chunk (and its entities) to unload.

@Marcono1234
Teleporting is enough to produce the problem in vanilla. You can use the Test-Map in this Report to reproduce the problem with vanilla within one or two teleports.
The difference is instantly visible (Fixed spigot first, spigot normal at 30sec): https://youtu.be/zj1Y43Buyik

The question if it 'proves it works' is harder of course. But as this only happens on chunk-reloading an not in normal gameplay this problem must be generated by this entity loading mechanism. I compared all Entity fields at runtime that either changed trough saving/loading to/from NBT or are never saved.

I think if this is caused by tiny errors in coordinates, it may be very hard to fix. An easy fix (which Mojang obviously prefers, see MC-97523, now MC-98153) would be to make it so that mobs are pushed out of blocks like players. I don't see why they shouldn't anyway.

I agree with Kademlia. Numeric precision is an important issue which is taken into account by experienced developers. Now that Kademlia warned about this problem it is a matter of software analysis which can be done by any developer and maybe tested with junit.

I was about to write this comment before, but canceled.. maybe i should have after all...

Seek through older comments, especially around this one: Daniel King added a comment - 17/Jun/13 1:58 AM (and it continues for a plenty many comments and longer period, this wasn't an easy thing to fix/improve.)

Most of all this has already been gone through; pushing mobs out, bounding box not saved, floating point inaccuracy, you name it... and something with multiple fixes was provided to test. Some of the sub-issues may have been solved since in the official game, but I think it might still be useful to go through the old things first and not invent the wheel again.

(For example, pushing mobs out of blocks was not in itself a full solution, but one part of the solution.)

I see a mod that solves this there: http://bugs.mojang.com/browse/MC-2025?focusedCommentId=74619
It takes a bit more space on the hard drive, but not much, only 6 float variables (24 bit if I researched this correctly) and takes a bit more time to save (shouldn't be recognizable), but it fixes this. Or did that change from 1.5 to 1.10?

Mobs are pushed out of blocks, though. Just not transparent ones like fences.

I actually see my sheep get pushed out of there fences by other mobs and I'll notice after a while a stray pig or cow mixed in with my other mobs. I just thought it was spawning there but now that I saw my sheep actually get pushed through the fence now i am not so sure. I am in 1.10.2. I actually started to think that this and MC-89030 are related. Since the problem might be the Mobs instead of the blocks. Any thoughts? I have to make double fences which seems to help. This might be the result of "fixing" the suffocation issue where mobs get stuck inside blocks. The mobs going through the block is to prevent them from getting stuck Inside it, Hopefully there will be a way to prevent the Mob from going that close to a block in the first place. Maybe if that is possible that could solve this issue?

This is not related to MC-89030, that one also warps players and this one also happens without pistons.

@fabian i didnt say that it had anything to do with pistons. I said that both issues might have something to do with mobs. Players perhaps included. 🙂

Animals escaping fences does not appear to be an issue for chunk reloading. It appears to be a gap/clipping error. I watched this horse slide out of the fence as though he were stuck in a cobweb. Oddly enough, while I have had all kinds of animals loose inside my base when I return, not a single pig has been found outside of its fence.

Confirmed in 16w39a & 16w39b

Confirmed in 16w39c

Confirmed in 16w40a

Confirmed in 16w42a

Confirmed in 16w43a

Confirmed in 16w44a

Confirmed in 1.11

Confirmed in 16w50a

Confirmed in 1.11.2

the same problem in 1.11.2

1.11.2 is already marked as affected.

I can guarantee that the beug still persists in 1.11.2

That's great for you, but next time please look at the affected version list before. It's already in there.

Ok thank you 🙂

I reported this bug on the console version same behaviour applies to PC 1.11.2. As I was able to easily follow a procedure to recreate mobs going trough fence or wall on pc as well. In the description i can find nothing over replication or cause that's why i'm posting this. (don't know the exact state of this bug i normally mostly report for Console).
Maybe there are details in the video https://www.youtube.com/watch?v=qUs1er67Zlg on that issue as in there it relates/ correlates to how you place something over chunk edges and loading. MCCE-3945 exactly the same behaviour as in the video applies to the pc version 1.11.2. Just tested it . Easy to reproduce in single player. Maybe there are details in the attached video that solve this. As in the linked issue there is nothing addressed to reproduce and I just did it easily. It applies to fenced / closed in villagers mobs everything. It has to do with the loading algorithm of chunks and timing if mobs are placed I guess(i'm not good at code). Just watch the video or see report for more info. In that bug report there is also a image showing how a large enclosure reproduces this behaviour (this issue has been going on quite long on pc I see)

I am not sure if the chunk border -effect was noticed before, but that could indeed explain one part of this particular issue. There has been multiple reasons in effect, the chunk loading could be yet another thing to consider.

For example, if during world/chunk loading mobs are loaded in one chunk, but the next chunk isn't in memory (yet) and thus its blocks are not preventing movement (in the way expected), and the already loaded mobs start to move... Even correct bounding boxes etc. other fixes will not necessarily help in such a case.

It may be impossible to fix the chunk-edge part of this issue "perfectly", but perhaps the mob simulation should assume that any unloaded part of world is a solid block, when it comes to movement collisions. That would prevent mobs moving too far until (if ever) the next chunk gets loaded. (Though, there is a chance this approach causes other issues, e.g. if there are mobs that are saved almost half-way out of the chunk because in reality there isn't a solid block in next chunk, and during next loading, the over-careful "assume there is solid block" method then pushes these mobs away from the chunk border, it could cause more pushing onto other mobs etc. However, these issues should be less severe and the mobs could be considered to do some such pushing even by themselves (though they won't do half-a-block pushes normally), so the results should be handled better than these outright slip through block -things.)

(Similar situation used to cause the "leaking" of water from village farms etc., though in that case the problem was at mid-chunk instead of chunk borders due to way village structures (and other decorations) are created.)

That is kinda what i thought as well. Only beautifully detailed explained.
I just didn't find the do this then this happens, how to have some consistent behavior on replication (the video is not something that happens ow hard to recreate, but often 3 out of 4 on pc as well). So you have something to test against.
The big enclosure picture and video perfectly fits your explanation on the chunk loading and behaviour on my issue. This issue also possibly affects MCPE as reported by a user, so it is across all platforms currently.
(Forgotten to mention: in my video the wool marks the chunk edges so the edge of a chunk is exactly in between the rows of wool)

@Killerbeenl ( @Marcono1234 )
Regarding the PC-Version (I have never used the MCCE):
While this is certainly a possibility you are re-loading the world and thus the mentioned precision-problem (first mentioned here AFAIK; not by me: http://bugs.mojang.com/browse/MC-2025?focusedCommentId=74619) is sufficient to cause the problem. So I´d argue this does not indicate another problem on its own.
As far as I know vanilla MC always looks up the blocktype when moving entities and sync-loading needed chunks. But its hard to tell as servers generally pause entities on bordering chunks to keep the server from constantly loading/unloading "border+1"-chunks.

Apart from the mentioned precision-problem I fixed another related bug on my servers. This was mentioned in the comments here as well some years ago: The BoundingBox of an Entity that is changing its state from Baby to "GrownUp" increases and can result in entities moving out of fenced areas if the entity was standing directly at the fence while growing up. This can be fixed by relocating the entity in the event of growing up (my ugly code to fix this: https://hastebin.com/socaxakiko.cpp).

Since adding those two additions no player (on the servers) was able to reproduce the problem but as stated above on servers entities near the border of the loaded world wont move.

The bug is still present on 1.12-pre6. (Tested on the Java edition.)

Just came across this; I've been noticing the same "chicken-gets-stuck-on-fence-corner" thing on my new, current, Pocket Realm world, as well.

Bug persists in 1.12

Bug still confirmed in 1.12. Llamas and cows occasionally escape through fence when chunks load after being unloaded.

I've had villagers especially just walk into a block and die even after the chunk had been loaded for a while
Confirmed to happen once as I witnessed it die and saw the death smoke from inside a cobblestone block.
I've lost about 10 other villagers that I suspect walked into a block and died. Zombie death would have been unlikely as there would be missing doors, uprooted land (whole village area is tilled), and I would have heard both the zombies and the turned zombie villagers (game set to hard difficulty).
In each case I was within 30 blocks of them and the game had been running for at least an hour, unlikely to be a chunk loading error

I was on a multiplayer server, so it could have been lag, but I thought I'd post it here just in case there was another cause to this bug than just chunk loading.
Edit: It was not player griefing, I was alone on the server and no one logged in while I was away. Just for clarification)

The bug is still present on 1.12 Release (Java Edition), I have cows and sheeps in my spawn chunks, and when entry the world some cows/sheeps are out of the fences or die and leave their loot items.

Bug is still around on the Xbox One edition, has been for years. Sometimes they disappear, sometimes they just get pushed out of their pens. Often when I come down from my tower, several different animals will have escaped from their different pens all at once. How hasn't this been fixed by now?

Doesn't matter, because this is not the Console Edition bugtracker. You find that one at http://bugs.mojang.com/projects/MCCE.

I'm trying to investigate another chunk loading bug, and this one is interfering. I started with over 100 villagers in a 2x14 area along a chunk border. The walls are planks two blocks thick and two blocks high. Every time I would move away, unloading one chunk or both, and then move back, I would find villagers glitching out of the wall or getting stuck in the wall and suffocating. At this point I'm down to 37, and it'll keep going as I unload and reload the chunks. I'm using solid block walls, so I'll try glass or fences or something, but it's definitely weird that a villager cleanly inside a chunk would be fine on unloading and then upon reloading a villager glitch into blocks.

Looks like this affects other mobs too. People tell me it has to do with hitboxes. If the hitbox was not intersecting the wall before unloading, why would it intersect after reloading in the same spot? And why isn't the villager just pushed back out of the wall? The hitbox overlap has got to be insignificant.

I turned entity cramming off for this testing, and I can clearly see them blinking red while intersecting the wall. This happens if I move and have the chunks unload one at a time or if I teleport and they both unload at once.

Maybe villagers are shoving each other around, and they push each other into walls on reload. But we'd only get them being shoved into walls if the entities were reloaded before the blocks were, but if that were the case, they'd fall through the ground, right?

Update: I just teleported view_distance away and then right back to where the villagers are. I'd had 18, and there were 18. And then at least 10 seconds later (after everything was clearly loaded), some villager moved, shoving another villager into the wall to its death. How can a villager shove another into a wall ever?

Anyhow, I can just keep doing this over and over. Watch the villagers as long as I want, and they are fine. Get the chunks to unload and reload, and they might be fine for several seconds before some AI movement shoves a few into the walls, killing them. So far, I've been losing like two or three at a time.

Another update: I got down to 13 villagers in this 2x14 space. I did another unload and reload of chunks and everything looked fine, but then yet another death happened right before my eyes. So I'm looking at an arrangement like this:

SSSSSSSS...
SSSSSSSS...
SSVVVV  ...
SSvVV ...
SSSSSSSS...
SSSSSSSS...

In this spot where there there are three villagers in a line (V), another one walked into the last one, bumping him into the next one and that into the next one, ultimately shoving the one in lower case (v) into the wall, killing him. What is bizarre is that this sort of thing only happens just after a reload. What is altered about v's position on reload that even allows it to be pushed into walls?

Yet another update: I just saw one standing by himself, just fine for a few seconds all of a sudden start dying. I'm down to 11.

More info: Sometimes, when I reload the chunks, some of the villagers don't get reloaded by the client. However, they will start moving around after a while and will start appearing. So basically, after a villager is reloaded, it doesn't necessarily move around right away.

If a villager has been moving around by its own AI to any extent, it can bump up against a wall and not get shoved into it.

But if a villager has not caused itself to move since it was reloaded, then it can be easily shoved into solid blocks by other mobs. So why does the wall count as an obstacle when the villager moves itself or at any point after it's moved itself, but doesn't count as an obstacle at any point before it has moved itself?

2 things:

1. Are you testing in 1.12.1? (if not contact me in IRC (esper or freenode) and I can tell you how to set up MCP for 1.12.1; it's fairly easy)

2. Can you record a video of this happening?

So to summarize what's happening here:

Upon reloading a chunk with mobs (besides villagers, I also tried llamas and wolves and got the same behavior), if a mob has decided to move by its own volition, then subsequently to that, solid blocks are considered when hitbox collisions might shove it around. However, if the mob has not yet decided to move itself, then solid blocks are not taken into account, so if another mob's hitbox collides with it it, it can get shoved right into a wall.

Plan to identify cause:

With relatively large mobs (like horses or bears), this behavior is reproducible with only a handful. I'll shrink the area they are confined in to reduce the required number even further. Then I can print out how movement decisions are made for each entity to see why solid blocks are not considered initially.

Likely solution:

Perhaps a proper solution would find a way to consider the solid blocks right away. That's probably best.

But I noticed that if a villager so much as rotates in place, they can't be shoved into a wall. A really cheap work-around for this problem would be to have every mob execute a zero-degree rotation in place upon being reloaded. In fact, implementing that might help reveal the cause of the underlying problem anyhow.

Hi, Pokechu22,

I'm actually using MCP for 1.11.2, so I will need your help making it work for 1.12.1. However, testing with 1.12.1 vanilla was straightforward, and what I'm seeing was definitely not fixed. I'll upload videos for both versions.

Update: I just uploaded two files, kill-wolves-1.11.2.mp4 and kill-wolves-1.12.1.mp4 that demonstrate the bug happening.

BTW, I had a devil of a time getting these videos squished down to your 10000000 byte limit and still be watchable. For one thing, the size is too small for videos. Secondly, it's also ambiguous, because it's not 10485760 bytes like I had originally assumed.

@Timothy Miller, just an idea to look at, on the basis of some of the old reasons:

Check the exact positions of the villagers just before unloading and just after loading. (Basically need to write them after every move and unload/load). What you would be looking for is a tiny change in the value before and after, probably due to using float in save and double during runtime, or some such.

The result of such tiny change would be that while before unload/save, a villager would have stopped "skin" against wall (by the collision checks done after move), but after load, a tiny change would result in the position tiny bit inside the wall, thus past the collision check. Once they move themselves, movement routines would check if they are within block and push them out properly. This would require that when pushed (by others) (and when loaded) an entity position is not checked and pushed out of block, but only for collision (to not get in a block in the first place).

Or something like that.

Another possibility is, if the problematic walls/blocks are at the chunk edge, that while one chunk is loaded, the wall in the next chunk is not. If the collision checks assume the unloaded area to be "air", movement and/or pushing might allow moving half a block further (entity center just near the edge of last, thus well past the collision check point). Once the next chunk loads, if there is no "push all entities half inside blocks back out" checks, there would be some entities vulnerable to above fates. (And this could be combined with floating point errors, too).

(I'm not going to read through the history to check if either of those ideas has already been fixed in the past, and my memory is poor enough that I don't remember (I've read them all over time), it is almost faster to just check in MCP... and even if they were fixed, there could have been regression...)

(One more thing, please first collect your notes into own file, and update/add new comment like couple times a day... there is no point of causing 10 email notifications in couple hours. It is not like this is some time critical issue, especially considering that it takes years from Mojang to fix even a bug for which the fixed source code has already been provided.)

@@unknown: Sorry for vanishing on you. I've put the steps into MemoServ on esper so you'll get sent them when you return. Here's a gist of the same info.

That 1.12.1 video is really interesting and I can see exactly what you're talking about when you reload the 3rd time at around 0:45. Thanks! The 1.11.2 video's also useful (with chunk borders).

File upload sizes aren't something that I have control over, but that's important to note. Uploading to YouTube is also an option if the limit is causing problems.

@@unknown

Another possibility is, if the problematic walls/blocks are at the chunk edge, that while one chunk is loaded, the wall in the next chunk is not. If the collision checks assume the unloaded area to be "air", movement and/or pushing might allow moving half a block further (entity center just near the edge of last, thus well past the collision check point). Once the next chunk loads, if there is no "push all entities half inside blocks back out" checks, there would be some entities vulnerable to above fates. (And this could be combined with floating point errors, too).

That would make sense, but if you check the video, you can see that it happens on both sides of the pen, and in fact not on any chunk borders (see the 1.11.2 video). Floating point is maybe possible but I'd assume that too'd only round one way (but I'm not completely sure).

@Both:

(One more thing, please first collect your notes into own file, and update/add new comment like couple times a day... there is no point of causing 10 email notifications in couple hours. It is not like this is some time critical issue, especially considering that it takes years from Mojang to fix even a bug for which the fixed source code has already been provided.)

Agreed, try to minimize edits where possible - there's 165 people currently watching this issue, and any update emails all of them. (To those people: if this information's not useful to you anymore, stop following the issue - following is mainly only used to indicate you want emails about the bug, while votes indicate that you want it fixed). There's always /r/mojira if you want to do some discussion outside of the tracker (which may work well for this specific issue).

Sorry about the spam. I had no idea that the tracker software would generate a notification for every little edit. That seems like a bug in the tracker.

Anyhow, Markku is saying that a fix has already been provided. I looked and saw that Kademila had provided some code. I can look into testing that code to see if I'm observing the same issue or a different one. If it's the same issue, is this really worth me pursuing?

Also, chunk borders are NOT [edit] an issue. The pen is placed on a chunk border because I'm investigating an unrelated issue that this bug is messing up for me. But the way I'm teleporting, both chunks get loaded in the same game tick, and they're properly loaded well before any deaths occur.

When some people have asked why Mojang wasn't prioritizing bugs by severity, they were told (on /r/moijra maybe, but I can't remember) that vote count is what the devs to use judge that. But this bug has over 800 votes. It's currently assigned to Jeb, but I don't see any comments from him after that point about why the offered fix was inadequate. Given that we've more than met the criteria for this bug getting developer attention, could we ask for a comment from the developers on this, please?

Discussion about this continues on /r/Mojira.

woudn't just changing the entity width and height from float to double fix the issue? The casting from float to double in setPosition would be the culprit? This way entity AABB should be recreatable from NBT with position and double width.

Entity.java

public void setPosition(double x, double y, double z)
    {
        this.posX = x;
        this.posY = y;
        this.posZ = z;
        float f = this.width / 2.0F;
        float f1 = this.height;
        this.setEntityBoundingBox(new AxisAlignedBB(x - (double)f, y, z - (double)f, x + (double)f, y + (double)f1, z + (double)f));
    }

Xcom and I spent some time working together on experimentation, code analysis, and a fix for this bug, and we believe we have a viable solution for one of the causes. I have had to understand the intricacies of IEEE floating point for circuits I have designed to implement them, which helped a lot here.

To begin with, we need to avoid confusion with a client-side visual effect that sometimes makes it look like an entity has moved into a block when in fact its hitbox has not. In this case, it will appear that they can enter a block and get pushed back out again. In actuality, the hitbox never enters the blocks.

What we’re describing here is an unrelated server-side bug that causes an entity’s hitbox to actually overlap blocks. As a result, those blocks no longer limit the entity’s movement. Although there is a mechanism to prevent an entity from moving into a block, there is no mechanism to push them back out again.

The two bugs being discussed are as follows:

(a) One cause of this is straightforward: Some entities can suddenly expand the size of their hitbox, such as when a baby villager grows up. If the entity was up against a block when that happened, then it's hitbox will overlap the block, allowing it to pass through unimpeded.

(b) The other instance happens when an entity is saved to disk then loaded back into the world. Conversions between entity coordinates and entity hitboxes are vulnerable to rounding artifacts. The bug occurs due for the following reasons:
An entity can be moved by translating its hitbox. When that happens, coordinates have to be recomputed, which can result in a rounding artifact.
When an entity is saved to disk, the hitbox is not saved. It has to be recalculated upon reload, which can result in rounding artifacts.
Those rounding artifacts may result in a miniscule shift in position and/or size of the hitbox. This can cause the new hitbox to overlap blocks in the world, which the entity can then pass into.

To cite a real example, a villager was pushed against a block wall at X=17. This resulted in a hitbox translation that set maxX to 17.0. Next the entity’s posX was computed by averaging minX and maxX. Either or both of those operations can suffer rounding errors. When the entity was saved and then reloaded, the hitbox was computed from coordinates by adding and substracting width/2.0, setting maxX to 17.000000000000010658141036401502788066864013671875. With the entity now partially overlap blocks, there was nothing stopping it from being shoved all the way in.

This sort of thing happens easily in a crowded pen when entities with AI push each other around.

Xcom, gnembon, and I discussed these problems at length, along with a number of potential solutions, and we have arrived at one for (b) above. Problem (a) requires a completely different solution and is not associated with loading and unloading.

It is not sufficient to just include the hitbox in the NBT data, because sometimes standard hitbox sizes change due to bug fixes and other reasons. We have decided to recommend one of Xcom’s solutions, which is to impose a very tiny margin (on the order of 1e-12) between entity hitboxes and solid objects. When reloaded from disk, rounding artifacts computing the hitbox will err away from walls.

Note that this fix applies to only X and Z dimensions. Y coordinates do not suffer from this problem due to how they are calculated and stored.

We are currently preparing a Google Doc with more details on problems and solutions.

Explanation:
The best solution we could find without shifting entity hitboxes around if they happen to overlap incorrect static barriers after creating the hitboxes was to prevent any hitbox getting near any barrier.

In Entity.java and precisely in “moveEntity”(MCP name) where the entity vectors are re-calculated based on if they are about to hit a barrier. On line 966 the vector is reduced so as to give the exact distance needed for the entity to travel until it lands facing the barrier perfectly. All that simply is needed is to reduce the vector by a small amount, rather precisely 1.0E-12 to create a buffer space. This will prevent any rounding artifact errors described in theosib’s post by simply giving a margin to stay clear from the barrier.

The reason the 1.0E-12 number was chosen was because most rounding errors happen to land anywhere between 1.0E-13 and 1.0E-15. A larger flat 1.0E-12 barrier seemed sufficient while at the same time small enough to not be noticeable to any player.

The exact location where vectors are reduced based on the barriers they are headed towards are all calculated in AxisAlignedBB.java and more precisely in “calculateXOffset” and “calculateZOffset” (MCP name). This code pertains to how the parameter double value (vector the entity will travel in the next tick in either x or z direction) is reduced from its original value to the reduced value that will align the entity against the hitbox if it were to continue heading towards it. This number can simply be reduced further by another 1.0E-12 and prevent alignment and in turn create a buffer space for the described issue created by the save / load overlap problem.

Code:
https://i.imgur.com/VkKCKyA.png
This image shows where in the code the amount of 1.0E-12 is added. “margin” is the double value that is either added or subtracted based on what direction on said cartesian axes the entity is traveling. This needs to be done in AxisAlignedBB.java both in “calculateXOffset” and “calculateZOffset” (MCP name) and NOT in “calculateYOffset”.

It's worth noting that this only fixes entities not glitching into walls when reloading. This does not however fix entities growing up.

Have you tested how far out from origin that shift-by-error-margin -solution works (before resolution issues start to affect)? Should the error-marging be scaled up (upto some limit and then just give up) after coordinate resolution starts to get closer to it?

Markku has a point. The world border is at 30 million blocks out. To add 1e-12 to that and have any effect, you'd have to have at least 63 bits of actual precision, which is more than the 53 (54 effectively) bits we have with double.

Being a little conservative, we can use 2^-27, and it would work:
30000000 + 7.450580596923828125E-9 = 30000000.000000007450580596923828125

2^-28 works, but 2^-29 is lost due to limited precision.

So I would recommend:
final double margin = 1.0 / (1L<<27);

It is not sufficient to just include the hitbox in the NBT data, because sometimes standard hitbox sizes change due to bug fixes and other reasons.

While I agree with most of what you said I do not agree with this conclusion:
If a 'standard hitbox sizes change due to bug fixes' the change of said hitbox will most likely not be in the range of your proposed margin of

final double margin = 1.0 / (1L<<27);

but rather bigger than 1.0 / (1L<<6) making the solution for said problem still fail in the future, it would more ore less be the problem of growing.

("Other reasons" would have to be specified to be a valid point.)

For growing up and NBT saving see also: https://www.reddit.com/r/Mojira/comments/6tf9n7/insight_into_the_bug_fix_decisionmaking_process/dlkyqkn/

Hmm.. I'm not sure if I could follow Kademlia's comment...
I think Timothy meant with that "hitbox size change due to ...", that if/when such change is done (in the code), and if the hit box was also saved (and then loaded), there would be no recalculation (instead using the saved data), and the entity would continue to use the wrong hit box until something else forces recalculation.
(That is, if the hit box was saved as a (partial) fix for this issue, there would need to be some additional logic that would also recalculate the hitbox and then check if the saved one is reasonably close to it, in which case the saved one can be still used. If not similar, then use the recalculated one. But, IMHO, that would be an unnecessary complication which likely does not bring any improvement over the tiny shift -solution.)

I hope I'm not just messing things up even more 😛

As Markku pointed out. There are numerous reasons we chose to discard the NBT hitbox saving.
1. Issue of backwards compatibility.
2. Corrupted hitboxes would persist.
3. Any hitbox loaded would need to be corrected and as been in described in length because of the rounding artefacts would create an ambiguous state when a hitbox isn't at its correct size.
4. If hitboxes are corrected it could still result in the same overlapping walls problem that was started out with.
5. Extra storage for no reason when a simpler solution fixes the issue.

It was the best idea until we stumbled into the margin fix, after that it seamed natural to only add a margin with very little drawback instead of saving the hitbox.

Kademila,

I had planed to go into more detail on lots of possible solutions on like /r/mojira or something. We did think of this, of course. To address your concern, I'll cover a few options here, but in brief. Since I'm doing this from memory, I know I'm missing a number of solutions we had considered. Xcom can add some more if he wants.

Note that the growing up problem is separate. That is an explicit event that can be handled better exactly when it happens. I believe Xcom's solution to that is to compute a motion vector that would simply move the entity the right distance away from blocks that it is going to intersect.

• Saving and loading the hitbox:
  On load, this would restore the exact state prior to the save. This can be done in a backwards and forwards compatible way too. But if the standard hitbox size changes, then the hitbox won't change for pre-existing entities, which may at least temporarily miss out on bug fixes (there have been many instances of hitbox bugs, along with intentional changes to entity hitbox sizes).

• Move entities only based on coordinates, where hitboxes are always computed on demand:
  This would substantially complicate the code that handles motion that must account for hitboxes. It also doesn't address your concern.

• Quantize or otherwise carefully compute coordinates and hitbox values so that conversion each way is always lossless.
  This fixes the save and load problem, but it complicates coordinate and hitbox calculations in ways that are hard to understand. It also doesn't address your concern.

• When converting from hitbox to coordinates, provide hints to that conversion function that make it ensure that when coordinates are later converted back to hitbox that the new hitbox will respect the given boundaries.
  It's really not that complicated how I would handle this, but it also doesn't address your concern.

• When computing motion vectors, restricted by blocks, add a margin to avoid later rounding errors:
  This is Xcom's fix. It's really simple, requiring minimal code changes. However, it doesn't address your concern.

• On reload, check entities for overlap with blocks and push them out if necessary:
  This works well and would handle both rounding error and the case you mention of the hitbox growing due to a code change. At the same time, this would break things that people rely on, like encasing a mob inside glass blocks.

• Keep track of any block boundaries that affect the entity's position when it's saved. On reload, ensure those boundaries are still respected.
  This would require that we save both the prior hitbox and a bit vector indicating which hotbox faces must be enforced. On reload, if there are no such constraints, a new hitbox will be computed as usual, handling the case where the standard hitbox size changes. If there is a boundary, then the entity can be pushed away from the blocks to ensure that the boundary is respected, handling both size changes and rounding artifacts. If the entity is supposed to be overlapping a block (like encasing a mob in glass), then no such constraint will be recorded, allowing the size to change without undesirably pushing it out of the block. This solution would also slightly simplify the code for handling the growing up case.

That last case seems like the ideal solution, doesn't it? And if I were a Mojang employee, that is exactly what I would implement. However, this solution requires a lot of changes and is difficult to explain. We could post code, but Mojang employees are hamstrung by an idiotic Microsoft policy that forbids them to even looking at code we post here. It's short-sighed meddling-from-the-higher-ups that game-breaking bugs like MC-119971 may never get fixed, because Mojang employees don't want to get fired. As a result, you will probably always have problems losing and duping entities, blocks, and items at chunk boundaries. At least until I can get Mojang to offer me a job to fix bugs, ha-ha.

So what we decided to do is suggest the simplest solution that would fix all of the most common cases. Implement this, and all mobs will survive on saving and reloading. Implement Xcom's other fix, and all mobs growing up will also survive. The only case that isn't covered is when hitbox sizes change between saving and reloading, which only happens on version upgrades, and this would not be the first time inconveniences happened on version updates. I think we can tolerate having that corner case unfixed for a while longer. If we insist that every possible scenario be handled, we'll never get anything fixed. If Mojang had this level of perfectionism, then they would indeed have fixed MC-119971 when they fixed MC-79154. That obviously didn't happen, and so hopper duping isn't 100% fixed. Practical compromises have to be made.

And to be sure, "mobs sometimes glitch into walls if their hitbox size changes as a result of a version update" is not part of this bug report. In fact, I bet you've never seen it happen! If you're really that hot and bothered by this remote corner case, we can file it as a separate bug report (actually, I think we should in any case).

> Mojang employees are hamstrung by an idiotic Microsoft policy that forbids them to even looking at code we post here

Dang. Then, we need to make sure that anything we post is clearly marked as "This is just psuedo code, and is not intended as an actual solution", right?

I'm not aware of such a policy (not saying it does or does not exist). In any case, analyses are always appreciated (whether or not they can be used directly). If you want to discuss that subject, please do so in /r/mojira and not here as comments here are sent to currently 170 users.

(Actual discussion of this bug can happen here or in /r/mojira, whichever is more convenient. But off-topic discussion should always be in /r/mojira)

Hey,

thanks for the clarifications. As stated I am not against the idea or try to argue for the NBT-Saving idea. I just want to make sure the given reasons are valid reasons for the argument here. Lets look at the given list:

1. Issue of backwards compatibility.
I would disagree that this would be a factor talking about Minecraft.

2. Corrupted hitboxes would persist.
I would disagree with this also. The reason being that hitboxes do not 'persist'. They area changed on each tick to represent the given position and dimension of an entity. Thus always being corrected. The only reason for saving the AABB in the NBT data is because the code-flow is broken by saving/loading entities. You could probably even not save the AABB and just re-set the initial position of the entity later in the NBT-Loading method to get the same working flow again - calling .setPosition and re-calculating the AABB in the NBTLoad-Method is whats breaking said flow.

3. Any hitbox loaded would need to be corrected and as been in described in length because of the rounding artefacts would create an ambiguous state when a hitbox isn't at its correct size.
As far as i can tell this is answered with 2.? Feel free to correct me.

4. If hitboxes are corrected it could still result in the same overlapping walls problem that was started out with.
I do unfortunately not understand to what you are referring here with 'hitboxes are corrected'

5. Extra storage for no reason when a simpler solution fixes the issue.
I agree that additional storage is to be prevented but don't think its a strong point considering the amount. And I´d argue the use of 'simpler' in the sentence strongly 😉

(6.) One of the initial arguments as I understood it is that the margin-Solution would fix changes to the Entity-Dimension made by the developers (See the quote in my last comment). As far as I can tell from your explanation this would definitely not be the case based on the defined margin-Size. If you ONLY talk about changes made to the code-flow and recalculation of position/hitboxes etc. then I´d agree.

As far as I can tell the main difference in our understanding of the code (and feel free to correct me here) is that you consider hitboxes to be fixed values in the entity while I am of the impression that they are only used as dynamically created temporary values that change each tick anyway.

Do you have a explanation what needs to actually be changed in the code to make a working build similar to my reddit-post linked above?

(@Timothy regardless of whether or not bugs get fixed I don't think you are helping yourself with the off-topic parts of the comment)

There are two kinds of position information stored for an entity. There is a bottom-center position and an AABB. Whenever a method changes one, the other has to be recomputed to match. Both are stored separately in the entity object. This is only really problem if a saved entity is squished up against a block. Computing the AABB from position is lossy and can result in the position being a little too close to the wall. When the entity is saved and reloaded, the AABB is computed again, and it can overlap the blocks.

There are methods that will move an entity on the basis of position, which will cause the AABB to get recomputed. I haven't investigated thoroughly, but I have the impression that most mob movements are caused by motion vectors, which push the hitbox. We need to check the AI code. There have been bugs in the past with mob hitboxes, and if one gets changed, we do want the fix to take effect immediately, I think.

Using the margin would require no new NBT data, so that's a plus.

Saving the AABB in NBT isn't really a big deal, though. When saving, save the AABB too. When loading, check to see if the AABB tag exists in the NBT. If it does not, calculate an AABB as before; this deals with compatibility with earlier versions. If the AABB does exist, then just directly set it on the object. (Note that there are TWO places in the readFromNBT code that calls setPosition. I don't know why, but we have to fix both, so loading position and NBT should probably be moved into a separate method. Either that or the redundant setPosition should be removed.) If the world gets loaded in an older version, then the AABB data will just get ignored, handling compatibility with older versions. There isn't anything more to it.

The more complicated solution I mentioned involves saving both an AABB and a byte with 6 bit flags in it, one for each face of the AABB. Upon reload, if one of those faces is flagged, then that means the new AABB and any adjustments to position must respect that boundary. It would not be hard to implement, but it's not so easy to describe. The code that pushes the hitbox around (moveEntity?) can keep track of whenever a motion vector was restricted by blocks in the world and store that in another variable that gets saved in NBT, and the flags only get cleared when the entity moves away from the blocks. Then the methods that convert between position and hitbox will need some switch statements for three pairs of bits. For instance, if bits 0 and 1 correspond to minX and maxX, then compute (aabbflags & 3), and case 1 would hold minX constant while using the hitbox size to compute a new posX and maxX. Something similar happens for case 2 for maxX. Case 0 means there are no restrictions, although if an entity is really close to a wall, a hitbox "upgrade" on reload could glitch it into a wall. Case 3 is a conundrum, but I would just throw it in with case 0; plus it could be intentional, like a piston having squished a bear between blocks. Z and Y would be handled similarly.

As for my off-topic comments, I apologize for that. I only wanted to emphasize the point that we should not be striving for perfection, only improvement.

Forgive me for commenting with a lack of full understanding, but as I see the issue, the basic idea is that collision detection only compares the bounding box to walls outside that box.

Would a simple, and better behaving test (solves the child grow-up as well) be to say that the center of the object (and it doesn't have to be exact) cannot cross a wall?

I.e.: If at any time, the bounding box for an entity crosses the bounding box of a wall/fence/etc., and the center does not, then the whole entity is moved so that the bounding boxes do not intersect.

This code check would be placed where new bounding boxes are computed, rather than on save/load.

Benefits: It solves all issues – rotation, save/load errors, growing up.
Potential problems: I don't know how frequently a BB is recalculated; if it's too frequent, this would take too much CPU. Can't recalculation go on a thread?

:info: This discussion is getting longer and longer, please keep further comments short* and on point, or continue the discussion over on the /r/mojira subreddit.

(587 comments here so far, my computer is lagging, help)

_{*) If you have a code analysis which is fairly long, also post it on /r/mojira. It can be linked to in the description of this report.}

As a suggestion given above margin is suggested to be added in AxisAlignedBB.java both in “calculateXOffset” and “calculateZOffset” not in “calculateYOffset”. There might be edge cases where “calculateYOffset” might also benefit from this fix. As there are no side effects adding this tweak then I would suggest also adding it to the “calculateYOffset” as well giving all axis a simple margin fix. Mostly as there are edge cases where other types of entity's glitch through some other types of blocks in rare situations.

Persistence in 1.12.2.

Persistence in 1.13 ??

I've been unable to reproduce this issue ourselves in 1.13 (though MC-9568 has been reproduced), using the "kill wolves" setup. If you're able to reproduce it, can you specify the version, and any changes to the setup (if you know how to consistently reproduce it)?

Hello @unknown, look at the top right of each bugpost, there you can see the following things:
People
Assignee:
Reporter:
Votes:
Watchers:

And exactly upfollowing here, at "Watchers", there is a textlink:
"Stop watching this issue"

Click there to unfollow those bugposts you don't want to automatically get sent an email notification anymore.

FYI, those are really old messages that were replied to via email... which JIRA doesn't (didn't?) support, but now it seems like all those years of old emailed messages are suddenly going through (note that these all say they're from 2015).

I'll hide those comments. But to anyone who is getting unwanted emails – as mentioned by Meri, select "stop watching this issue".

Please disregard all of the following. I will post about a much simpler solution in my next comment, and that should be the end of it all.

I have implemented and tested a fix for this bug, which I describe in detail in the following reddit post. There, I explain and illustrate the cause(s), explain the solution, and describe testing.
https://www.reddit.com/r/Mojira/comments/8m1nta/proposed_fix_for_mc2025_on_chunk_reload_mobs_get/

My solution addresses the bug by fixing the underlying cause (floating point rounding artifacts that affect opposing AABB faces inconsistently). Additionally, it requires no NBT changes, interferes less with game updates that might modify entity sizes, and avoids long-term compounding drift of AABB faces (in contrast to saving the AABB in NBT).

The code for the MC-2025 fix is currently intermingled with a fix I developed for MC-4, so I'm planning to separate them before I upload code to mojira. Meanwhile, you can see the code here, along with a minimal testing world:
https://www.dropbox.com/sh/p8p4cdjmt2jrqm5/AAARSbXvkcgeBfrH8_ZIQSDRa?dl=0

The following is the most minimal fix we could come up with for MC-2025. It's absolutely brainlessly simple, and it WORKS.

There were rumors that MC-2025 had been fixed already, so I was comfortable tinkering with more complicated solutions. However, we can't find any evidence of a fix from decompiling 1.13-pre1, so I have decided to be practical here.

Along with plenty of other people, I, Xcom, and MrGrim (Michael Kreitzer), and Kademlia came up with basically the same solution independently. Xcom's has been in Carpet Mod for ages, and MrGrim has been using it in his own custom JAR for probably about as long. The really embarrassing thing is that Kademlia figured it out about two years ago, well before any of the rest of us (https://bugs.mojang.com/browse/MC-2025?focusedCommentId=317274&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-317274). A little over a year later, I found the underlying cause (https://bugs.mojang.com/browse/MC-2025?focusedCommentId=408078&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-408078). But everyone just argued for "better" solutions (including me), which was dumb. There are no intrinsically better solutions.

There's no point in "correcting" the AABB. The drift is on the order of 2^(-46). Moreover, AABB inflation is statistically as likely as the shrinkage that causes the bug, so there should be no long-term cumulative drift, just random wobble in the size. More detail and justification are included in my corresponding /r/mojira post. So I think it's about time that this bug just got fixed once and for all.

Based on MCP symbols for 1.12.2, the following methods on Entity need to be modified:

• public NBTTagCompound writeToNBT(NBTTagCompound compound)

• public void readFromNBT(NBTTagCompound compound)

Saving the AABB on chunk unload

In writeToNBT, somewhere within the try block, do the following:

AxisAlignedBB aabb = this.getEntityBoundingBox();
compound.setTag("AABB", this.newDoubleNBTList(
    aabb.minX, aabb.minY, aabb.minZ, aabb.maxX, aabb.maxY, aabb.maxZ));

Restoring the AABB after chunk reload

There are two places in readFromNBT that call setPosition, which resets the AABB based on entity width. It is very important that this new code be inserted after those calls. This needs to be the very last thing inside of the try block.

So right after this:

if (this.shouldSetPosAfterLoading())
{                
    this.setPosition(this.posX, this.posY, this.posZ);
}

Insert this code:

if (compound.hasKey("AABB")) {
    NBTTagList aabb = compound.getTagList("AABB", 6);
    this.setEntityBoundingBox(new AxisAlignedBB(aabb.getDoubleAt(0), aabb.getDoubleAt(1),
                                                aabb.getDoubleAt(2), aabb.getDoubleAt(3),
                                                aabb.getDoubleAt(4), aabb.getDoubleAt(5)));
}

Note: If you load an old world that lacks the Entity AABB tags, some entities will be loaded with bad bounding boxes, and they may get pushed into walls. The reason for not proactively fixing those cases is that people have been known to decoratively encase mobs inside of glass blocks, and we shouldn't break that. However, from that point on, the saved AABB will be used, and entities will never again get accidentally lost inside of walls.

This really should be the LAST Mojira comment on this bug. A simple, reliable, and mathematically correct fix has been provided. And that fix has undergone extensive empirical and live testing on multiplayer servers (e.g. SciCraft) for 1 to 2 YEARS. For any further questions or comments, please bring them to over to the /r/mojira post.

Link to /r/mojira post: https://www.reddit.com/r/Mojira/comments/8pgd4q/final_and_proper_fix_to_mc2025_simple_reliable/

Code attached: https://bugs.mojang.com/secure/attachment/169871/final-mc2025-fix.zip

Since we now have a fix, and since 1.13 has not yet been released, can we please get a quick 1.12.3 so that those of us who play modded can make use of these various (this one, the Redstone dust one, etc.) community contributed fixes without having to wait for another round of "all mod catch-up"?

This has not been fixed yet, although a fix will likely happen in the near future.
As this is not a critical exploit, a 1.12.3 will most likely not be released because of this, especially since 1.13 is to be released in 2 or 3 weeks.

I have been unable to reproduce this bug in 1.13.2. Looking at a decompile, it appears that the developers fixed this by applying a 0.001 block margin around the Entity when computing collisions with blocks. I hesitate to formally declare the bug fixed without developer comment. However, my test setup was able to reliably reproduce this bug over and over again in 1.13.2, but no deaths occur in 1.13.2, and I found the code that applies the margin, and some debug trace code clearly associates the function applying the margin with block collisions.

I'm not sure if this is exactly Xcom's fix, but since he was the one that suggested applying a margin, we should at least partially credit the fix to him. Many thanks to Xcom and to the developer(s) that decided to adopt his solution.

My horse somehow made it on the other side of a fence while I wasn't looking. No other blocks that it could have climbed to get over that fence. Not sure if it happened when the chunk loaded 5 mins earlier when I came back from an excursion. There's a llama in the same pen also.

Did it happen with the last snapshot (19w03c)?

I have this issue on 1.14.2

I have this issue, especially with chicken and villagers, in 1.14.4. Chicken just escape a fenced off area, while villagers somehow even manage to escape a village that is fenced off twice, with a cobblestone wall and another 2.5 high block wall 2 blocks outside the first one. The village is partly inside spawn chunks and some players also have their bases in a distance that might keep only half of the village loaded.

I attached 2 screenshots that show the part that is not inside spawn chunks anymore, but closer to players' bases. This is one of the parts where villagers seemd to have gotten out. There are no beds anywhere near the walls and no baby villagers growing up. One of the villagers was unemployed, one was a nitwit (in the screenshot), but also employed villagers have gone missing and some even vanished (probably died).

@unknown, your issue is probably unrelated to the issue in this ticket and tracked in MC-153904.

I don't think it's related to MC-153904 since the villagers and chicken usually don't vanish, but can be found outside the fenced-off area. Only 2 villagers have gone so far and they probably died (and not just vanished) because I witnessed one being chased by a zombie at night who would have died as well if I hadn't been there. I can't be 100% sure because I can't see the server logs on Realms, but I keep track of all the villagers and of over 50 villagers in this village only 2 have gone, but several more have been found outside and brought back in.

Ever since I've upgraded to Minecraft 1.15.1, this problem has been absolutely plaguing me, when I've never had it before.  It seems to be occurring the most with my horses.   If my horses are in a room, like a stable, one or two of them will eventually... be gone.  If I put them in a fenced in field, it usually isn't long before the horse goes missing, and I find the horse wandering around the world, if I find it at all.   This seems to occur even if I make a fence that's double thick around the field, or if I fence around the walls of the stable to prevent the horses getting to the wall blocks.   It's been a real bother for me.  I've lost multiple of my favorite horses this way in only a matter of a couple weeks.

Same happened to me recently, but with Villagers. Both of my villagers seemed to vanish out of nowhere, and I feel like this is the reason for it.

@Michael Reynolds

Does this describe your problem MC-153904?

Confirmed in 1.16 Release Candidate 1.

Confirmed in 1.16.1.

Confirmed in 20w29a.

Why am I unable to reproduce this? I used the same setup shown in the attachments and baby chickens remain in their box upon relog

I'd like to request ownership of this report since the reporter has been inactive since November 2012.

happen in 20w49a

Confirmed for 20w51a. My villagers keep escaping their village where there is a fence around it. I ensured multiple times there is no way they can get out yet they still do. Strangely none of the fences are on chunk boundaries. It is possible they are glitching out diagonally through unloaded chunks.

Requesting ownership as the current owner has been inactive for over 8 years

Can this still be reproduced in 21w05 or later?

I am the owner and i’m not inactive, so I’d like to keep my ownership.

You were inactive

I've never really been inactive since I've been receiving every update of this Bug Report on my email address 😉
 

I was saying it as in you were not updating this bug report. While you may have been checking it by e-mail, that does not necessarily mean that you are active 😉

The bug description seems ok for me. No need to be updated.

Also I've seen moderators updating descriptions by adding references to relevant comments. So bug descriptions do not need to be managed by the reporter. Changing it may even cause confusion.

Occurring in 1.18.2

Can confirm in 1.19.1-pre2.

Can confirm in 1.19.1-pre3.

Finally after months of trying I was finally able to make an account on this website... This bug is still occurring in the latest version 1.19.1-pre3. I've lost two villagers and multiple pets to it. I cannot comprehend why this issue hasn't been fixed after almost a decade and a literal fix in the bug report itself that Mojang can use.

Now that you have an account, please only use it if you actually have new and useful information. Every comment here sends out 203 mails. And yes, Mojira has a bunch of big issues on its own, we know. If you want to discuss further, please go to reddit.com/r/mojira or the Discord group linked somewhere there.

Can confirm in 1.19.3 and 23w04a

Can confirm in 23w06a

Still in 1.20.1, keeps ruining my villager hall...

Affects 1.21

Can confirm for 1.21.3

Confirmed in 1.21.4

TLDR:
Various bugs causing MC-2025 have been fixed over the years. The remaining ones listed here are no longer reproducible.
If you are still encountering issues please follow the steps to create a new report for them.
 
Happy 2025!

The long version:

Hello everyone!
 
MC-2025 is the most up-voted bug report on the bug tracker. It has been open for over 12 ⚠️ years with so many contributions and reproductions from so many people.
That the issue is still open after 12 years is not down to a lack of trying to fix it. But the reality is, that there have been a lot of different contributing factors in the code, resulting in many different issues manifesting in a similar way.
As specific causes got fixed, the details on this report have been updated to match the remaining ones.
At this point a lot of them - in fact all that we are aware of - have been fixed!
 
It's not easy to get a full list of the underlying problems that caused MC-2025 and related issues, since many of them were never separately tracked as an own bug report.
 
But here is a list of a couple we were able to find:

• Collision boxes having floating point rounding issues at high coordinates
  Fixed in 1.5

• Collision boxes being globally changed from several threads
  Fixed in 15w38a (1.9)

• Collions issues on chunk loading
  Fixed in 17w47a (1.13)

• Baby mobs growing up next to blocks (MC-9568)
  Fixed in 21w05a (1.17)

• Chickens spawned from eggs being in blocks
  Fixed in 21w05a (1.17)

• Frogs growing up next to blocks (MC-253791)
  Fixed in 24w19a (1.21)

• Baby mobs growing up next to blocks below blocks (MC-252846)
  Fixed in 24w19a (1.21)

But there is no doubt there was more!
 
 
So, what about the possible reasons that are still listed in the description of this report?

• Floating point inaccuracies
  We got no working reproduction steps and nothing that would suggest this is still an issue.

• Mobs moving in unloaded chunks
  It's questionable this ever was an actual issue. If it was, it has been fixed long ago.

• Baby mobs growing up
  Fixed as per MC-9568, MC-253791 and MC-252846

With all this said, at this point we see no value keeping MC-2025 open.
It looks like the issue described by the title "when loading chunks" has been fixed by larger collision refactors in 17w47a (1.13), so we will be setting this as the fixed version.
The issues of mobs growing up next to blocks getting out was likely the reason MC-2025 got reopened the last time it did, but this has been fixed since.
 
If you are still encountering issues of this kind, please don't ask for this report to be reopened, but instead follow the steps to create a new report.
 
Thank you for all the contribution on this and other issues over the years!
 
Happy 2025 and hpp new er!