[solved] Causing a different type of DamageSource when entity is hit

[coolAlias]

I'm making a skill that allows the player to charge up an attack and then strike, causing all of the normal sword damage but ignoring armor. I've considered many different ways of doing this, but all of them seem to require me to simulate (read 'copy / paste') significant portions of the vanilla attack code or are otherwise not good options.

 

Let me outline what I've considered:

1. In LivingHurtEvent, make a call to 'damageEntity' with a new, armor-ignoring DamageSource and either cancel the event or set the ammount to zero; Benefits: no adverse effect on any of the other attack calculations Problem is that 'damageEntity' is protected, so I'd have to copy / paste that code into my own method

 

2. somehow reassign the DamageSource in LivingAttackEvent; this would be ideal, but I don't think it's possible because the event's DamageSource field is 'final' (which makes perfect sense, but still )

 

3. cancel LivingAttackEvent and make a new call to attackEntityFrom with the new DamageSource; this one just no, the problems far outweigh any benefit that might be gained, since among other things this would cause 'attackEntityFrom' to return false in the player's 'attackTargetEntityWithCurrentItem' method mid-strike, but I still need that to return true for the rest of the calculation

 

Number '1' is currently my top option, but I thought I'd ask if anyone knows of a better way. Thanks for any ideas.

[GotoLink]

Not 2, of course.

You blasted out 3, so...1.

 

Though you can do the same with AttackEntityEvent and

attackTargetEntityWithCurrentItem

.

 

 

You don't need to copy anything by the way, reflection can Method#

invoke

(instance, params) even on protected methods (Method#setAccessible(true)).

[coolAlias]

Thanks for the reply. Yes, AttackEntityEvent could work, but if I'm not mistaken then once attackTargetEntityWithCurrentItem is called it's back to the same problem - getting it to use the new DamageSource - because attacking with the current item always causes 'player' damage.

 

As for reflection, yes, that thought crossed my mind, but it seems so dirty I'll wait a while and see if any new ideas are forthcoming, but reflection may indeed be the best bet in this scenario.

[coolAlias]

Ooooh, I never thought of adding a class to a vanilla package! I was trying to figure out how to make a wrapper like that, and all I could think of was making a class extend EntityLivingBase, which of course wouldn't help at all because none of the vanilla mobs would even use that class... Is it not considered taboo to add custom classes to vanilla packages? It's not editing any vanilla code, though, so I don't see why not

 

Anyway, that's a great idea! I've got my flag built in to the way the skill works, so the second event shouldn't be a problem. Thanks for the tip though.

[coolAlias]

That's just so damn sneaky So which would be considered dirtier, reflection or a foreign accessor class? I've managed to stay clear of both until now :-/

[coolAlias]

You, good sir, deserve a beer. That was the most clear and concise argument against reflection I have ever seen.