Daniel King

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. 🙂

@Torabi
No, I have no prior knowledge of the computational cost of pathfinding, but I do have a decent guess. And I do understand the challenges of pathfinding in a dynamic environment.
I do think I oversimplified the theoretical solution. Having read the pathfinding code thoroughly now, I am disappointed to say that I doubt it can function perfectly ever. Changing it from int based to double based would require exponentially more points, memory, etc. I think the only way the problem has any chance of being solved in a remotely optimal way is by continually adding even more conditions to the code that basically say "in this very specific situation, do this".

@Kumasasa
You are somewhat right. Actually, the exact source for this (and MC-4661) is explained in a separate bug report I made (MC-21109) which encompasses quite a few different issue all caused from the same flaw that pathfinding is heavily grid-based while movement is not. It is not one little bug but rather a conceptual flaw in the coding that sometimes mobs can pathfind when they cannot move somewhere and cannot pathfind when they can move somewhere. Obviously, whether a mob thinks it can move and whether it can move should always agree. The reason no mobs (including large ones) can pathfind out of northwest corners is because their pathfinding algorithm begins pathfinding from the block which contains their minimum x and z bounding box coordinates. Then, beginning from inside the fence block, they pathfind in a totally grid-based way and conclude their only possible paths lead through the fence they are stuck against.

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.

@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.

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

Just so everyone know, this bug is mostly or entirely fixed as an unintentional side effect of my MC-2025 bugfix.
Any questions, comments or concerns about the fix should be posted in the comments section of the link:

MC-2025 Bugfix+ 1.6.2 v23

@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 do not think this is a bug. I am familiar with how the code for this is written, and fences and stairs actually specifically change their collision boxes to this form just for rendering the wire frame, then change it back again. However, I concede that it may be a bad feature.

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 🙂

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

@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.

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

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 🙂

@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.

I placed a bunch of sheep around me, trying to place them a little south east of where I was standing at the origin. I left it on while I was gone from home for 6 hours and got the picture NWtrend as my result.
I think this bug is clearly confirmed and in 1.6.2.

Just to quantify this, in each quadrant I had the given number of sheep
Northwest: 12
Northeast: 3
Southeast: 0
Southwest: 4

• That is based on the sheep which were rendered in the overhead picture. There were some not pictured.

If you play for any extended period of time I think this is very, very noticeable.

@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.

@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.

@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 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".