DPSMeterFix : Combat Mods : Elder Scrolls Online AddOns

(3 Kb)

Download

Updated: 07/05/22 03:31 AM

Add Favorite

Install Help

Compatibility:	High Isle (8.0.0)
Updated:	07/05/22 03:31 AM
Created:	07/04/22 05:37 PM
Monthly downloads:	75
Total downloads:	3,195
Favorites:	1
MD5:

DPSMeterFix

Version: 0.1.1

by: voidbiscuit [More]

Easiest fix as provided by code65536 in the comments for this addon:

COMBAT_MECHANIC_FLAGS_INVALID = 0

The affected function is ZO_TargetDummyLog_Manager:HandleCombatEvent
found in esoui/esoui/ingame/combatlogs/targetdummylog.lua

This addon, my own fix, checks another parameter to provide the same result, but doesn't tackle the core reason the code broke in the first place.

Optional Files (0)

Comment Options

07/19/22, 08:02 PM
code65536 Forum posts: 21 File comments: 374 Uploads: 40	/script d(COMBAT_MECHANIC_FLAGS_INVALID) now returns 0 instead of nil, so ZOS's official fix here is just defining the undefined constant.

07/18/22, 06:56 AM
Qcell Forum posts: 0 File comments: 50 Uploads: 5	On today's incremental: Fixed an issue that caused training dummies to report inflated DPS values. Last edited by Qcell : 07/18/22 at 06:57 AM.

07/06/22, 10:37 AM

code65536

Forum posts: 21

File comments: 374

Uploads: 40

Originally Posted by Baertram

Is this something we should ask ZOs to change in their code, at the Wishlist forum?

It's been reported as a bug on the ESO forums and ZOS has acknowledged it there. I expect it wouldn't take long for them to investigate and come to the same conclusion.

07/06/22, 01:59 AM

Baertram

Super Moderator

Forum posts: 4971

File comments: 6037

Uploads: 78

Is this something we should ask ZOs to change in their code, at the Wishlist forum?

Originally Posted by code65536

I think a much easier fix is to just define the following global variable:

Code:

COMBAT_MECHANIC_FLAGS_INVALID = 0

So what's going on here is that ZOS just went through and did a blind search-and-replace of the old "POWERTYPE_" constants into the new "COMBAT_MECHANIC_FLAGS_". Which mostly works. Except here.

Why does it not work here? Because COMBAT_MECHANIC_FLAGS_INVALID is not defined anywhere. It's nil. So ZOS's code is now checking if the powerType field is ever undefined (and it never is), which is why this code broke.

So, why is COMBAT_MECHANIC_FLAGS_INVALID not defined? Because it makes no sense semantically. The old POWERTYPE_ constants were enumerations. The new COMBAT_MECHANIC_FLAGS_ are, as the name suggests, bitwise flags, that can be used in conjunction with each other to form a bitfield. They're 1, 2, 4, 8, 16, 32, 64, etc. And in this context, "invalid" doesn't make any semantic sense.

So the bug here is that ZOS tried to use an undefined COMBAT_MECHANIC_FLAGS_INVALID rather than just checking to make sure that the bitfield isn't 0. I guess if they don't want to have 0 in the code directly, they could define a COMBAT_MECHANIC_FLAGS_NONE as 0 and check against that (since for a bitfield, "none" makes semantic sense whereas "invalid" does not).

The variable naming from ZOS here is also a bit confusing. Checking the powerType field just makes sure that the hitValue isn't something like a time (for ACTION_RESULT_BEGIN or ACTION_RESULT_EFFECT_GAINED_DURATION, for example), and whether or not the ability is actually a damage ability (vs. a heal ability) is done naturally by way of the events being siloed by the target's unit ID.

Anyway, tl;dr: easier fix is to just define the undefined constant that ZOS tried to use.

Last edited by Baertram : 07/06/22 at 01:59 AM.

07/04/22, 06:56 PM
code65536 Forum posts: 21 File comments: 374 Uploads: 40	I think a much easier fix is to just define the following global variable: Code: COMBAT_MECHANIC_FLAGS_INVALID = 0 So what's going on here is that ZOS just went through and did a blind search-and-replace of the old "POWERTYPE_" constants into the new "COMBAT_MECHANIC_FLAGS_". Which mostly works. Except here. Why does it not work here? Because COMBAT_MECHANIC_FLAGS_INVALID is not defined anywhere. It's nil. So ZOS's code is now checking if the powerType field is ever undefined (and it never is), which is why this code broke. So, why is COMBAT_MECHANIC_FLAGS_INVALID not defined? Because it makes no sense semantically. The old POWERTYPE_ constants were enumerations. The new COMBAT_MECHANIC_FLAGS_ are, as the name suggests, bitwise flags, that can be used in conjunction with each other to form a bitfield. They're 1, 2, 4, 8, 16, 32, 64, etc. And in this context, "invalid" doesn't make any semantic sense. So the bug here is that ZOS tried to use an undefined COMBAT_MECHANIC_FLAGS_INVALID rather than just checking to make sure that the bitfield isn't 0. I guess if they don't want to have 0 in the code directly, they could define a COMBAT_MECHANIC_FLAGS_NONE as 0 and check against that (since for a bitfield, "none" makes semantic sense whereas "invalid" does not). The variable naming from ZOS here is also a bit confusing. Checking the powerType field just makes sure that the hitValue isn't something like a time (for ACTION_RESULT_BEGIN or ACTION_RESULT_EFFECT_GAINED_DURATION, for example), and whether or not the ability is actually a damage ability (vs. a heal ability) is done naturally by way of the events being siloed by the target's unit ID. Anyway, tl;dr: easier fix is to just define the undefined constant that ZOS tried to use. Last edited by code65536 : 07/04/22 at 11:33 PM.

Report this File