🐛 [Bug Report] [TBC] Attack Power mods with negative value (debuff) cause zero total Attack Power for Player #3872
Labels
Expansion: TBC (2.4.3)
Issues relating to the TBC Expansion (2.4.3).
Info: Needs Replication
Issue needs replication before further action.
System: Player Data
saved stats, items, achievements, queststatus
System: Spells
e.g. spell scripting, spell editing, and missing spells
Comments
CyberBarr
added
the
Info: Needs Replication
|
I don't think this is ultimately the correct solution. The UNIT_FIELD_ATTACK_POWER_MODS should never ever be set to a negative value, so instead we should investigate why/if that occurs. |
|
Try with this: diff --git a/src/game/Entities/Unit.cpp b/src/game/Entities/Unit.cpp
index cd79cac70..622515ff1 100644
--- a/src/game/Entities/Unit.cpp
+++ b/src/game/Entities/Unit.cpp
@@ -9437,6 +9437,7 @@ bool Unit::HandleStatModifier(UnitMods unitMod, UnitModifierType modifierType, f
if (modifierType == TOTAL_VALUE)
{
auto sign = amount > 0 ? AttackPowerModSign::MOD_SIGN_POS : AttackPowerModSign::MOD_SIGN_NEG;
+ amount = std::abs(amount);
if (unitMod == UNIT_MOD_ATTACK_POWER)
m_attackPowerMod[size_t(AttackPowerMod::MELEE_ATTACK_POWER)][size_t(sign)] += apply ? amount : -amount;
else if (unitMod == UNIT_MOD_ATTACK_POWER_RANGED) |
|
I agree about it not being a negative value. The proposed solution is likely sub-optimal but it worked as a hotfix for my case. Edit: I should have clarified, I was unaware of the potential downstream impacts of removing the negative signage, specifically being unaware about usage of |
|
I just checked and you're correct, the number should be negative. my change is incorrect. Correct would be instead int32 ap = GetInt32Value(UNIT_FIELD_ATTACK_POWER) + GetUInt16Value(UNIT_FIELD_ATTACK_POWER_MODS, 0) + static_cast<int16>(GetUInt16Value(UNIT_FIELD_ATTACK_POWER_MODS, 1)); |
1 task
insunaa
added
System: Player Data
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug Details
In TBC core, UNIT_FIELD_ATTACK_POWER_MODS field is set as a signed 16 bit integer within Player::UpdateAttackPowerAndDamage(bool ranged) within StatSystem.cpp.
SetInt16Value(index_mod, 1, m_attackPowerMod[size_t(mod)][size_t(AttackPowerModSign::MOD_SIGN_NEG)]); // m_attackPowerMod is a 2-D floating point arrayThe field value is ONLY ever retrieved once and as an unsigned 16 bit integer in Unit::GetTotalAttackPowerValue(WeaponAttackType attType) within Unit.cpp. The resulting outcome is integer overflow whenever a debuff/negative attack power mod is applied to a Player. When applied, the Player's total attack power value becomes 0.
int32 ap = GetInt32Value(UNIT_FIELD_ATTACK_POWER) + GetUInt16Value(UNIT_FIELD_ATTACK_POWER_MODS, 0) - GetUInt16Value(UNIT_FIELD_ATTACK_POWER_MODS, 1); // overflow results in subtracting a large positive 16 bit integer valueSteps to Reproduce
Expected behavior
DPS on Player's in-game stat interface is exactly reduced to weapon damage amount. Damage done by the Player is reduced more than it should be while a negative mod is active.
Suggested Workaround
Add the following function within Object.h:
int16 GetInt16Value(uint16 index, uint8 offset) const { MANGOS_ASSERT(index < m_valuesCount || PrintIndexError(index, false)); MANGOS_ASSERT(offset < 2); return *(((int16*)&m_uint32Values[index]) + offset); }Change the following:
int32 ap = GetInt32Value(UNIT_FIELD_ATTACK_POWER) + GetUInt16Value(UNIT_FIELD_ATTACK_POWER_MODS, 0) - GetUInt16Value(UNIT_FIELD_ATTACK_POWER_MODS, 1);to:
int32 ap = GetInt32Value(UNIT_FIELD_ATTACK_POWER) + GetUInt16Value(UNIT_FIELD_ATTACK_POWER_MODS, 0) + GetInt16Value(UNIT_FIELD_ATTACK_POWER_MODS, 1); // addition of the stored (as negative) valueCrash Log
No fault occurs.
Core SHA1 Commit Hash
a9c89d6
Database SHA1 Commit Hash
0caae67b319ae0e31e256eb7edd3e784d127249a
Operating System
Windows 10
Client Version
2.4.3 (The Burning Crusade)
The text was updated successfully, but these errors were encountered: