Raid mobs can spawn on any block, anywhere

Nope, not fixed. I just tested and got them to spawn on leaves, giant mushrooms, and stone with buttons on top.

Why aren’t the illagers taking damage form the magma

@unknown I don't know, but that's not part of this bug report. Feel free to create a new report if you have that problem and can't find an earlier ticket reporting it.

@unknown They don’t take damage because there was another bug, that caused mobs to not take damage from magma blocks, which has already been fixed. See MCPE-47518

Affects 1.16.40 Hotfix.
Affects 1.16.100.55 Beta.

Affects 1.16.100.56 Beta.

Affects 1.16.100.57 Beta.

Affects 1.16.100.58 Beta.

@GinePik: Please do not add a new comment for every affected version. That makes the substantive comments harder to find. You can just edit your last comment to change the version. Also, it is not very important to add every new beta version to a bug that exists in the current release version. The most recent release version is enough to show that it is still an active bug, unless there is some question about whether a reported beta fix is effective.

They now spawn on scaffolding once in a while... I've watched them spawn right next to me on top of scaffolding in my bedrock realm many times now. 

I tested this and they cannot spawn on leaf blocks. Raids have always been able to spawn on any block except leaf blocks so this is completely normal behaviour for pillager spawning.

Tested in the beta 1.16.220.52, raids don't spawn on azalea leaf and flowering azalea leaf blocks.

Tested in 1.17.2, several blocks are now spawn proof from raids, the list contains:

Amethyst Bud (large), Twisting vines, Lantern, Powder snow, trapdoors, coral (and fans), Big dripleaf, campfire, fences, doors, conduit, anvils, composters, cauldron, sea pickle, grindstone, brewing stand, glow lichen, slime block, iron bars, signs, bells, redstone dust, lectern, shulker boxes, lightning rods, stone buttons (wooden buttons won't work), end portal (frames), armor stand, boats, minecarts, rails and chains.

Magma and fire still won't prevent raid spawns which is a bummer, but now leaves are no longer alone to prevent raid spawns. Further testing is needed though.

Jesse Kohn: I had a friend thoroughly test raid spawns and they found that nothing has changed: raids can spawn on any block except (1) blocks without collision, (2) leaves, (3) scaffolding. They also won't spawn inside of 2-deep water. The test involved covering solid blocks with various blocks and starting raids, then covering leaves with various blocks and starting raids.

Please provide more details on your testing if you still think there is a change.

I've only tested this on a 3x3 area in the end void, not in a bigger scale. I apologize for the previous comment posted.

I suspect one of the factors complicating testing this issue is that we keep talking about "spawning a raid" without defining what that phrase means. In the first place, raids don't spawn, it's raid waves that spawn, but that's a trivial correction. More substantively, spawning a raid wave means spawning a more or less fixed combination of illagers, vindicators, witches, evokers, and ravager beasts all at the same time. Such a complex spawn is very different from spawning an individual mob herd (a.k.a. "pack spawn"), but that's the mechanic we're relying on as we try to understand how it works. I think that's where we're going wrong, because raid spawning can't possibly work the same way as herd spawning.

Here's why: When the game is spawning a mob herd, all the mobs spawn on a single block and then spread out, so the game only has to find one block eligible for spawning one kind of mob. If the first few blocks it looks at don't pass the test, it's no big deal, it can retry lots of times before any delay is apparent. But when the game is spawning a bunch of mobs all at once, there are many more chances for a block eligibility test to fail. This magnifies the possibility of failure by a factor equal to the number of mobs, and if a block test failure causes the whole raid wave spawn attempt to fail (which is what happens in herd spawning), the failure possibility for the wave as a whole goes up exponentially. It could easily take half an hour or more for a wave to spawn successfully.

So to understand what our testing results mean in a way that can make all of our findings consistent with each other, we first need a new model of how raid wave spawning mechanics work. I'm now going to propose one possible model that can explain not only some of our inconsistent observations, but also might explain why they spawn in ridiculous places like on lava and in fire. I'm mostly just guessing and other models are possible, so keep an open mind.

I propose that the game spawns a raid by choosing a block to serve as what I'll call an anchor point. The anchor point will define the center of a sphere within which all the wave's mobs will spawn. (Coincidentally, it will also be the point that the raid horn emanates from.) The anchor point might have conditions that are tested for wave spawn eligibility, like a normal mob, while the individual mob herd spawns are scattered to random blocks within the sphere and have less rigorous conditions, or none at all, so that there's less likelihood of them failing to qualify and cancelling the entire spawn attempt. The spawn block conditions associated with the anchor point would be sufficient to avoid spawning the entire raid in a large-scale feature such as an ocean, lava lake, fire pit, etc., while the subsequent spawning of mob herds would be subjected to few or no spawn block conditions—which is why they appear to spawn on almost anything, and also why they often spawn underground.

(Side note: The program's data folder contains a folder called "spawn_groups" which contains a file for each wave, giving its mob composition and the conditions for spawning each type of mob. I notice that all the mobs have the spawns_on_surface component, which should mean they can only spawn on a block that has sky access. Since we know that raid mobs spawn underground sometimes, I think it's probable that these files are a work in progress and aren't actually used by the game yet, that the game instead has the spawning logic for raids hard-coded. It would make sense, then, that the spawn_groups files are meant to be the solution to the underground spawning problem MCPE-45183, and probably for this problem as well, but there is still some work to be done. Interestingly, the spawn_groups files do not specify any spawn block conditions other than on-surface spawning and a max distance of 1024 from (presumably) the anchor point.)

The point of all this discussion is that in trying to track which blocks raid mobs spawn on, we might be trying to infer the details of game mechanics that don't exist in the first place. Furthermore, there's some pretty good evidence that Mojang is in the process of converting raid spawning to a data-driven mechanic and that they already know how they're going to solve it, so additional information isn't really needed at this point.

Auldrick: Two replies:

Re: anchor points

Your concept of the anchor point is surely correct, but your theory on how that works can be shown to be incorrect by testing. The anchor point and any scatter points must satisfy the same block checks. The anchor point is chosen first, and then a search is made for scatter points using the same block criteria. If there is only one spawnable block, then the entire wave spawns together on that block (like an environmental herd spawn). The search range for scatter points appears to be 4 blocks in each direction.

You can use

to test spawn mechanics and spawnable blocks. It consists of a 150x150 smooth stone platform at Y = 149, and above that a single-bed village encased in leaves. Command blocks on top of the leaves allow you to place blocks for testing across the platform at Y = 150 ("Low Block Fill") and 151 ("High Block Fill"), as well as above the leaf structure ("Ceiling"). Another command block is used to start raids, and a repeat-chain command block pair marks raid spawns with soul campfires and instantly kills them.

If you want to see what I mean about anchor and scatter points, try these tests:

• Set "Low Block Fill" to leaves, "High Block Fill" and "Ceiling" to air, and then place one solid block above the leaf structure. Whole waves will spawn on that block. (Some waves may fail to find it; just start another raid if that happens.)

• Set "Low Block Fill" to leaves, "High Block Fill" and "Ceiling" to air, and then place a few scattered solid blocks above the leaf structure with leaves in-between the scattered blocks. Waves will spawn on the scattered solid blocks but not on the leaves between them.

• Set "Low Block Fill" to lava, "High Block Fill" and "Ceiling" to air, and spawn raids. Waves will spawn in the lava with typical scattering.

Re: the spawn_groups json files

I think these probably are being used, but they simply don't fully expose the raid spawn rules. Many mobs have special hard coded spawn rules that work "behind the scenes" of the exposed .json rules, or in spite of them. For example, magma cubes skip the block collision test that most mobs use (MCPE-46540), but they check for entity collisions unlike other mobs (thus armor stands are used to block magma cubes in fortress farms). Even the general environmental spawning algorithm has a block check for slabs that is not exposed as a block filter in any mobs' spawn rules json. So the fact that the spawns_on_surface filter does not always apply for raid waves does not mean that the file as a whole is unused.

There is, in fact, a part of the anchor spot search procedure that uses the same kind of top-to-bottom search for a surface spawnable spot as environmental spawning. However, this part only kicks in if the game first fails to find a spawnable spot around the village near the village's own Y-level:

1. The game first looks within 32-56 blocks horizontal and 18 blocks vertical of the village center for a spawnable spot. (The vertical range of was tweaked in 1.16.200.51 beta; it used to be 16 blocks.)

2. If step (1) fails, then the game searches from the top of the world downward for a spot within a 32x32 horizontal square around the village's horizontal center.

We cannot overwrite the vanilla spawn groups with a behavior pack to test changing the rules in them. In the absence of a conclusive test, it seems probable to me that the those files are being used at the points in the raid wave spawning algorithm that match what they state.

(Note: everything I'm stating here is based on extensive testing by myself or others. I've seen some code-digging done on raid spawning but the results were pretty vague and only suggest the game uses several block search algorithms to check for spawnable locations and checks around 50 spots for each wave.)