Pedro

Let's suppose we have 3 villagers meeting all the conditions for panic summon a golem. The memory of last seen golem is about to expire and it's the begining of tick when it get's summoned, all 3 memories are 1 and the flow is the following:

• Brain#tick(world, villagerA) is called

• Executes Brain#tickMemories() -> villagerA memory gets decresed by 1, meaning last seen memories is 0 now

• Then it executes Brain#updateTasks(world, villagerA) -> here, the condition is met, iron golem get's summoned and all 3 memories are reset to 600 (VillagerEntity#summonGolem rewrites all the memories of the 3 villagers)

• Brain#tick(world, villagerA) is over: villagerA, villagerB and villagerC memory is 600

• Brain#tick(world, villagerB) is called

• Executes Brain#tickMemories() -> villagerB memory gets decresed by 1, meaning last seen memories is 599 now

• Brain#updateTasks(world, villagerB) -> task fails because iron golem got summoned and the memory is not 0

• Brain#tick(world, villagerB) is over: villagerA and VillagerC is 600, villagerB memory is 599

• Brain#tick(world, villagerC) is called

• Executes Brain#tickMemories() -> villagerC memory gets decresed by 1, meaning last seen memories is 599 now

• Brain#updateTasks(world, villagerC) -> task fails because iron golem got summoned and the memory is not 0

• Brain#tick(world, villagerC) is over: villagerA memory is 600, villagerB and VillagerC memory is 599

This flow causes a desync in the memory between the 3 villagers, so when the next time that a villager can spawn a golem because its memory is 0, it can't because the others are on 1s

This is my theory I could made a mistake. I'm attaching a screenshot of my observations: This is the end of next tick after the golem spawned 

I do agree with ampolive, looks like the correct way is the one on 1.19 and the extra 100 ticks is not an intended behavior. When I get a free time I’ll try to dig further into it, something is off 

I compared the Brain class of 1.18.2 and 1.19, the method tickMemories() on 1.18.2 calls memory.tick() first and then memory.isExpired() and on 1.19 is the othey way around,  memory.isExpired() first and then memory.tick(). So the information on the video is accurate.

(These are names are from the Fabric mappings, actual names may be different)

Forcing to call memory.tick() first and then memory.isExpired() on 1.19 (Using Fabric's mixins) I get a constant Iron Golem every 600 ticks or 30 seconds (assuming spawn attempt succeded) like we used to.

I tested this issue with carpetmod's /tick freeze/step and /ai_tracker.

Effectively, villagers are missing the spawning window by just 1 tick, making us having to wait for another 100 ticks to get the golem to spawn.

I think this issue should be reopened, I tested it on stable 1.18.2.3 and 1.18.20.23 and the mob dies at the same time compared to regular camp fire. I'm attaching proof

build height Y=320 is for placing blocks, not flying Y limit

It does not happen with a bed, but with a chest. If a chest is placed and then waterlogged, the texture dissapears.

Affects 1.17.0.54

Affects 1.17.0.54

Also happens with copper, both variants. Just 1 piece of raw copper with fortune 3 pickaxe. Win 10

All my minecoins went missing

Same happened to me. I want my money back now

@@unknown they have told you what is not true multiple times, ask them to get informed.

If this is parity with Java, villagers should as well hold the discount forever

Its been 13 months, when will this be high priority?

affects 1.16.100.51

still affects 1.16.100.51

A workaround if you want to bring back the 54 max spawn distance by patching the Linux 1.16.20.03 dedicated server while this gets fixed:

printf '\x36' | dd of=bedrock_server-1.16.20.03 bs=1 seek=$((0x000000000E4060E4 + 0)) conv=notrunc
printf '\x36' | dd of=bedrock_server-1.16.20.03 bs=1 seek=$((0x000000000C714E3E + 3)) conv=notrunc
printf '\x36' | dd of=bedrock_server-1.16.20.03 bs=1 seek=$((0x000000000C714E45 + 3)) conv=notrunc
printf '\x36' | dd of=bedrock_server-1.16.20.03 bs=1 seek=$((0x000000000C714F27 + 3)) conv=notrunc
printf '\x36' | dd of=bedrock_server-1.16.20.03 bs=1 seek=$((0x000000000C714F2E + 3)) conv=notrunc

Thanks you. I created a new ticket for this MCPE-95568

I'd like to request this ticket to be re-opened because the release 1.16.20.03 that dropped today have r44 on all simulation distance, when the patch notes indicates its for sim. 4

To test what im saying:

1. Create a flat word

2. Repeat command block with: execute @e[type=creeper] ~~~ setblock ~ ~-1 ~ concrete 0

3. From the above block -> chain command block with: kill @e[type=creeper]

4. Repeat command block: kill @e[type=!creeper]

5. Afk and check that nothing spawns beyond r44