Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DAMAGE_TYPE_BASE_WEAPON doesn't propogate if added in ResolveDeathAttackHook #1726

Open
pF-arQon opened this issue Jan 18, 2024 · 2 comments

Comments

@pF-arQon
Copy link

pF-arQon commented Jan 18, 2024

this:
static void s_ResolveDeathAttackHook( CNWSCreature *pThis, CNWSCreature *pTarget) { ... CNWSCombatAttackData *pAttackData = pThis->m_pcCombatRound->GetAttack(pThis->m_pcCombatRound->m_nCurrentAttack); pAttackData->m_nDamage[4] += 100; }
works fine, and adds 100 acid to each attack, as you'd expect, and likewise for every other index except [12], i.e. DAMAGE_TYPE_BASE_WEAPON. I'd expect / hope for that to be converted to the appropriate physical fields at some point in the chain, but it doesn't seem to be.

(No idea if the same applies to the SA hook - haven't had time to test that one).

@Daztek
Copy link
Member

Daztek commented Jan 18, 2024

It's not really a bug, BaseDamage gets overridden in CNWSCreature::ResolveDamage which runs some time after ResolveDeathAttack(), other damage types work because it adds to them instead.

@pF-arQon
Copy link
Author

Thanks. It's that inconsistency that bothers me, but if it's impractical to fix it then so be it. I do get that this is a lot earlier in the chain than people generally mess around with the damage part of an attack, but since DA is already "special" you have to catch it here if you want to change its behavior.

That being the case, it would have been nice to be able to modify the damage here so I can keep it all nicely contained in the DA hook rather than having to also hook Damage and carry the data over in locals. I may try just doing the BASE_WEAPON conversion here myself instead, but either way I think we're done with the behavior of this part unless someone wants to try fixing it, and given the potential dominoes from doing so that seems very unlikely. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants