Age | Commit message (Collapse) | Author |
|
The old code seemed to choke on WvW players, as the subgroup-calculating
code did 0 - b'0', which underflowed. The proper way to parse a subgroup
is not to take a single character anyway, because subgroups can be
bigger than 10.
The new code fixes that by properly extracting the "subgroup str
literal" and then parsing it as an integer, with some special logic to
detect an "empty" subgroup as it is in WvW.
|
|
|
|
|
|
It makes sense to expose this logic as a function, as other programs
like raidgrep might want to use the same logic when dealing with partial
evtc files.
|
|
If the reward has been given out, we can be 99.9% sure that the fight
succeeded, in which case we don't need to do any other convuluted
checking. This has the benefit of catching some false-negatives (edge
cases in success detection), at the cost of making the detection a bit
... weirder, in the sense that a log's success might now depend on
whether it was the first kill in the week or not.
However, given that our sucess detection works pretty well overall, I'd
say it's worth to catch a few more false-negatives and try to classify
as many logs correctly as possible. At least, this does not introduce
any false-positives.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The Sunqua Peak patch released on 2020-09-15 shifted fractals around
(notably moving the old CMs to 98 & 99), which messed with the boss
health in those fractals. As a result, the Skorvald CM detection (which
relied on the health of Skorvald being higher in CM) was broken.
This patch introduces a fallback mechanism which relies on the
split-phase anomalies, as those are still different in the CM. It should
be 100% accurate, as long as players actually make it to the split
phase. Before that, we currently have to assume that the fight is
non-CM, even if it's a log from a CM wiping before first split phase.
There is some discussion in the Elite-Insights Discord here[1] about
this change.
[1]: https://discordapp.com/channels/456611641526845473/718866714527399976/755914037354692648
|
|
|
|
|
|
|
|
Since downstream applications will also print this, we should remove it.
|
|
|
|
|
|
Otherwise the text will be garbled (reversed and probably cut short).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|