Paper
Paper copied to clipboard
PaperMC
Add PlayerAttackEntityEvent
Adds an event that allows people to cancel the actual attack from a player. This is useful as it currently allows you to cancel the sound that is played when attacking a player.
Canceling player attacks with the entity damage entity event: https://user-images.githubusercontent.com/23108066/190920900-38c05a4b-980d-4935-b7ed-aad8777469bb.mp4
Canceling player attacks with this event: https://user-images.githubusercontent.com/23108066/190920880-fc6a057b-ab03-4329-91fd-78adfd5f0f89.mp4 Note: Particles are client side
This is a pretty niche event, but it's just supposed to be much higher up to cancel as much logic as possible.
Just interested: Does this event gets fired when player attacks..
falling_blockentity?armor_standentity with invulnerable: true in survival?
I think event could be more useful if it was earlier (probably warrants it having a different name). Maybe in ServerGamePacketListenerImpl#handleInteract
The server currently does know when a player attacks a falling block, but not event is fired for that.
I think event could be more useful if it was earlier (probably warrants it having a different name). Maybe in ServerGamePacketListenerImpl#handleInteract
The server currently does know when a player attacks a falling block, but not event is fired for that.
I was thinking of doing something like that but it being cancelled by default… but I know that cancelled events being executed is already a huge meh in the API.
Would it be okay to execute it as cancelled by default then? I'm not sure what to 100% do with that.
firing as cancelled is pretty much a norm, personally I generally prefer to err on adding a state field of some form to the packet which reflects that better, i.e. "will this even actually induce the thing you'd think it does"
So how does a “willAttack” method or something that’ll return FALSE for entities like falling sand sound?
Cause yeah, I see what you mean.
Alright, should be good! Another thing, should I still allow you to set canceled to false for entities that normally aren't attackable? I just worry it might cause weird things for stuff like falling blocks, but if this is the behavior we want to support sure.
It's nuanced, last I came with this was the dismount stuff in which I ended up just adding a boolean to the event which would make setCancelled be ignored
For new events, we can define what we wanna do here; idk what the side effects are but it's generally between either babying developers or giving them the free reign to determine what they wanna do, I generally tilt more towards the former when there isn't a huge argument for allowing otherwise
It's nuanced, last I came with this was the dismount stuff in which I ended up just adding a boolean to the event which would make setCancelled be ignored
For new events, we can define what we wanna do here; idk what the side effects are but it's generally between either babying developers or giving them the free reign to determine what they wanna do, I generally tilt more towards the former when there isn't a huge argument for allowing otherwise
Yeah, then so I'll probably keep it so they can't modify setCancelled with certain entities. Does that seem fine?
@lynxplay What about PrePlayerAttackEntityEvent or something?
And how does this sound? "Note: there may be other factors (invulnerability, etc) that will prevent this entity from being attacked that this event will not cover"
This would be added to willAttack too.
The API is not really consistent with the naming here.
Both forms exist PreSpawnerSpawnEvent, PreCreatureSpawnEvent.
As well as AsyncPlayerPreLoginEvent.
Presumably just a personal preference, tho one I agree with, PlayerPreAttackEntityEvent just reads worse in my very subjective opinion. However as both names convey the same fact, this is fine.
