Steve Mellross

I just ran into this issue as well. I've attached the world 

that demonstrates this with the dispensers in different orientations as well as the "T", to show that it is purely based on the direction of the "T", not the dispensers.

So much for my auto wither killer that only works if the Wither is facing in one of the broken directions. Not sure how I'm going to use my 6 double chests of Wither skulls now. 😅 I guess I can bounce back and forth in a minecart with the right mouse button held down and a dropper to make sure my stack never runs out....

@unblocked: The new behavior you mentioned is actually a separate issue tracked by MCPE-120829 “Experience orbs not moved by flowing water” if you wanted to add your vote to it as well. 👍

Could also just have the mob drop any picked up items on despawn. Or both.

Other ways for items to be dropped without player interaction:

• Mobs killed by lightning.

• Unsupported gravel/sand from world generation getting updated by flowing water/lava (only on first load only when water/lava is in the process of flowing)?

• I've often seen patches of broken kelp, and sometimes broken blocks (gravel?) floating in the ocean on my way through an area. I have no idea what caused this, except possibly unsupported gravel getting updated (making it the same issue as the last one), but it could lead to drowned holding items in open water areas.

There are also quite a few ways with indirect player interaction simply by not picking up all player-caused dropped items. The hardest of these to avoid would be:

• Decaying leaves after chopping down a tree.

• Breaking blocks near a cave opening or ravine. They could be carried in deeper by flowing water.

• Player death when you can not find your corpse (although, hopefully this doesn't happed that often!)

It's annoying enough picking up all the easy drops, like from killed mobs, or unwanted items from mining. It's nice to just be able to throw unwanted items on the ground without worrying that you might be creating a persistent mob that will give you headaches later.

As requested in MCPE-60552, my seed is 538239489.

The witch hut is at [1235, 1603]

The persistent spawns I checked in the area were are listed in the table below:

Notes:

• There were a lot more more found that I did not check. They will be visible in the image, but not listed here.

• A "Y" value of "hole" means it was a water-filled hole accessible from the surface.

• "Zombie" includes Zombie Villagers.

• Only the ones within 4.5 chunk offset (measured from center of witch farm chunk) contributed to the population cap. I had the position slightly off in the attached screenshot (see below) from MCPE-60552, causing my outlined area to be one chunk too far West. With it in the correct position, the number of persistent mobs in the 9x9 population cap area was 11, not 9. Correct numbers used below.

Here is a screenshot illustrating the positions after quite a few of the Zombies were killed (and the ~40 Drowned). See MCPE-60552 for a full description. Again, note that the outlined area is one chunk too far West so one drowned is incorrectly included and 3 zombies are not marked.

@GoldenHelmet, do you want me to create a separate issue for persistent spawns building up without player interaction? I was going to add it to Minecraft Feedback since it seems to be a side-effect of intended mechanics but happy to treat it as a bug instead since it seems to break lots of farms and general mob spawning over time.

It's hard to say. I spent a heap of time AFKing - but that was ~128 blocks up, intentionally chosen to be out of range of any non-witch hut spawns, so would not contribute to mobs building up. At a very rough guess, it would probably be around the 24 hour mark of time spent on or near the surface because I'd built three other farms and the witch hut farm collection system in the area. I probably also left my character unattended at the witch farm collection area under the witch hut for a few hours here and there as well. I'm generally pretty careful about that though since I'm not overly confident in the spawn proofing there.

I was probably getting waves of spawns whenever I came near the surface bringing previously out-of-spawn-range areas into range, so it might have been just as dependent on how many times I'd been in and out of the area. Although, mobs would need time to die to drop items to be picked up as well... So, a quick fly into range then up to the spawn point might not contribute at all.

It is worth noting that I had two Zombie drowning holes pretty close to the 9x9 chunk boundary. One with 8 persistent mobs about 16 blocks out, the other with 7 (one an Illager?) about 20 blocks out.

If they had been in range, it would have broken faster. Luckily those holes are relatively easy to fill in. I'd already filled in quite a few early on. I'd previously (mostly) spawn proofed the 12 chunk simulation area around my iron and slime farms. All mob spawning had stopped in the area, mostly due to large holes that had ~50 drowned in them each (resulting in multiple double chests of gold armor gear as I was collecting it all at the time to smelt it). I did AFK near the surface there though. Because of this, that was one of the first things I checked for in the witch farm area.

It's also worth noting that I could not get the slime farm spawning any slimes (surface or cave) even after filling in all these holes and lighting up all the caves I could find in survival. Which was no small task! It took weeks. I had to create a creative copy after that and use the commands above to find the remaining caves and holes (some had what I assume were persistent surface spawn zombies trapped in them) before even a single slime would spawn. I had AFK'd at the iron farm on the surface for quite a while before this point though. I have no idea how long for. Still, it's pretty game breaking if there is no reasonable way to resolve it in survival only.

I confirmed the water slow-down issue.

• With flat grass at sea level (63) for the 9x9 chunk around a witch hut, I got 202 witch spawns in half an hour.

• With water 13 blocks deep (50 to 63) in that same area, I  got 26 witch spawns in half an hour.

• Interestingly, with a single layer of water, the spawn rate did not change, getting 208 witches in half an hour. Two layers seems to where it kicks in all at once.

I have attached two worlds indicating this. One for the grass case (

), the other for the 13 blocks of water case (

). If you stand on the spawn block and flick the switch, it will kill all entities, then give you an item for each witch spawned after that.

Note: The 9x9 chunk area is not significant. I just chose it because that is the density cap area. I'm pretty sure only the witch hut chunk matters. If a 16x16 roof of spawnable blocks is placed above the witch hut chunk (e.g. at level 80) and lit up in the water world, the spawn rates are fully restored to normal.

It does seem to come down to spawnable columns within the chunk. With grass, the full 256 are spawnable, With water, there are only 38 (the flat part of the roof and the porch). This 256:38 spawnable block ratio matches up with the 202:26 spawns per half hour ratio pretty well.

Edit: Updated to remove stairs as unspawnable. They are transparent to spawn attempts if there is at least one block gap below them.

This means there are three separate issues that can affect witch hut spawning:

• Water causing a major reduction in spawn rates. Described in this comment. This can be resolved via adding a solid spawnable-block roof over the chunk.

• Normal cave mobs spawning in the 9x9 chunk density area around the hut chunk and exceeding the 8+1 structure spawn limit, temporarily preventing any witches spawning. See my second comment above. This can be resolved by moving far enough away that the mobs despawn. If you are not above the hut such that it is the only spawnable area, the mobs could very quickly build up and exceed the density limit again once you return to the area.

• Persistent cave spawns, not caused by any player interaction, building up in the 9x9 chunk density area around the hut chunk and exceeding the 8+1 structure spawn limit, permanently preventing any witches spawning. See my first comment above. This can only be resolved by somehow finding and killing the persistent mobs which can be very difficult without using commands.

Ideally you would not need to be aware of all these mechanics and their workarounds for the witch hut to spawn witches reliably.

A further note on the last point in the description about the 8 + 1 density cap for structures being easily defeated by the 8 density cap filling up then an additional mob wandering in: It seems like it would be much easier to fill than that since it checks around where each mob spawn. The 8 + 1 limit for the witch hut is around that specific chunk and that area cap is only checked for a spawn at that point. Any other mobs in that area will have checked their own 9x9 chunk which will overlap, but may not be the same. This would allow 8 mobs to spawn to the North-West with the witch spawn in the corner of their 9x9 chunk area. Another 8 could spawn to the North-East still overlapping the witch spawn but not the other 8 mobs, and the same for the two South corners. That's 32 mobs that could be contributing to the a population density check at the witch hut location without any mobs moving after spawning or violating their own density cap checks.

If the mechanics from the wiki this is based on are correct, it means a +1 structure cap is not effective at ensuring that structure can spawn a mob. It only ensures a spawn in the structure chunk will not prevent the structure from spawning an additional mob, not spawns in other chunks in it's 9x9 chunk density area.

This illustrates the point:

The grid in the middle is the witch hut 9x9 chunk density area. The "8"'s in the corners represent groups of 8 mobs with the density areas they check on spawn in the corresponding color. They are all in the witch hut density area, but they do not overlap any mobs from another density area.

I had my witch farm recently stop working in the release before 1.16.220. It had the AFK spot 128 blocks above the witch spawn point and there were no other spannable areas in that radius. Constant witch spawns turned into not a single spawn between sessions. I knew I was not at the mob cap (I'd broken it with too many sheep before) because hostile mobs spawned all over the surface when I moved down so it was in range. I'd tried flying hundreds of blocks away and back to make sure, and no difference.

In a creative copy of the world, I discovered I had 9 persistent cave mobs within the 9x9 chunk population area around the witch hut spawn point. 2 zombies holding items and 7 drowned (see below for ways of persisting). These 9 persistent mobs filling the 8 mob hostile mop cave population cap and the +1 structure cap were all in caves I had never been in before so not persisted by any of my actions.

As soon as I killed the two zombies, witches started spawning again.

I am sure these mobs are persistent because the commands I used to find them were executed when I was over 128 blocks above any spannable point. FYI - those commands were of the form /execute @e[type=zombie] ~~~ fill ~ ~+2 ~ ~ ~+100 ~ concrete 11

I've attached an image showing the results:

There were a lot more persistent hostile cave mobs in the wider simulation area as you can see in the image. Close to 80 in total! There were also about 10 zombies I'd killed previous to this when I just checked for them in an earlier copy. If this trend continued at the same rate for about the same amount of time, it would reach the overall mob cap and break a lot more stuff!

As for the reasons the mobs were persisted:

• The zombies and zombie villagers I checked were all holding items (confirmed it persists them in creative) that can naturally drop in caves like mob-drops (arrows, slime balls, rotten flesh) I assume from natural deaths (e.g. lava, drowning, falling) since I had never been in any of those caves. Or gravel. I'm assuming it generated unsupported and then received an update somehow.

• The drowned I checked were mostly holding nothing or default items. They were mostly in water filled holes though, so were probably zombies that fell in and drowned while holding an item they picked up on the surface. The drowned will stay persisted even if they drop the item on conversion (tested in creative). 

• Some drowned were holding items like rotten flesh, so these may have been normally spawned (or non-persisted converted) drowned that just picked up an item.

• The skeletons were all wearing armor at or near the surface in areas near where I'd been. I assume they were persisted by picking up armor I'd left on the ground after killing other mobs near by (tested in creative for skeletons and zombies).

Note: All the testing I did in creative was with naturally spawned mobs and I would always test alongside another mob without the change to ensure it would despawn while the other didn't.

This is now present in non-beta version 1.16.220 as of today for me. It definitely was not present yesterday before the update hit.

Luckily I have build my farm and know the XP orbs get delivered correctly so it does not matter if they are all rendered in a completely different place. I will not be able to modify it or build another one reliably until this is fixed though.

The test world uploaded for MCPE-109326 can also be used to demonstrate this issue.

I can confirm. It kicks in way to close.

It there a setting we can use to prevent this in the meantime? It makes a huge difference to the experience. The shroomlights are just blurry blobs for the second pillar.

That definitely seems like that is the cause.

More info may be required though (hopefully cover in a later part eluded to above). I tried changing the "normal" entry to "heightmap" using the same image with the height map data in the red channel to get the height maps working again but this resulted in the netherrack texture completely failing to load and using a purple and black checkerboard pattern. I tried it with a greyscale (PNG) version of the image but the result was the same.

The documentation also has some inconsistencies. The second point for the "heightmap" entry in the Layers section reads "This layer does not support uniform values in JSON (i.e. only supports reference to a texture)." but then a later example shows: "heightmap": "#7B". Same with "normal". The same image-only constraint is listed, but another example shows: "normal": [ 130, 135, 140].

Might also want to auto-format the examples. The indenting and spacing is all over the place. 😉

I removed the "normal" entry in netherrack.texture_set.json and it seems to have resolved the issue, at the cost of being unable to use height maps of course.

This screenshot has almost all the non-netherrack textures removed from the pack so other blocks may look different between screenshots. Only glass and some emissive ones are also present.

The difference between the faces of the netherrack in the wall above the lava bucket are due to the roughness map which is still present and is very noticeable at different lighting angles. It transitions smoothly between angles now though.

I am also experiencing this since 1.16.200.56. Everything looked fine before this update.

I am using the following resource pack since it's the only one that emissive textures seem to be working for: https://mcpedl.com/vanilla-rtx/

I've attached an image that shows Netherrack at sunrise. It seems to be greatly affected by the lighting angle, looking almost consistent at night. I believe this texture pack uses the original textures, just with added height (not normal), metallic, emissive and roughness maps.

The Netherrack texture has non-flat height map data and, before this update, you could definitely see the effect of the height map where it caused "edge borders" between the larger 16x16 "pixels" that definitely gave them the indication of having different heights. This effect is also no longer present and it is back to a flat, sharp, 16x16 pixel appearance.

This may be related since the stone stairs (outlined in blue) have a flat RGB(127, 0, 0) height map and don't seem to be affected by this issue. Same with the white concrete (outlined in green) with RGB(0, 0, 0). Netherrack does also have a non-flat roughness map while the stone and concrete have flat roughness maps (170 and 200 respectively).

Metallic and emissive maps are 0 for all three.