Anomie X

Since there never was a distinct bug here I am re-resolving this report as a duplicate.

This is incorrect. MC-92017 was about the damage direction being determined by the current location of the entity that was the (indirect) source of the damage, so you had to face towards that entity instead of towards the explosion to block. This bug was about certain kinds of explosions not having any associated entity and so being entirely unblockable.
 
On the other hand, you're correct both were fixed in 22w43a, when they added tracking of both the direct entity (e.g. the TNT) and the indirect entity (e.g. the player who ignited it) instead of only the latter, and also added a location to bed explosions that have no entity at all.

The situation does not seem to have changed from the behavior in 22w46a as described in #comment-1212161.

I can also reproduce this bug. The necessary conditions seem to be that there is more than one villager in the vicinity that has been traded with (i.e. it has a defined profession) and without a current job site or potential job site. When the appropriate jobsite block is then placed where multiple such villagers can path to it, one grabs it as a "potential job site", then it and one other will freeze, neither making any progress towards the jobsite or walking anywhere else.

The frozen villagers will still do other activities such as breeding or sleeping if they can do these without having to walk anywhere. Also, if a third villager meeting the conditions comes close to one of the two frozen villagers, it may take the place of the frozen villager that was farther away.

Looking at decompiled code, I think you may have introduced an error when refactoring YieldJobSite. Prior to 22w45a, the code in part looked like this:

protected boolean checkExtraStartConditions(ServerLevel serverLevel, Villager villager) {
        if (villager.isBaby()) {
            return false;
        }
        return villager.getVillagerData().getProfession() == VillagerProfession.NONE;
    }

In other words, the check returns true only if the villager is not a baby and has no current profession. The AI routine itself has that villager look for a nearby villager having the necessary profession but with no jobsite or potential jobsite, and gives its potential-jobsite claim to that villager.

The corresponding part of the new code looks like this

if (villager2.isBaby()) {
                return false;
            }
            if (villager2.getVillagerData().getProfession() == VillagerProfession.NONE) {
                return false;
            }

In other words, the check proceeds only if the villager is not a baby and does have a current profession. So a villager with the right profession will give its claim up to some other villager, who will then run the same routine to give it back (or pass it on to another, closer villager). And since the act of giving up the claim also clears the villager's walk destination, neither villager goes anywhere as they just trade the claim back and forth.

If I'm right the fix would be simple, just change that == to !=  to restore the prior logic.

No, that is entirely unrelated.

Looked into the cause of this, since I was confused why 22w46a lowered the light level for Skeletons, Wither Skeletons, and Endermen in the Nether from 11 to 7 but did not do so for  Zombified Piglins. I didn't see any light level check in ZombifiedPiglin.checkZombifiedPiglinSpawnRules(), which made it more confusing. As far as that method is concerned they should spawn in any light level.

It turns out it's the call to the generic mob.checkSpawnRules(). PathfinderMob overrides this to check for this.getWalkTargetValue(this.blockPosition(), levelAccessor) >= 0.0f, and Monster overrides that method to return a value based on light level that happens to be >= 0 for light levels <=11 but goes negative for light levels 12 to 15.

P.S. This same thing seems to be the cause for Blazes, Piglins, and Hoglins also requiring light level <=11 to spawn. Magma Cubes and Ghasts escape because they aren't subclasses of PathfinderMob, which is why they do manage to spawn in any light level.

Behavior is more predictable in 22w46a. The one remaining oddity I've noticed is that a hopper failing to draw from a non-empty bookshelf will reset the signal to indicate the last-filled slot.

This appears to be because the hopper technically takes each book, finds it can't actually put it into the hopper's inventory, and then reinserts it back into the bookshelf. The "reinsert" step changes the bookshelf's last-interacted slot.

This should be closed as Works as Intended. Villagers got smarter about handling inventories full of seeds and such to fix MC-74407.

I see this is currently closed as "Works as Intended". Is this really intended (and if so, can anyone point to an official Mojang statement to that effect), or is it really more of a "Won't Fix" because too many people would complain if this were fixed after so many years?

I've not seen shulkers get stuck in an open state. But I do see that any shulker that wasn't directly attacked (and didn't teleport after being hit by some other shulker's bullet) never "peeks", and is not alerted if another golem is spawned unless directly attacked.

this behavior can be observed after a shulker has finished being aggressive towards an entity.

I think that the problem here is that the stuck shulkers are not finished being aggressive towards the entity.

When a shulker is directly attacked, it starts running HurtByTargetGoal because its getLastHurtByMob() starts returning a non-null value. When that mob dies, LivingEntity.baseTick() clears the lastHurtByMob, HurtByTargetGoal ends, and the stop() it inherits from TargetGoal clears the target.

But for all the other shulkers that were alerted by HurtByTargetGoal.alertOthers(), nothing clears the target. ShulkerAttackGoal stops as soon as the target dies (when canUse() sees !livingEntity.isAlive()), but doesn't actually clear the target. Their own HurtByTargetGoal wasn't running, so that won't clear it either. And they don't run anything like NeutralMob.updatePersistentAnger that checks if the target is still alive, so no clearing there like we have for wolves or bees or zombified piglins.

The fact that teleporting "cures" an affected shulker is also suggestive, as teleportation does call setTarget(null). Same for logging out and back in or going far enough away that the shulker is unloaded and then returning, as those also effectively clear the target.

BTW, I note similar behavior from blazes: Spawn a bunch of blazes, then spawn a snow golem with 1 health. It'll attack one, and all of them will start attacking it until it dies. Summon a second snow golem, and only blazes that were directly attacked by the first golem (or are directly attacked by the new one) will be pack-angered, the rest will not be.

I took a look through decompiled code to try to see what's going on here.

When a shulker acquires a target, the ShulkerAttackGoal AI routine begins running. It's start() calls setRawPeekAmount(100) to open the shell, and the routine periodically shoots bullets. When the target is lost for whatever reason, its stop() calls setRawPeekAmount(0) to close the shell.

There's also the ShulkerPeekGoal AI routine, which runs randomly while the shulker has no target. It's start() calls setRawPeekAmount(30) to slightly open the shell, and when it ends (either 1–3 seconds later or when a target is acquired) it calls setRawPeekAmount(0) to close the shell again except when a target was acquired, presumably so as to not interfere with ShulkerAttackGoal having just started.

So far so good.

But in the shulker's setPos() and teleportSomewhere() methods also set the DATA_PEEK_ID value directly to 0, which causes the shell to close.

If setPos() is called for whatever reason while the ShulkerAttackGoal routine is active (e.g. push the shulker with a piston, or move it with a minecart), we get the result that the shell is closed but the shulker still shoots bullets. This state continues until the shulker manages to lose its target and ShulkerAttackGoal ends.

teleportSomewhere() is slightly better, as it also clears the target which should cause ShulkerAttackGoal to end. But it seems there's still a race condition here, if a target is reacquired before ShulkerAttackGoal is evaluated then it won't end and we get the same result as above.

I can think of a few ways this might be fixed:

1. Stop setting DATA_PEEK_ID in setPos() and teleportSomewhere(). Although I suspect that the reason they do is because it looks odd for an open shulker to teleport, so this may not be the best idea.

2. Have ShulkerAttackGoal's canContinueToUse() return false if the DATA_PEEK_ID value is no longer 100. This would make it stop, restoring a consistent state, and then restart right away. OTOH, that might break shulkers in moving minecarts from ever attacking, which may also be an undesirable behavior change.

3. Have ShulkerAttackGoal's tick() method re-call setRawPeekAmount(100) periodically, perhaps whenever it's about to shoot or perhaps whenever it finds the value has changed away from 100.

I suppose also of note is that sometimes it will do the "shift all books over" thing, e.g. on a save-reload cycle. Just not consistently.

Took a look at the code for this bug. I found that the Gossips data for a zombie villager is being saved, as a List (nbt type 9) of Compounds (nbt type 10), in the entities/r.x.z.mca file.

But the code for reading the Gossips data in `net.minecraft.world.entity.monster.ZombieVillager` does not read it back correctly. That code looks like this:

if (compoundTag.contains("Gossips", 10)) {
            this.gossips = compoundTag.getList("Gossips", 10);
        }

Or in English, "if it contains a Gossips tag that is a Compound, read a List of Compounds from it".

That code should look like this instead:

if (compoundTag.contains("Gossips", 9)) {
            this.gossips = compoundTag.getList("Gossips", 10);
        }

I think I see what's happening here, looking at decompiled code for Java 1.19.

1. net.minecraft.world.entity.monster.Enderman's teleport(double, double, double) looks for the first block from the target location (inclusive) down for one made of a movement-blocking material (.getMaterial().blocksMotion()).
2. If that block is not found or is waterlogged, it rejects the teleportation.
3. Otherwise, it calls randomTeleport(), which is inherited from net.minecraft.world.entity.LivingEntity. It passes the original target location, not the top of the block found, but the bug here would still occur anyway.
4. randomTeleport() looks for the first block below that target location that is movement blocking and tries to teleport there, failing if there's a collision.

The case described in the bug happens when a roof block itself (one with air or other non-movement-blocking material below) is selected as the teleport location. Steps 1 stops at the selected roof block itself, and that passes step 2. But step 3, which does the actual teleportation, finds the waterlogged block underneath the roof instead and teleports there.

Chances are the logic in step 1 should be changed to match that in step 3.

A workaround would be to make your roof blocks waterlogged.

I've managed to get screaming goats when breeding a normal goat and a screaming goat in the situation Skorpeyon described. I haven't tried finding a natually-spawned screamer.

Looking at the decompiled code for 1.19, in net.minecraft.world.entity.animal.goat.Goat I see that it chooses the type of the baby by looking at the type of the other parent. Most other animals that inherit a trait from one parent explicitly use this.random.nextBoolean() to select one of the parents. The one exception I noticed was for ownership of tamed wolves, for which the code always uses the this parent and the wiki says the baby's owner is always the same as the older parent.

Based on that, I did a little experimenting in Creative. Over a small number of trials, if I /summon the screamer second then the baby was always a screamer, while if I /summon the normal goat second the baby was always normal (I didn't do enough trials to really see the 2% chance).

So as a workaround, I'd suggest people try breeding their screamer with a normal goat that was spawned earlier than the screamer, rather than with one spawned later.

MC-15820 seems to be about (in MCP terms) the whole IChunkGenerator.populate() method not being called correctly. In this bug, populate() being called but MapGenEndCity.generateStructure() is deciding not to do its thing, because when the city data is loaded from EndCity.dat the MapGenEndCity.Start.isSizeable field isn't restored properly.

If I mod MapGenEndCity.Start to set this.isSizeable = true when loading the city data from EndCity.dat, I can no longer reproduce the bug with either method.

What I described is the same cause, with a different visible result (entire city missing instead of city only partially missing).

It's not MC-15820, the cause is different.

Here's another reproduction case that proves it's a different issue:

1. Create a world.

2. Go find some end cities.

3. Go back to the Overworld.

4. Close the world.

5. Delete the DIM1 folder from the save, to reset the end. Do not delete EndCity.dat.

6. Go back to the End and see that none of the cities you previously found generate.

7. Close the world.

8. Delete the DIM1 folder from the save, to reset the end, and also delete EndCity.dat this time.

9. Go back to the End and see that the cities you previously found generate again.

Please link to this comment by [Helper] Anomie X for a way to reproduce this

Don't bother, the situation in MC-96998 does not have the same cause as this bug.

Not a duplicate, the reproduction here has nothing to do with exiting the game while chunks are populating.

Duplicate of MC-1403, probably. Certainly of MC-103502.