This repository was archived by the owner on Oct 11, 2026. It is now read-only.
Repository navigation
fix(analytics): compare each EI player entry against its own fight slice (4 503 → 1 116) - #120
Merged
Merged
Conversation
Elite Insights does not emit one entry per player. It emits one per contiguous stretch of squad membership: a player who leaves and rejoins the squad, or who is out of it before the recorder picks them up, appears several times under the same account and the same instance ID, with adjacent non-overlapping firstAware/lastAware windows and a different `group` on each. Every counter on an entry covers only that stretch. On `20260424-204954`, 34 entries cover 23 accounts, with `empiria.8961` split three ways at 3..11321 / 11322..137166 / 137167..254724. arcdps has no such notion -- one agent record spans the whole fight -- so the comparison was measuring each of those entries against the player's whole-fight totals. Every counter on every duplicated entry came out high, which is exactly why the per-target buckets dominated the report while `statsAll` looked healthy: the per-target arrays are per-entry too, so a 3-way split inflated 69 target rows at once. Each entry is now compared against the matching slice of the event stream, and the difference key carries the slice so entries under one account stop overwriting each other. The correlation is exact: the five logs with duplicated entries were the five worst in the corpus, and logs with no duplicates were already near-clean. Corpus: 4 503 -> 1 140 differences over 35 logs. 20260424-204954 2 202 -> 182 20260224-233019 674 -> 72 20260526-202841 503 -> 142 20260412-220632 280 -> 24 20260125-194936 198 -> 62 Buff uptimes and consumables are still computed whole-fight and need the same treatment; they are now the largest remaining buckets. Signed-off-by: Roddy <r.salardon@gmail.com> Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…it entries Follow-up to the slice fix. The obvious next step was to window buff uptimes the same way as the damage counters, and it is wrong: EI reports the same whole-fight buffUptimes on every entry of a split account. Measured on the four logs that have splits, restricting uptimes to the slice takes buff differences from 225 to 913. Two dead ends are worth recording so they are not retried: - subtracting two BuffStateTracker readings does not give the stack-time inside a window; the tracker only moves forward, so both readings taken after the full feed return the same final total; - replaying the tracker per window computes the window correctly and still diverges, because the target itself is whole-fight. Signed-off-by: Roddy <r.salardon@gmail.com> Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Consumables are pre-fight applications, and EI repeats the same list on every entry of a split account. Restricting them to the entry's window dropped them whenever a player's firstAware landed after the food or utility went up, which the slice change had just made possible. Corpus: 1 140 -> 1 116 differences; consumables 82 -> 58. Also tried and rejected: shifting our consumable timestamps by +1 ms. 39 mismatching entries are short by exactly 1, but most entries already agree, so the blanket shift takes consumables from 39 to 95 on the four logs that carry them. The remaining gap is a mix of that offset and entries we never emit, not one rule. Signed-off-by: Roddy <r.salardon@gmail.com> Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Roddygithub
force-pushed
the
fix/parser-ei-target-attribution
branch
from
August 4, 2026 14:26
dfc0531 to
a4dd6c4
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The bug
Elite Insights does not emit one entry per player. It emits one per contiguous
stretch of squad membership. A player who leaves and rejoins the squad — or
who is simply out of it before the recorder picks them up — appears several
times under the same account and the same instance ID, with adjacent,
non-overlapping
firstAware/lastAwarewindows and a differentgrouponeach. Every counter on an entry covers only that stretch.
On
20260424-204954, 34 entries cover 23 accounts.empiria.8961is splitthree ways:
arcdps has no such notion — one agent record spans the whole fight — so the
comparison was measuring each of those entries against the player's
whole-fight totals. That is why the per-target buckets dominated the report
while
statsAlllooked healthy: the per-target arrays are per-entry too, so athree-way split inflated 69 target rows at once.
The correlation is exact. The five logs with duplicated entries were the five
worst in the corpus; logs with no duplicates were already near-clean.
Result
4 503 → 1 116 differences over the 35-log corpus.
20260424-20495420260224-23301920260526-20284120260412-22063220260125-194936Two dead ends, recorded so they are not retried
whole-fight
buffUptimeson every entry of a split account; restricting themto the slice takes buff differences from 225 to 913 on the four logs that
have splits.
BuffStateTrackerreadings does not give the stack-timeinside a window. The tracker only moves forward, so both readings taken
after the full feed return the same final total. Replaying per window
computes the window correctly and still diverges, because the target is
whole-fight.
Remaining
rotation(424) andbuffUptimes(363) are now the two big buckets, followedby
consumables(58) and a long tail.BACKLOG.mdcarries the detail.Note the earlier "0 diffs corpus-wide" figure in #117/#118 was measured over 20
logs; the committed corpus is 35.
Verification
537 pytest, ruff, ruff format and mypy all clean.
🤖 Generated with Claude Code