| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
Otherwise the text will be garbled (reversed and probably cut short).
|
|
|
|
|
|
This brings in proper fight outcome detection, which is nice and needed
for downstream applications (raidgrep/ezau).
Furthermore, this cleans up the CM detection a bit by moving away from
the "descriptive" trigger way to just having dynamically dispatched
methods for every log.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This was only there to make it easier to gradually implement the outcome
method for the individual bosses. Now that each boss has a proper
outcome, we no longer need the default method - in fact, I'd rather make
sure the compiler tells us if we forget to implement this method in a
new analyzer.
|
|
|
|
|
|
Otherwise, this would only return Nikare, and not Kenut.
|
|
|
|
|
|
|
|
It turns out that `was_rewarded` is a pretty bad heuristic if you ever
kill a boss a second time per week (basically, was_rewarded=false does
not imply that the boss was unsuccessful). Therefore, we need a proper
detection of when a fight failed and when a fight succeeded.
This is the first batch that implements this as part of the Analyzer
trait for bosses of wings 1 to 4.
|
|
You can run it with
cargo run --example=loginfo -- path/to/log
|
|
It turns out that the different encounters do require quite some
encounter-specific logic, not only to determine whether the CM was
activated, but also to determine whether the fight was successful, the
duration of the fight, later the phases, ...
Wrapping all of this in pre-defined "triggers" (like CmTrigger) feels
like it will be a bit unfitting, so with this patch we have introduced
the evtclib::Analyzer, which can be used to analyze the fights.
Currently, the whole CM detection logic has been moved to this new
interface, and soon we also want the success-detection logic in there.
The tests pass and the interface of Log::is_cm is unchanged.
|
|
|
|
|
|
|
|
|
|
|
