| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
There's not many useful things we can do with this log, other than
providing a way for downstream applications to identify those logs.
|
|
|
|
|
|
|
|
|
|
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.
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
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.
|
|
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.
|
