add item_pre_anvil event

[Lildirt]

Kind of flying blind with creating a new event. It's been many years since I've written one, in an extension. 😂
Let me know if there's any validation you'd like for me to do on my end.

Example payload (pretty printed):

event_type: item_pre_anvil
first_item: {meta: {damage: 0, display: null, enchants: {silk_touch: {elevel: 1}, unbreaking: {elevel: 3}}, flags: {}, lore: null, model: null, modifiers: null, repair: 0, tags: null, unbreakable: false}, name: DIAMOND_PICKAXE, qty: 1}
item_repair_cost: 10
level_repair_cost: 10
macrotype: inventory
max_repair_cost: 40
result: {meta: {damage: 0, display: null, enchants: {efficiency: {elevel: 4}, silk_touch: {elevel: 1}, unbreaking: {elevel: 3}}, flags: {}, lore: null, model: null, modifiers: null, repair: 1, tags: null, unbreakable: false}, name: DIAMOND_PICKAXE, qty: 1}
second_item: {meta: {damage: 0, display: null, enchants: {efficiency: {elevel: 4}, unbreaking: {elevel: 3}}, flags: {}, lore: null, model: null, modifiers: null, repair: 0, tags: null, unbreakable: false}, name: DIAMOND_PICKAXE, qty: 1}
viewers: {Lildirt}

[Pieter12345]

Quick review without having compiled or executed the code. It looks like you were successful at sticking to the project structure! Thanks for contributing :)

[Pieter12345]

I believe that this should call getRepairCostAmount() instead.

[Lildirt]

Indeed it should! Updated.

[Pieter12345]

What is this override doing here?

[Lildirt]

Uh, nothing. Actually, that entire getInventory() definition doesn't need to exist. It's defined in MCInventoryEvent. Removed it.

[Pieter12345]

I would word this as all players viewing this anvil's interface or something similar that is a bit more explicit.

[Lildirt]

Verbage updated.

[Pieter12345]

I would word this as:
the first ingredient in the anvil recipy
the second ingredient in the anvil recipy
the result of the anvil recipy
Or something alike. Again a bit more explicit, leaving less room for misinterpretation (what is the result of an anvil?).

[Lildirt]

Verbage updated.

[Pieter12345]

Java now has a nice language feature that you can use here.

if(event instanceof MCPrepareAnvilEvent) {
    MCPrepareAnvilEvent e = (MCPrepareAnvilEvent) event;

is equivalent to:

if(event instanceof MCPrepareAnvilEvent e) {

It's up to you to decide whether or not you want to use that, but it's been used more and more in CH.

[Lildirt]

Sure! I've updated it to use the short-hand.

[PseudoKnight]

Looks like you matched 'viewers' from item_pre_craft, whereas we should probably get a player for both of these from the InventoryView. I don't think there can be multiple viewers, at least for these events on these GUIs. I would recommend removing 'viewers' and add 'player' for this event.

There's one hitch. InventoryView was changed from an abstract class to an interface a couple of weeks ago. Directly using methods from that interface may not work on older versions of the server. Might need reflection. Something like:

	@Override
	public MCHumanEntity getPlayer() {
		return new BukkitMCHumanEntity(ReflectionUtils.invokeMethod(e.getView(), "getPlayer"));
	}

[PseudoKnight]

Let me test the other event to see if reflection is needed here too. [edit] Confirmed. Needs reflection.

[PseudoKnight]

Actually can probably just do e.getViewers.get(0) instead of reflection. That's probably the way to go.

[Lildirt]

Actually can probably just do e.getViewers.get(0) instead of reflection. That's probably the way to go.

Pushed a commit. Something like that?

[PseudoKnight]

That looks fine. It looks impossible to have more than one viewer for an anvil. Unlike shared inventory views, the list of tracked viewers of an anvil is created every time a call to open an anvil is used.

[PseudoKnight]

Just noticed you have question marks in the description of the repair costs. Perhaps they were temporary?