Jump to content
View in the app

A better way to browse. Learn more.

Forge Forums

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Featured Replies

Posted

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.

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)).

  • Author

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 :P I'll wait a while and see if any new ideas are forthcoming, but reflection may indeed be the best bet in this scenario.

  • Author

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.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

Important Information

By using this site, you agree to our Terms of Use.

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.