Shulkers sometimes get stuck in their opened or closed states after being aggressive towards an entity

I just created my very first shulker farm, using RaysWorks newest design.  After a couple days of this running without issue, my snow golem disappeared, and at this time, every shulker in the farm refused to open or agro the new snow golem, even though the main one was agro'd.  I was able to bring the farm back to life by going to each "stuck" shulker so that it would agro me.  After I did this enough, they eventually killed off each other, and all newly spawned shulkers are working as intended.

A shulker that is group aggravated and its target dies by other means, does not group aggravate against a different target (but it aggravates against a player or directly attacking target just fine).

If you experienced an issue with that in cubikmetres or others farm design, it is because the target snow golem died, which would have eventually broken the farm anyway at some point (i assume that you have a dozen golems so you didn't notice that one died).

You can solve this issue by making sure that your golem doesn't die and is properly enclosed. Place a few more blocks around it and its fine.

When it is about a portal farm like in the video, i assume that you ended up with multiple bullets in your chamber, one hit the shulker and duplicated it and the other hit the new shulker and aggravated it towards the previous shulker which teleported into the nether and is not around anymore. Therefor the target is set (which deactivates regular PeekGoal) but it isn't around (so no peeking caused by ShootBulletGoal). This would be a problem in your farm anyway and you would have to fix the cause rather than asking for an AI change. One possible solution is to make the shulker extend through lava which shields the new shulker - which isn't extended on spawning - from a second bullet that would still be around. Same with scaffolding.

And when a shulker is in a minecart, it doesn't extend, but can still fire bullets. When a shulker is sitting on a block where it can't stay and tries to teleport away (but can't, cause its a killing chamber of your farm) it also can't start the PeekGoal (which is the regular opening, not the 100% opening when it is aggravated).... if you do not like this behaviour, consider building your killing chamber so that the shulker is sitting on a valid block for it to stay... it is not a good idea to have a shulker try to teleport away 5 times per tick, 100 times per second, anyway.

Edit: I assume that the PeekGoal can't be started in that case because it would mean that you could force a shulker to open into another block. The canStay requirement makes sure that it has room to open, and just happens to have the side effect that it now also can't open when sitting on, in example, SoulSand in an environment where it can't tp away.

We are talking about three different mostly unrelated things here.

Messing around and changing revenge AI (it isn't shulker specific code) would potentially break more farms than it fixes.

I would label this WAI.

Yeeun this is a very interesting analysis, thankyou for clarifying. I will point out that my breeding chambers never lose snow golems, I have run modules which only have a single golem and I never lose the golem however I can quite often lose the shulker due to this glitch regardless. Your point about the shulker bullets from the previous shulker remaining in the chamber and aggitating the shulker against a target that does not exist makes a lot of sense. I simply wasn't aware that shulkers would aggro on eachother this way. Also your points about the shulker becoming glitched this way due to being in a minecart or being in a space which does not allow them to open their shell is quite consistent with my observations. With my most recent shulker farm design I had issues with shulkers in minecarts getting aggro from modules as the shulker is carted through the farm to the module which needs a shulker replaced. This also seems to affect shulker reactors where shulker replacement should not be necessary in theory, however in practice the group aggro mechanic for the shulkers can cause a lot of problems.

By the sounds of things, this glitch can be mostly fixed if shulkers would not aggro on eachother, if the shulkers are to behave using a pack mentality, then it does not make sense for them to attack eachother if they accidentally catch eachother in the crossfire. A good example would be pillagers who do not turn on eachother if they accidentally hit eachother, because it rather defeats the purpose to have a pack mentality if they just attack eachother.

Just wrote a comment about how to reproduce the shulker-buggy-and-stays-closed behaviour by group aggravating it and then pushed the target into a portal... but i realized that it goes a bit deeper into the group aggro stuff than i expected.

I don't want group-aggro mechanic to change, so i will just aggree wth cubicmetre that not having shulkers aggro at each other - which leads to weird happenings, including shulkers at the end cities themselves eradicating each other - would be the best soluton.

>> A shulker that is group aggravated and its target dies by other means, does not group aggravate against a different target

Why would you not want this to change? It doesn't make sense to reject new targets when the old target doesn't exist anymore. Any mob that "doesn't get the kill" would suddenly stop helping against new threats. Mobs are abandoning the group because the group succeeds. I don't see how that could possibly be intended behaviour.

I am able to confirm this behavior in both 1.18.1 and 22w05a.

I've done some thorough and careful testing regarding this problem and have discovered some things. As indeed described in this report, and as mentioned in the comments above already, this behavior can be observed after a shulker has finished being aggressive towards an entity. For some reason, their shells will remain open or closed and they'll no longer naturally peek (naturally open and close their shells every once in a while).

Below, I've rewritten this ticket to include these details and have provided a reliable method on how to go about reproducing this.

The Bug:

Shulkers sometimes get stuck in their opened or closed states after being aggressive towards an entity.

Steps to Reproduce:

• Build the setup as shown in the attachment below.

• Using spawn eggs, spawn shulkers on top of every diamond block within the setup.

• Stand on top of the gold block and spawn an iron golem with a low amount of health.

/summon minecraft:iron_golem ~ ~ ~ {Health:1f}

• Wait for the iron golem to be killed by the shulkers.

• Observe the behavior of all the shulkers for around thirty seconds.

• Take note as to whether or not most shulkers sometimes get stuck in their opened or closed states after being aggressive towards an entity.

Observed Behavior:

Shulkers sometimes get stuck in their opened or closed states after being aggressive towards an entity.

Expected Behavior:

Shulkers would not get stuck in their opened or closed states and would naturally peek as normal.

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.