| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Might be nice to have it readable in the documentation, not just the
source!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The EoD elite specs and strikes are not fully implemented yet, but
delaying this release until they are would be a bit silly. After all,
the old version cannot parse any log that has a new elite spec in it.
Therefore, 0.7.0 shall be released with EoD elite spec support, so that
downstream applications can be updated.
We can always improve the EoD strike situation and implement proper
analyzers later. As far as I can tell, Elite-Insights also does not
parse them correctly just yet.
|
|
Dragonvoid is one of those weird bosses which consists of multiple
characters(?) that are structures and not even "normal" characters(??).
The first ID we used seemed to not catch the actual logs that are now
generated using an up-to-date arcDPS.
I'm not sure if the old ID was necessarily wrong, but for some reason,
it doesn't seem to match the actual ID that is currently used to log
this fight.
|
|
|
|
Many thanks to xyoz & neko for providing me with suitable log files!
|
|
This is the one thing that prevents evtclib from parsing new logs, as we
can handle unknown bosses, but no unknown elite specs.
|
|
|
|
There's not many useful things we can do with this log, other than
providing a way for downstream applications to identify those logs.
|
|
Cargo will complain if the benchmarks that are defined in Cargo.toml are
not found, so we need to include the sources - even if the benchmark
itself cannot be run from the cargo package (due to the missing test
logs).
|
|
|
|
|
|
|
|
With a new release being on the way (and long overdue), it's time to get
the CHANGELOG up to date with what actually happened since v0.5.0.
|
|
There are two reasons for this:
First, we want to implement new events (and arcdps might add new events
themselves) without having to release a new major version. Adding enum
variants is usually a breaking change, because match blocks have to be
adjusted to keep every variant included. This is the same reason why we
made Encounter and Boss non-exhaustive as well.
Secondly, the usual modus operandi is not to iterate through all events
and do something for every event kind that you find, but rather to
iterate through the events and look for the events that you find
interesting. This means that most often, you will use a match with a
"do-nothing" catch-all, an if-let or a matches!() anyway, in which case
this change does not affect the code in a good or bad way.
|
|
|
|
It is way cheaper to retrieve the correct agent first (especially with
the faster agent_by_addr) and then check if it is a boss, rather than
iterating over all bosses (which iterates through all characters), and
then iterate through the found bosses to check if any address matches.
The new code is a bit longer (and doesn't combine the functions as
nicely), but it is still readable and more performant - which is more
important.
|
|
We know that the way we construct the Log, the agents are always sorted
by their address. This invariant cannot be broken, as the only way to
construct a Log is in evtclib itself, and there is no way to obtain a
mutable view on the agent vector or change the address of an agent.
Since Log::agent_by_addr is used by other functions, this speedup (even
if it is small) can show in a lot of different places.
Note that if we change the interface of Log in the future to allow
creating logs from different sources that processing::process, we need
to make sure we adjust this function.
|
|
Comparing the int is a very cheap operation, and it is also a very good
indicator already that we've found the right event. Due to the short
circuiting behaviour of &&, it is better to check that first before
doing the Log::is_boss check - which is relatively costly. Remember that
we do this check for every buff application event!
This brings a speedup of around 50x:
new: 654.1±25.18µs
old: 34.9±0.69ms
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This may be useful for downstream applications and it fits into the
pattern of implementing it for Boss/Encounter.
|
|
If we already have an Encounter, it might be nice to determine the game
mode from it as well - without needing to go through the whole log
first.
This is especially useful for raidgrep, where we can use the early
filters - which don't have access to the whole Log item.
|
|
For a lot of applications, it can be useful to distinguish between logs
made in raids, fractals, ...
Note that we probably don't want further categorization (as for example
done in ezau).
|
|
|
|
|
|
|
|
|
|
|
|
|
