Mark Dykstra

Actually, I just discovered a workaround. Simply updating the bounding box in NBTExplorer to the correct height solves it. It's merely an issue of the data in Temple.dat being malformed.

Specifically, find the entry in Temple.dat the pertains to the witch hut (labeled in chunk coords) and then copy the value from ~/Children/BB to ~/BB. That aligns the two bounding boxes on the position where the actual witch hut spawned.

Affects 1.9.4. Is any workaround known for this bug?

Marcono's steps to reproduce are separate from the bug in question. The bug in question is regarding village doors that are still near villagers getting removed from villages.dat when the chunks unload, whereas Marcono's steps to reproduce are about doors being removed from the village when villagers are no longer nearby (which is not a bug but a feature). The original bug has in fact been fixed in 1.9.

Steps to reproduce the original bug:

1) Ensure you are not in the spawn chunks (/tp @p 1000 ~ 0)
2) Place a villager in a fenced area and a valid village door (see http://minecraft.gamepedia.com/Tutorials/Village_mechanics)
3) Wait a minute for the door to register and then check villages.dat. You'll see an entry for that village with one door
4) Teleport yourself 1000 blocks away (/tp @p 0 ~ 0)
5) Wait a minute for the game to register that the village is no longer loaded.
6) Check villages.dat again. In 1.8 and older, the village you created will no longer be listed. In 1.9 (or at least 1.9.2), it correctly remains listed in villages.dat.

This bug is fixed. If Marcono wants to make a separate report for his "bug" he can but I'd say that the situation in his steps to reproduce works as intended. Villages are supposed to die if they are no longer populated by villagers.

I don't think it's that irresponsible to make a video about a bug exploit. After all, the reporter of this bug does it all the time. 😉

Although this bug definitely needs to be fixed. It's a highly pernicious bug that breaks a lot of things that ought to work.

Happened to me with named ghasts in minecarts in 1.8pre2. Makes it a real pain trying to keep a Zipkrowd Wither Wiper working. 😛

Aw, you guys fixed this without adding the option to use the new model? I was using this bug so I could have a skin with the new model. lol

I added steps to reproduce. It should be simple to try the skin I gave on and see for yourself.

It does also apply to the other "back" sides of the sleeve layer (the side next to the body and the back of the arm). They likewise would be seen if they stick out from behind the arm, but aren't rendered in first person.

I mean that the end of the sleeve layer should be visible if it sticks out beyond the edge of the arm itself. If your sleeve layer is a solid rectangular prism you can't see it, but if parts are missing from the "sleeves" of your sleeve layer you can see it. In my skin, the stripe going down the side connects with the plus sign on the end, but the plus sign isn't rendered in first person, so there's a gap.

This may also apply to the other two "back" sides of the sleeve layer. I'll go test that.

Ok, I made a more obvious example. Take the default skin and just add a big red square to that area only. Clearly visible (even from above) in third person, but in first person completely missing. Included skin file so you can try it yourself.

EDIT: That area is invisible in your "gloves" skin because the sides of the sleeve layer cover it, but in my skin the sides are mostly transparent (like in the steve skin which has no sleeve layer).

I'm talking specifically about the end of the sleeve layer. Your skin doesn't have that area, Galaxy_2Alex. Uploaded screenshots with comments as well as a skin file you can use to verify (and a blown up version with comments).

I see this issue whenever I increase my render distance from 11 or below to 12 or above. Restarting the game (not reopening the map or relogging from the server) fixes the issue, and the issue only happens if my render distance is set to 11 or below when I start the game.

And yes, I have an AMD Radeon HD graphics card.

EDIT: And of course as soon as I post this it completely stops happening. Still, I have had this happen several times when increasing render distance and I am quite sure it was the switch from 11- to 12+ that triggered it, as I definitely just had it happen when I changed from 11 to 12. It's also worth noting that turning your render distance back down removes the glitch.

BTW this is still the case in the latest snapshot (14w33b) and affects all mobs, not just pigmen.

Suffocation mechanics changed in 1.8 so that instead of mobs suffocating when a block overlaps with the top full block their hitbox, it's only the top half block. I would argue this works as intended, since for most mobs (including Zombie Pigmen) their head appears to occupy the top half block of their hitbox. If you wish to duplicate the previous functionality of a 1.5 block tall crusher (killing pigmen but not wither skeletons), use a full 2 block tall crusher instead.

Same when ender pearl glitching into a barrier (either into the side by throwing one at the ground in front of you when next to be block or the bottom by just throwing a pearl at the bottom). I was really hoping I could ender pearl through them in survival. XD

Also an issue when switching from spectator mode to any other mode while clipping a barrier.

I know you're not supposed to get through the things, but it would better to implement the deterrent as excessive suffocation damage (say, 9001 hearts/tick) than as a crash. And I do suggest implementing something like that because otherwise adventure maps could be broken by ender pearl glitching. If you don't want players in your map dieing from barrier suffocation damage in minecarts, don't make your minecart rails pass directly under any barriers. Or Mojang could just make entities in minecarts immune to barrier damage.

To be specific, the hopper minecart picks up items in a 1x1 square centered above its southeast corner. It should obviously pick up items in a 1x1 square centered above its center. This is a version of the classic off-by-1 programming error. My guess is that that hopper minecart's location is saved as its southeast corner's position and whoever coded this feature assumed that it was saved as its center. Showcased in this video: http://www.youtube.com/watch?v=U6BWv8b94RI

Easy to confirm by watching the video or just placing a hopper minecart under a block and throwing various items on top. Any items that don't land on the southeast quadrant of the block fail to be picked up. Presumably also affects snapshots, people have noted this bug ever since hopper minecarts were added so I don't think it would accidentally be fixed.

This is a HUGE issue. I started a new world just a few days ago as a tryout server for my main server and have (among other things) been AFKing near spawn to let plants grow and a chicken farm run. Then when I get around to going caving the caves are FULL of chickens. Chicken jockeys may be rare but leave a world running for a while and you get a huge buildup of chickens, which cannot be removed by any means except exploring dark areas to kill them by hand because switching to peaceful doesn't even despawn them. Never underestimate the amount of lag that can be caused by passive mobs, because they simply build up without disappearing. Within a matter of weeks (if not days) every survival world will be brought to its knees by an invasion of thousands of unsolicited chickens. You might as well implement Zelda chicken AI and label them as hostile mobs. 😉

In all seriousness, I suggest making chickens despawn when the riding zombie despawns (although not when it is killed via other means) and making eggs part of a list of items that mobs cannot pick up (including rotten flesh and other common mob drops). That second point should help clear up the issue of passive (not initiated by a player) zombie buildup because as it is zombies can also build up in cases when other mobs die near them. Simply making zombies despawn if the item is not dropped by a player would not be ideal because a zombie could pick up an item that a player mined or shot from a dispenser and despawn with it.

Well, not exactly. In the 1.7.2 snapshots it changed so that instead of blocking tree growth, vines destroy logs. That is, any vine that occupies the space a log would occupy will replace that log. So vines don't prevent tree growth, but they do ruin it. I'm keeping this ticket open in case the fix for MC-29853 causes it to revert to the way it was. If that bug gets fixed properly, then this bug is out the window.

Still an issue in 1.7.2, and presumably the snapshot too because the changelog is devoid of bugfixes.

Still an issue in 1.7.2. If this were fixed it would make a lot of automatic farms a lot better, at the moment hopper minecarts are a pain because of this.