search

baaron4 / GW2-Elite-Insights-Parser

Binary parser for the .evtc files that arcdps generates after a boss encounter. This will generate a .html file where the results can be easily reviewed.
MIT License
130 stars 47 forks source link

WVW JSON logs produce odd players>combatReplayData>dc starting with version 2.48.0.0 #675

Closed Drevarr closed 1 year ago

Drevarr commented 1 year ago

Describe the bug Starting with version 2.48.0.0 wvw json logs have a combatReplayData>dc entry for all players. Appears to be max integer value.

Screenshots image

IMPORTANT: Provide Files Add the EVTC and/or HTML of the log related to this issue 20221205-230253_detailed_wvw_kill.zip

Drevarr commented 1 year ago

Likely related. one down state, two death states. image

EliphasNUIT commented 1 year ago

Hello,

What is the problem you are encountering? You have stated the appearance of additional values, what is the issue?

Drevarr commented 1 year ago

The change broke downstream code based on my assumption of combatReplayData . Working around it with player>defenses>dcCount, dcDuration.

What does the negative dc value and offsetting death value represent?

EliphasNUIT commented 1 year ago

The arrays in CombatReplay are for deciding how to represent the given Agent, if time in dc => do not draw, if time in down => show as downed, if time in dead => show as dead, otherwise show as normal. The extra padding has been added in order to avoid mis-representing the Agent by indicating the last known status and the first status. In your 2nd image you can see the CR data ends at 32681 while the final state is "dead" which ends at 32499, which means you'd assume the Agent is alive between 32499 and 32681 but that would be wrong. The extra paddings are here to indicate that the final state has not changed.

You can use this data in order to compute dead duration, dc duration, down duration, but not how many times a player got downed for example, for that you should always use "defenses" as this state array does not indicate stuff like vapor form. However, even before this change, you should always sum the content as follow, assume you wish to measure duration in a specific phase, that starts in phaseStart and end in phaseEnd: sum{max(min(phaseEnd, array[i][1]) - max(phaseStart, array[i][0], 0} It was never guaranteed that the time values in those arrays would be between 0 and EncounterEnd, on the contrary, more often than not, it was not the case but I guess you noticed it when you got some crazy values. For example, on current, if you get downed or die during Xera/Deimos pre events, you'll naturally get negative time values. The formula I've given is actually how I compute downDuration, deadDuration and dcDuration, so doing it yourself is kinda rendundant unless you wish to compute it on a custom time interval.

Drevarr commented 1 year ago

Thanks for the clarification and detailed response. Will adjust accordingly.