Fruits

[benjajaja]

pumkins and melons' fruit growth is stored as extra field.

Keeping track of fruit growth is more expensive than crops:

• must track block break to start tracking a fruit's growth again after harvest (unlike crops which simply get replanted)
• must search for nearby stems on break
• a stem must search for both free spot and possibly existing fruit each time it's growth time is checked
• also tracks piston events for BUD auto farms (although internally a bit poor - plant may spawn, get removed from DB, then right after get broken by piston, then added again. a future contraption could improve this with better yield as incentive or something, if necessary.)

There is room for future improvements at Fruits.java as noted in comment.

---

Cactus and sugarcane will probably use the same principle, but won't need that much block checks, jsut the block above.
Trees don't need to track "fruits" since a sapling only grows once. But I want to move away both from magic-numbers/data-ids for tree types and make the internal [material/treetype/other?] to growthconfig map typesafer.

[ghost]

Needs a quick review and I'll merge. @ProgrammerDan @WildWeazel

Any volunteers?

[ProgrammerDan]

I don't see any obvious errors in the code, can't speak to the logic. Assuming it's a clean compile, I see no reason this can't go to testing unless @WildWeazel has a different opinion!

In any case it'd be great if gipsy wrote up a testing plan in anticipation of the merge; specifically: what changed, what stayed the same, and what testers need to do to activate all the prior.

[benjajaja]

will do, in discourse will be best I think

[ttk2]

ok to test