Open benjajaja opened 8 years ago
Does anything prevent that list from being modified? Alternatively, allow plant growth to be cancelled per plant.
I don't have a good feeling modifying that list, events should be one-way and cancelled at most. But on the other hands, it's common to e.g. modify a BreakBlockEvent's drop list...
Can't in good conscience cancel all the growth in a chunk simply because of the presence of a single demarkated area. Whether you or I write something that allows finer grain control, it'll need doing.
So let Contraptions modify the list, and RB read it back later?
That's one option; allow for list removals and RB will only "grow" the plants that remain on the list after the event is fired. Alternatively, whatever element is in the list has a flag -- "cancelled" -- and events can safely set that flag, instructing RB to either grow or ignore a particular plant. That's probably the most "bukkit-like" approach, allowing higher priority plugins to supercede earlier plugins based on Bukkit's event handler ordering.
Ok, that sounds at least tad safer than removing items from the list.
Whenever a persistent plant grows on chunk load, fire a
PersistenceGrowth
event (per chunk). Can be cancelled, if cancelled then RB will not attempt to grow blocks in any way. The event contains: Array of plants:To be used by https://github.com/ProgrammerDan/Contraptions/tree/reboot. A contraption may cancel the event and e.g. place drops as items into a container.
@ProgrammerDan You see we have a small problem here with contraptions' markers is that markers define a volume which does not match entire chunks, but RB must handle plant growth on chunk load. It shouldn't fire one event per plant either.