Conversation
|
I don't mind exposing the damage source here but this doesn't solve the mentioned issue. |
oh.. i misread the issue then... the issue not talk about cases for the direct/causing entity? for that i suggest the damagesource for check all rather than change logic in the event or miss something? |
|
Not 100% sure what you mean, but I do agree with exposing the whole damage source. |
The lightning bolt is passed as the eventEntityDamager instead of the causing/directEntity in the vanilla damagesource, meaning you still can't retrieve the lightning bolt entity from it as it is now. |
Ahhh that thing again... The issue is the DamageSource not expose that and when DamaSource api comes to paper the definition was separate the vanilla from events then... Maybe can be good a method in damagesource for get that? or pass again the causing entity to the events but using the event method from the craftdamagesource? |
|
I don't think it should be exposed on the damage source which represent the vanilla object. But it would make sense for getAttacker to behave like the EntityDamageByEntityEvent so plugins can get both information. |
if the events implementation was in server its easy but for know just send the DamageSource and also the attacker again but using the event behaviour... |
fb7df77 to
6c277ee
Compare
|
I include a helper method in the CraftDamageSource for handle the same logic for get the damager used in other damage events (if is valid then in another PR can make the damage events use that helper method and not make the check of direct-event entity) |
no absolutely not
Close #13571 by adding the DamageSource to the Vehicle events related to damage for allow check more details for the damage rather than just the entity who cause the damage also change the Attacker passed to events for include the internal event damager used in a few places if exists.