Daniel King
- DV King
- dv king
- Europe/Stockholm
- Yes
- No
MC-21109
Northwest Favoritism.jpg
I will say right now that both
MC-12427andMC-4661are included in what I am about to report. However, I am reporting exactly what the problem is, how they are in reality the same issue, examples of other pathfinding issues which also occur, and how it could all be fixed with a single theoretical solution. It seems sort of conceded to ask if they could be consolidated into this report, but I feel like this single one is more constructive than a bunch of little ones out there which are all symptoms of the same bug.The problem
The problem with the pathfinding in Minecraft is that is uses a strictly grid-based system. This would be okay except that collisions are not as strictly grid-based. Entity movement accounts for this, but pathfinding does not. The consequences of this are far reaching. Basically there are many ways in which an entity may conclude that it cannot move when in reality it can and vice versa. Fixing this bug would make farming less frustrating and hiding from monsters much harder. Let me explain each of the four images inside the larger image I posted.1. Mobs (the creeper) get stuck in northwest corners
This is a combination of things. For one thing, entities begin pathfinding from their northwest corner instead of their center. For another, they do not take into account collisions properly. This means the creeper pictured begins his pathfinding from inside the corner fence. This creeper believes he can travel both north and west because it is air, and he cannot travel either south or east because they are fences. All four of these assertions are wrong. If he were to analyze collisions instead of just the grid he would know this.2. Mobs are incapable of passing through half slab gaps
Some people like and utilize this, but it is a flaw. The creeper knows he can pathfind through the center of the hole, but reasons he is too tall to put his feet through the center and his head through the half slab. This is false. He does not take into account where his feet will land, and the same can be said about his head.3. Mobs, especially small ones, get stuck inside walls
The picture is a special case in which the sheep has his northwest corner inside a wall. He can clearly step back and walk through the opening in the fence to my character, but he believes the fastest way is to walk through, because he is already "inside" the fence and does not take collisions into account. This same thing will happen with small entities far more frequently because their entire collision box can fit inside the fence block. This makes it a pain to lead animals along/through fences and other thin walls.4. Mobs cannot navigate through gaps between blocks
This is the same issue as the creeper who cannot walk through the half slabs but in the x and z dimensions. If the chicken were to acknowledge the size of its bounding box and which blocks it would collide with, it could reason that it is possible to fit through the gap.
Theoretical solution
If mobs were able to pathfind through blocks with abnormal collisions in the same way as they calculate movement (going as far as their bounding box will allow), all of these problems should be solved. However, this would require a substantial rewrite of the pathfinding code, possibly changing it to entirely double based. I started to mess with it myself but it is horribly difficult to read, even with MCP's rough translation. I will need to do a lot more tracing and variable renaming before I can understand exactly what needs to be done.I have been thinking of an alternative to rewriting the pathfinding to entirely double based code. If the pathfinder kept a little bounding box which represented where the entity was going (it seems to attempt essentially the same thing with a path point) and pushed it along like it was actually moving through blocks with odd collision boxes, it could set path points inside of fences and other partial blocks only when it is possible to move there. It should only have to make the calculations in circumstance when it comes into contact with said blocks. Then, once it concludes the space is passable, the vector stuff the code already does should make it move in a straight line.
At the very least, changing pathfinding so that entities begin from their center should fix situations 1 and 3 (
MC-12427andMC-4661respectively) for the majority of creatures (everything but babies, silverfish, and chickens).I will say right now that both
MC-12427andMC-4661are included in what I am about to report. However, I am reporting exactly what the problem is, how they are in reality the same issue, examples of other pathfinding issues which also occur, and how it could all be fixed with a single theoretical solution. It seems sort of conceded to ask if they could be consolidated into this report, but I feel like this single one is more constructive than a bunch of little ones out there which are all symptoms of the same bug.The problem
The problem with the pathfinding in Minecraft is that is uses a strictly grid-based system. This would be okay except that collisions are not as strictly grid-based. Entity movement accounts for this, but pathfinding does not. The consequences of this are far reaching. Basically there are many ways in which an entity may conclude that it cannot move when in reality it can and vice versa. Fixing this bug would make farming less frustrating and hiding from monsters much harder. Let me explain each of the four images inside the larger image I posted.1. Mobs (the creeper) get stuck in northwest corners
This is a combination of things. For one thing, entities begin pathfinding from their northwest corner instead of their center. For another, they do not take into account collisions properly. This means the creeper pictured begins his pathfinding from inside the corner fence. This creeper believes he can travel both north and west because it is air, and he cannot travel either south or east because they are fences. All four of these assertions are wrong. If he were to analyze collisions instead of just the grid he would know this.2. Mobs are incapable of passing through half slab gaps
Some people like and utilize this, but it is a flaw. The creeper knows he can pathfind through the center of the hole, but reasons he is too tall to put his feet through the center and his head through the half slab. This is false. He does not take into account where his feet will land, and the same can be said about his head.3. Mobs, especially small ones, get stuck inside walls
The picture is a special case in which the sheep has his northwest corner inside a wall. He can clearly step back and walk through the opening in the fence to my character, but he believes the fastest way is to walk through, because he is already "inside" the fence and does not take collisions into account. This same thing will happen with small entities far more frequently because their entire collision box can fit inside the fence block. This makes it a pain to lead animals along/through fences and other thin walls.4. Mobs cannot navigate through gaps between blocks
This is the same issue as the creeper who cannot walk through the half slabs but in the x and z dimensions. If the chicken were to acknowledge the size of its bounding box and which blocks it would collide with, it could reason that it is possible to fit through the gap.More details
It has recently come to my attention that small entities like chickens cannot pathfind out of fence corners even if they are told they can pathfind literally anywhere. This is because they cannot draw a vector out of the fence wireframe without concluding they will collide with it.Theoretical solution
Ideally, if the code could be more double-based, relying on the actual bounding box, this problem would be fixed in all instances. But, unfortunately, that would likely require a significant amount of processing. Instead, it is probably best to add more conditions to the code which allow pathing along but not through fences.At the very least, changing pathfinding so that entities begin from their center should fix situations 1 and 3 (
MC-12427andMC-4661respectively) for the majority of creatures (everything but babies, silverfish, and chickens).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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...
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.
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).
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.
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 have had animals swim off , to (from kilometers away), and past my island home following a northwest path. By and large it seems all the animals in my world migrate northwest unless I enclose them. Actually, if you look at large animal enclosures you can see a slight northwest bias. I hope this gets fixed as it is an annoyance when you have lived in an area a long time. Good 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.
...? 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.
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.
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.
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).
Are you experiencing a noticeable FPS drop? I am not having jittery movement in my tests.
@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.
@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
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.
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.
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
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.
=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 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:
This was basically my solution:
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.
@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.
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).
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 fixEDIT 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
12th13th version of my fix. It does include my fix for baby animals shifting northwest on load as well: MC-2025 Bugfix 1.6.1 v13And in case this was not understood for anyone just joining in on this conversation, this is not fixed in 1.6.2.
@ANBO Motohiko
No, that is a problem with core path-drawing methods, explained in
MC-21109, which honestly is the same problem asMC-12427andMC-4661(which have the same cause in the code), but explained in more detail for more situations. In that bug, an entity is trying to path from inside a fence. In this bug the random destinations animals choose to move in tend to be weighted northwest of it. Both bugs are annoying and should be fixed however.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".
@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.
@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:
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.
@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.
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
If you play for any extended period of time I think this is very, very noticeable.
@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.
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
@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.
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
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
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.
@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
Just so everyone know, this bug is mostly or entirely fixed as an unintentional side effect of my
MC-2025bugfix.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
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:
MC-10) are mostly if not entirely resolvedI 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.
Bugfix - Please read this post before commenting
@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.
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.
@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.@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".
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.