Vaan/fix/copper blocks axes

[Intybyte]

Fixes pylonmc/pylon-core#528

[Seggan]

IMO this should be a default behavior and then allow overriding per-block

[LordIdra]

Agree with Seggan - maybe a PylonCopperWaxable or something, and then this logic can go in a listener

[Intybyte]

Agree with Seggan - maybe a PylonCopperWaxable or something, and then this logic can go in a listener

we already have a listener for that, why have 2 listener that do the same thing when it might create small problems, like which one gets called first, I agree on the idea of it being the default behaviour, but maybe we should just cancel the event as a default implementation of PylonInteractBlock

[LordIdra]

Agree with Seggan - maybe a PylonCopperWaxable or something, and then this logic can go in a listener

we already have a listener for that, why have 2 listener that do the same thing when it might create small problems, like which one gets called first, I agree on the idea of it being the default behaviour, but maybe we should just cancel the event as a default implementation of PylonInteractBlock

Confused. Where's the current listener?

[Intybyte]

Agree with Seggan - maybe a PylonCopperWaxable or something, and then this logic can go in a listener

we already have a listener for that, why have 2 listener that do the same thing when it might create small problems, like which one gets called first, I agree on the idea of it being the default behaviour, but maybe we should just cancel the event as a default implementation of PylonInteractBlock

Confused. Where's the current listener?

meant to say that we can use the PylonInteractBlock handler listener and cancel the event by default

[Seggan]

Orrr.... we can ignore this and just let stuff be waxable by default

[LordIdra]

meant to say that we can use the PylonInteractBlock handler listener and cancel the event by default

This doesn't really feel intuitive to me tbh. If a pylon block is a hopper, I don't think that the default behaviour should be to cancel the interact event and force implementing blocks to then override and manually open the hopper interface.

I would just suggest solving it by creating an interface PylonUnwaxable or something (in core) that cancels all wax events using the logic you've added to PylonCopperInteractBlock. I would use a separate listener rather than overriding PylonInteractBlock (I think most other similar bits of logic do this). That shouldn't be too much work, it's just slightly reorganising what you've got already.

[Intybyte]

meant to say that we can use the PylonInteractBlock handler listener and cancel the event by default

This doesn't really feel intuitive to me tbh. If a pylon block is a hopper, I don't think that the default behaviour should be to cancel the interact event and force implementing blocks to then override and manually open the hopper interface.

I would just suggest solving it by creating an interface PylonUnwaxable or something (in core) that cancels all wax events using the logic you've added to PylonCopperInteractBlock. I would use a separate listener rather than overriding PylonInteractBlock (I think most other similar bits of logic do this). That shouldn't be too much work, it's just slightly reorganising what you've got already.

Maybe not called PylonUnwaxable, as you can also remove rust if you wanted to and the interaction is the same, it seems useless to me having another event that does the exact same thing that interact does, and only creates confusion if both are implemented imo, one interface should interact with one event, it has always been like this, and I see no reason to change that now for this small edge case

[LordIdra]

I don't see the issue? Why is having two interfaces for an event a problem? Surely this lets us control unwaxing much easier? In another world BlockUnwaxEvent could exist, the distinction between events is a little bit arbitrary here so I wouldn't just not do it because it requires two interfaces that listen to the same event

[Intybyte]

I don't see the issue? Why is having two interfaces for an event a problem? Surely this lets us control unwaxing much easier? In another world BlockUnwaxEvent could exist, the distinction between events is a little bit arbitrary here so I wouldn't just not do it because it requires two interfaces that listen to the same event

It is a problem because

• now 2 distinct methods now contain how the even is handled, and you might need to check both
• you have no idea which one is executed first
• it proves 0 benefits having another interface, i have no idea what makes you say "control unwaxing much easier"
• it breaks the general expectation of one event getting handled by one interface, which has been true for each interface of this type, which in my opinion is problematic

[LordIdra]

OK let's recap:

• Right now, you have PylonCopperInteractBlock, which (slightly misleading) disallows any 'copper-based' interactions (i.e. waxing or unwaxing).
• Me and Seggan are suggesting to do the opposite and disallow waxing by default unless PylonCopperInteractBlock is implemented, because it just makes a lot more sense that way round
• Doing this would require you to cancel waxing events by default, hence why a separate listener is needed
• Then, you could change PylonCopperInteractBlock to have no methods and just be a marker interface. Then add a check in that listener so that it does not cancel the event is PylonCopperInteractBlock is implemented by the involved block

Does that make sense now?