Yann

After some code analysis, this issue comes from HopperComponent::pullInItems.
The method fetch entities around the hopper, but only tries to take the first item of the list.
It should try all items of the list until addItem returns true.

Fixed in 1.16.

I found a village that generates with only one villager.
So it's not "empty", but I wouldn't consider this as normal either :

Seed : -27149278
Coords : -2929 -3335

Here is how the current POI scanning system work :

 - Each villager request the village manager to scan 32x8x32 area around the block it is on
 - Village manager has a LIFO (last in firt out) where it stores scan requests
 - A request can only be submitted once (if it's in the list it's not added anymore)
 - A request is only processed, and removed from the list if a player is in the same region (I believe 512x512 around the block)
 - The LIFO max size is 64
 - Each query is splitted in 8 (1024 blocks scanned), to do so, the village manager only stores the position where it stopped scanning, not the request its processing.

This can lead to multiple situations :

1/ DDOS
 - A village with a lot of villagers is loaded (lets say a trading hall with 70 villagers)
 - Take a nether portal (at this point the LIFO is full, and requests aren't being processed anymore)
 - Go to another place, at least 512 blocks out, using the nether, and try to do stuff with villagers. The LIFO is full so the villagers will not be able to query for POI.

This can also happen if you are on multiplayer and if a player logout in its trading hall.

This situation can also happen in the same simulation distance, a lot of villagers in one place can prevent one from linking if it's not in their scanning area.

2/ POI Scan expansion (infinite amount of block scanned)
 - A village with some villagers is loaded (ie 0,0).
 - The village manager start scanning for a POI on x - z, it does the first part of the splitted query
 - The player go to the nether  (+x +z coordonates, ie 50000,50000)
 - The player go to the overworld and load an other village thousands of blocks away.
 - The loaded villagers add queries in the LIFO, setting the end of the current query to those new coordonates
 - The village manager goes from the last position it was scanning and continues, (from 0,0 to 50000,50000).

This can cause villagers to take a lot of time to find their POI. Especially on multiplayer worlds where multiple villages are loaded at the same time and requests overwritting the previous one all the time.

The only solution for the player is currently reloading the world or reseting/crashing realms.

For the devs, theeses could be fixed this way : 
 - using a FIFO (first in first out) instead of a LIFO.
 - dropping requests when a player is not around.
 - if you dropped a requets, reset the internal state of the Village Manager regarding last block scanned.

The limit of 64 could still be an issue for large multiplayer worlds, since there is a race condition in being accepted in the list, some villagers could never be added to it and never link.

The fact that villagers always link in the same order is actually a pretty usefull and easy mechanic to use.

Villagers will unlink from their beds at night and possibly reset the village.
To prevent unlinking, always keep one villager with access to their beds.
If all beds are removed by the player, the village is removed and poi will be scrambled.

All of that is how village mechanics works.

However sometimes, they don't link at all, and that's a bug.

Composter never accepted bamboo.

Growth is not defined by behaviour packs. You can search them there is nothing about kelp in there.

Are you it made the release ? Kelp seems to grow faster on the 1.15 beta. Even though it suffers from the same 'stop growing' issue.

Hi, nothing changed in the code regarding kelp in 1.14.30

Should we open a new ticket "kelp sometimes doesn't grow even with it's age < 23" then?
It's the same issue, the rates are bad because the kelp stops growing randomly, and not because of its age.
And a kelp plant that you can't bonemeal will never grow.

Still applies in 1.14.30 and 1.15.0.51 beta.
The situation is explained in length in this video : https://youtu.be/3Fdy93XXC9U

While I like the fact that the initial explosion don't break obsidian anymore.

In the beta, blue skulls don't break obsidian anymore.
And the wither is supposed to be able to break all blocks around it when it takes damage, including obsidian.

After growth the original kelp block age is unchanged.

It's easy to get a world with kelp with an age < 23 that doesn't grow even with randomtickspeed at 4096.

It uses the same random generator the game uses everywhere.

I think it has to do with the pendingTick fix they made to remove kelp to fill up a chunk with pending ticks.

I'm also pretty sure they didn't change anything in 1.14.30 and it's just miscommunication.

Can you share your testing protocol ?

I tested this :

Make a 16x25x16 water tank.
Plant kelp
increase randomtickspeed to ~1000, so that it doesn't take ages.
Kelp barely grows higher than 2 blocks.
If the age system was working properly growth should be equaly distributed in height (0-25).

They changed the age system to that the max is 23 (was 15 before), and the 14% chance of growth in 1.14 (was 1 before). Parity isn't always a good thing.
It's not listed in the changelog but they did. This alone would reduce significantly growth rate, but it's not the only issue.

When kelp grow, the new kelp block has the age of kelp block below it +1.
The original kelp block doesn't incease its age (you can check in the block data of chunks).
So technically if you break the kelp block above it it should be able to grow again, which is the expected behaviour. But for some other reason, it stops growing.

This is still affecting 1.14.30 release.
Simple and easy to check, make a kelp field and push randomtickspeed to 4096, admire very little to no kelp growth...

I've looked at the code, and there is a method called fetchClosestVillage in the VillageManager class that is used to distribute poi and villagers amongst villages.
The fact that you can't find that it's the closest village that is used, is because this particular method is bugged. Note that there  is a limit to join a village of 96 on x-z and 38 on y.

To go into the specific of this bug, the methods computes the euclidian distance between a villager/poi and a village centers.
Since 1.13, it substract the "approximateRadius" which for square villages resumes as (x/2+z/2)*0.6, so roughly 38.4 blocks for a standard 64x64 village.
This gives a floating point value that is negative when you are less than 38.4 blocks away from a village in a sphere.

The error in the code is casting this negative floating point to an unsigned integer, which results in undefined behaviour in C++.
On Arm devices, results is 0, on x86 devices it's (2^64)-1-value).

Of course rates will be slower from java because it's random tick based. And if they keep the parity, it will be always slower unless you setup your random tick speed to 3 to match java's.

But it's very easy to make a test where kelp is not growing. and it's age is nowhere near 26.
Getting the age of the kelp is a bit tricky because it's in the block data part of the chunk nbt data.
I would assume it's a collateral of the pendingTick bug they "fixed".

They changed the aging system to have parity with Java.
So each time a kelp block is ticked there is 14% chance for it to grow if it hasn't reached the max age.
Pre-1.14 there was 100% chance for it to grow, so it should be ~4x slower than before.

However, sometimes the kelp, just stops at random age, this is the real bug.

Steps to reproduce :
 - Create an empty world
 - Make a water column
 - Plant kelp on the bottom

 - raise random tick speed to 4096 (kelp plant should grow at least twice per second)
 - wait a few seconds
 - look at nbt data of the chunk to check kelp age.

Chunk borders and sub chunk borders don't transfer light level sometimes.
If you go in an ocean and place a sealantern at y=64.
Unload the chunk reload it, the top face of the sea lantern will have light level = 0

And mobs will spawn on them.

I've only noticed this since 1.13, so it may be another bug.

The only work around for that is having minecraft on windows.

Or find someone that has it and that you can trust with your account password to get the worlds and send it to you. I wouldn't recommend it. But at this point...

Hi,

The world if from a realm. The earliest back up I have of this is June.

The world I uploaded is truncated, I removed nether/end and reduced the overworld, the original file is 500MB and backups are larger. I'm not sure how I could make them available to you.

Are piston arm collision in the same chunk ?
I don't believe there ever where pistons in that chunk.
There was invisible chests too. I broke them before crashing the realm.