| 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 turns out that arcDPS gives each boon stack an ID which is also
re-used in the BuffRemoval or StackReset events.
|
|
As it turns out, the padding bytes are not just padding, but for some
events they contain useful information. Therefore, we've adjusted the
parser to save those bytes (if available).
|
|
|
|
|
|
|
|
When this function was written, it was done under the assumption that
a) There are not a lot of agents, so linear search is fast enough
and
b) We just want it to work for now
However, it turns out that there can be a lot of agents, close to 1000
for the Qadim log for example. This means that there is quite some time
saving that we can do here, as get_agent_by_addr is used a lot in
set_agent_awares and set_agent_masters, so speeding this part up is
good!
We could build a HashMap, mapping the address to the agent (index), but
that would mean that we have to carry the hash map around. This patch
provides a simpler yet already good improvement: We invest a bit of time
after converting all agents to sort them by their address (as the agent
order is implementation defined anyway), so we can later use a binary
search to get the right agent. It's not O(1), as a hash map would be,
but it works in logarithmic time and already provides a big benefit:
Before
process Qadim time: [39.444 ms 39.501 ms 39.561 ms]
After
process Qadim time: [18.699 ms 18.744 ms 18.788 ms]
change: [-52.672% -52.546% -52.413%] (p = 0.00 < 0.05)
That is half of the processing time saved by a 3 line patch!
|
|
No particular reason other than it's more idiomatic and shorter.
inline has been added to get_agent_by_addr since it "feels" like a short
function that can and should be inlined, but it doesn't matter too much.
|
|
|
|
This adds some simple benchmarks to test the speed of
evtclib::process_{file,stream}, just so we can quickly assess on a
high-level if changes make a big impact.
I'd like to add some more benchmarks in the future as well, mostly
- on the higher level when we go from RawEvtc to a log, benchmarking the
process function itself (thus not benchmarking all the byte-twiddling
deserialization code).
- on the Analyzer level
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
Just like with Event, we now have Agent defined in its own submodule.
The amount of code that it entailed was a lot, so it made sense to split
it off, especially with the deserialization being another big chunk of
Agent related code in lib.rs
The main issue was that the processing submodule accessed private fields
of the Agent struct, which is now no longer possible (since processing
is no longer a submodule of the module in which Agent is defined).
Therefore, some simple crate-public setters for those fields have been
added. Those setters are not public because we do not want outside
crates to mess with the innards of Agent (yet).
Although with (de)serialization being a thing, we need to ensure that we
can handle nonsensical values anyway, since we can no longer guarantee
that we have full control over all of the values, even without setters.
|
|
The rationale is included in the comment below. The gist is that we want
to avoid deserializing Agent<Player> (and others) directly, as that
would circumvent the checks.
As a small bonus, we now skip the phantom_data field in serialization,
as that's just an implementation detail that other consumers shouldn't
worry about.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Those functions can be used to simplify the special case handling that
was done in lib.rs on encounters that have multiple bosses.
|
|
This is now the enum that contains the IDs of the single bosses, like
Nikare and Kenut. This means we can do away with the NIKARE_ID and such.
The enum is not publicly re-exported, as we re-export Encounter (which
is more of a replacement of the old Boss).
Special casing still remains (mostly in lib.rs), but we should be able
to do away with this now with a more general Encounter::bosses and
Boss::encounter methods.
|
|
This is the first step in differentiating between Encounters and Bosses.
It sounds a bit weird at first, but there are some events without any
bosses (like the River of Souls), and some events which have multiple
bosses (like Twin Largos or the kodan strike mission). If we want to
support this better, without relying on extra IDs, special casing and
constants (like NIKARE_ID), we should differentiate between Encounters
and Bosses.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
