Skip to content

Add Throw EntityChangeBlockEvent for BrushableBlockEntity#brush#12133

Merged
Owen1212055 merged 4 commits into
PaperMC:mainfrom
Y2Kwastaken:fixes/12132
Apr 30, 2025
Merged

Add Throw EntityChangeBlockEvent for BrushableBlockEntity#brush#12133
Owen1212055 merged 4 commits into
PaperMC:mainfrom
Y2Kwastaken:fixes/12132

Conversation

@Y2Kwastaken
Copy link
Copy Markdown
Contributor

@Y2Kwastaken Y2Kwastaken commented Feb 17, 2025

This Pull Request adds calls for EntityChangeBlockEvent for BrushableBlockEntities. This allows for the increased tracking described in #12132.

This warrants further testing due to the fact that the point where the loot table is unpacked at could cause issues, however, I was unable to notice anything significant during my testing. Input for this aspect is appreciated.

@Y2Kwastaken Y2Kwastaken requested a review from a team as a code owner February 17, 2025 02:37
Copy link
Copy Markdown
Contributor

@lynxplay lynxplay left a comment

Choose a reason for hiding this comment

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

The event calls are too late right now.
Right now, the block would drop its content even if people cancelled the change event.
It would also unpack its loottable, which, that modifies the block.

We need to move the unpacking down, dropContent calls it so, I think we can just move it right before the block set when a completion state changed (needs testing).
But yea, cancelling these events should maintain the block in the same state (not drop items/unpack loot tables).

@Y2Kwastaken
Copy link
Copy Markdown
Contributor Author

It would also unpack its loottable, which, that modifies the block.

Ran into this now the loot should only be unpacked after the first permitted brush Cancelling the event should not persist the state.
image

We need to move the unpacking down, dropContent calls

I moved these down as well and it seems to be working as intended to me.

I did some more playing around with the event and wasn't able to change the state after cancelling as intended using the vanilla brushing behavior. The patch needs a bit of cleaning up, but I'll leave it as is for now to see if this is what we will go with before I do that.

@lynxplay
Copy link
Copy Markdown
Contributor

Mhmmm, I did not even think about the brushCount, good catch.
This makes this entire block a lot more difficult, but yea, I think this is the way to go forward (shuffling).
The client should be perfectly fine and we still unpack the loottable on the first brush (the first brush count moves from 0 to 1 in completion stage)

Event is still not fully cancelling the "last" and final brush tho, the game event is still called and the brushCount is not reset either.

@lynxplay lynxplay force-pushed the fixes/12132 branch 2 times, most recently from 328a870 to c614a20 Compare February 17, 2025 23:59
@lynxplay
Copy link
Copy Markdown
Contributor

769de10 might be a separate solution, not gonna push over yet because I am too tired.
Will review tomorrow.

@lynxplay lynxplay force-pushed the fixes/12132 branch 2 times, most recently from 769de10 to 86138f6 Compare February 21, 2025 11:05
@github-project-automation github-project-automation Bot moved this from PR Party candidate to Awaiting final testing in Paper PR Queue Apr 30, 2025
@github-project-automation github-project-automation Bot moved this from PR Party candidate to Awaiting final testing in Paper PR Queue Apr 30, 2025
@Owen1212055 Owen1212055 merged commit 2754d7c into PaperMC:main Apr 30, 2025
3 checks passed
@github-project-automation github-project-automation Bot moved this from Awaiting final testing to Merged in Paper PR Queue Apr 30, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Merged

Development

Successfully merging this pull request may close these issues.

4 participants