Skip to content

fix: Prevent vine growth on the same block if vine-grow is false - #4930

Open
CAG2Mark wants to merge 2 commits into
IntellectualSites:mainfrom
CAG2Mark:fix/fix-vine-growth
Open

fix: Prevent vine growth on the same block if vine-grow is false#4930
CAG2Mark wants to merge 2 commits into
IntellectualSites:mainfrom
CAG2Mark:fix/fix-vine-growth

Conversation

@CAG2Mark

@CAG2Mark CAG2Mark commented Sep 1, 2026

Copy link
Copy Markdown

Overview

Prevents vines from growing on the same block if the vine-grow flag is set to false.

Description

A single vine placed in a 1x1x1 hole can spread to all available faces in that hole, and this triggers BlockGrowEvent instead of BlockSpreadEvent. This PR checks for vine growth that is fired under BlockGrowEvent. Note that vines spreading to another block is still handled under BlockSpreadEvent, a subclass of BlockGrowEvent, and this is handled separately from BlockFormEvent (see line 415 in BlockEventListener.java).

Submitter Checklist

  • Make sure you are opening from a topic branch (/feature/fix/docs/ branch (right side)) and not your main branch.
  • Ensure that the pull request title represents the desired changelog entry.
  • New public fields and methods are annotated with @since TODO.
    • Q: Do new listeners need this annotation?
  • I read and followed the contribution guidelines.

@CAG2Mark
CAG2Mark requested a review from a team as a code owner September 1, 2026 13:14
@EventHandler(priority = EventPriority.HIGHEST, ignoreCancelled = true)
public void onBlockGrow(BlockGrowEvent event) {
if (event instanceof BlockFormEvent) {
return; // handled below

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would be fine with handling all growth types of vines under this event handler and removing the vine checks from BlockSpreadEvent. Feels cleaner than keeping vine spread logic in multiple places imo

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems this doesn't work. The BlockSpreadEvent doesn't appear to trigger handlers for BlockGrowEvent (despite the former being the latter's superclass). Vines would spread to other blocks in my testing when only handling BlockGrowEvent.

if (plot == null) {
return;
}
switch (event.getBlock().getType().toString()) {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we only handle vines in this handler we could potentially think about moving the material check to the top (we don't really do that currently, but that checks is most certainly cheaper than getting the plot area and plot - especially for such a potentially high frequency event)

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In principle, this check could be moved to the top for the other handlers too, but it might be a bit less clean

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No longer relevant as I've moved the code to onGrow, which was already used for crop handling.

return;
}
switch (event.getBlock().getType().toString()) {
case "VINE":

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current handler for the VineGrowthFlag handles more than just vines, so if the other handler gets removed (1st comment) this should contain all types (currently this makes sense as no other type should be able to grow in a single block space)

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No longer relevant as per my comment here: #4930 (comment)

return;
}
switch (event.getBlock().getType().toString()) {
case "VINE":

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And is there any reason for using the enum name instead of the field? (would only make sense if there were any material renames in our specific supported version range)

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know. I just followed what was done in the other handlers for consistency.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Enum names were used due to compatibility issues with older versions of Minecraft. Given vines have been around for over 10 years, we don't need to use the string version of the enum.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Resolved in c00c1b9.

Block block = event.getBlock();
Location location = BukkitUtil.adapt(block.getLocation());
if (location.isPlotRoad()) {
event.setCancelled(true);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should check road-flags, no? Unsure in this case tbh, as the default flag value is true I think, which would be unexpected for roads...

@CAG2Mark CAG2Mark Sep 1, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All the other related handlers seem to do the same check as this, so I don't know.

@CAG2Mark

CAG2Mark commented Sep 1, 2026

Copy link
Copy Markdown
Author

Ah, I didn't see there is already a handler for BlockGrowEvent, oops...

EDIT: It seems CropGrowFlag prevents the described vine growth behaviour, see onGrow. I think this would count as a bug. Perhaps we should just rework onGrow?

@CAG2Mark

CAG2Mark commented Sep 5, 2026

Copy link
Copy Markdown
Author

Please see my comments as they contain some information. Still not sure what to do about road flags (and it seems many of the other handlers don't deal with this anyway, or maybe it is implicitly handled somehow, not sure)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants