Minecraft: 1.8.9
Forge: 11.15.1.1808
Agricraft: 2.0.0a1

Carrot seeds, wheat seeds and potato seeds placed in Crops do not mature. Agricraft potato seeds and Agricraft carrot seeds placed in Tilled Soil without Crops render incorrectly and mature immediately. Status of other seeds unknown.

I am also having this issue. I believe the bug is in TileEntityCrop.setGrowthStage(int). Here are my observations:

1. Both plants and weeds do not grow unless bonemeal is applied.
2. Plants and weeds DO grow when bonemeal is applied.
3. When there are no plants in the crops, weeds can grow.
   • This means that BlockCrop.updateTick is being called.
4. If you bonemeal a weed to full growth and have it next to a crop with a plant, it can spread over the the plant and destroy it.
   • This means that CompatibilityHandler.allowGrowthTick in BlockCrop.updateTick is being reached and does return true.

So far, this COULD mean that the shouldGrow bool here might never be true, however, I doubt that's the case because:

1. If you bonemeal a plant to mature on a crop, then move it to another new crop, it will change to stage 0 for that plant.
2. If you then move a new plant (stage 0) to the crop where the plant from step 5 was mature, regardless of whether it's vanilla or not, the plant will immediately be mature.

This tells me that setting the stage of the crop for the trowel and regular growth have a similar problem. In fact, TileEntityCrop.onTrowelUsed calls the same method as TileEntityCrop.applyGrowthTick. However, if you compare it to TileEntityCrop.applyFertiliser (which we know works), we see we're using a different method for that.

When comparing the two methods that actually handle the state, TileEntityCrop.setGrowthStage and BlockCrop.grow, we see that the main difference is in the third parameter for World.setBlockState. BlockCrop.grow uses 2, while TileEntityCrop.setGrowthStage used 3.

// TileEntityCrop.setGrowthStage
this.worldObj.setBlockState(pos, state, 3);
//                                     ---

// BlockCrop.grow
world.setBlockState(pos, state.withProperty(AgriCraftProperties.GROWTHSTAGE, l), 2);
//                                                                              ---

This, however, is all conjecture as I've never written a mod before and don't know what the World.SetBlockState method does or what its parameters mean.

I don't have a dev environment ready to test this myself or I would have done it. But at least I hope this will help.

Also, this affects SP as well as MP in 1.8.9.

Good work in tracing that down, cheers.
That third parameter is indeed the key, it's a set of 3 bits that determine what must happen:
If the first bit is one, a block update is caused, if the second is one the change is sent to the client and if the third is one the block will not be rerendered.
So my guess is they are actually growing, but no block updates happen so you don't see them grow visually.

Interesting. So I'm guessing that when you pass in an integer you're passing in the index of the bit to be set to 1? I would have expected a method like this to turn the integer into its binary form (011 in this case), which would result in an update happening and a client update being sent. Unless we're talking about the bits from left to right as opposed of least to greatest? In either case, I think an enum or bitwise flag enum would make mod devs' lives easier. Does Java have flag enums? I'm mainly a .NET dev.

no you pass the value of the bits (0 = 000, 1 = 001, 2 = 010, 3 = 011, ... I think you get the point)
And yes java has enums, but I don't know what flag enums are.

You mean 1.9?

I'm not terrible sure anything matures at all atm...
It looks like the plants aren't getting growth ticks...

Oh... It looks like they might not even tick at all...

Oh... Duh. It was the fact that the object returned by state.withProperty() wasn't being saved back to state.

Well I have this fixed on the 1.8.9 branch, don't know if I should leave open so gets fixed in 1.9?

Yeah...

probably for the best yeah

Thank you both for your work on fixing this issue, and thank you Lao for tracking it down.

I hope that with both you mean @LaoArchAngel and @RlonRyan because I didn't do anything here.