Replies: 2 comments
-
Yeah, this sounds like a good idea for me. We can't just directly reuse PrepareItemCraftEvent because that event requires having an InventoryView which only exists with a "player" actually viewing the inventory. But we could have a supertype of that event that is also then fired for crafters that has everything else. |
Beta Was this translation helpful? Give feedback.
0 replies
-
There also needs to be a |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Is your feature request related to a problem?
Some of my plugins crafting logic depends on PrepareItemCraftEvent and affecting the result. Because crafter does not invoke that event and has no special events they break my crafting plugins
Describe the solution you'd like.
Either include crafter in PrepareItemCraftEvent or create new event for crafter that inherits on the same base as PrepareItemCraftEvent. (My main concern is to not have double implementation for crafters)
Describe alternatives you've considered.
Probably interacting with crafter invokes inventory events, I haven't looked into this yet, but I could probably listen to some eventory click event check the crafter inventory and fabricate PrepareItemCraftEvent (crafter inventory i bare bone but I excpect that inside there is at least 10 elements array when 10th element is the result)
But this won't work perfectly as there are many inventory based entry points (player, hoppers, usage of crafter) that might change the state of result item and it would be great to have one common point when paper looks recipes for crafter
Other
No response
Beta Was this translation helpful? Give feedback.
All reactions