aboutsummaryrefslogtreecommitdiff
path: root/src/analyzers
AgeCommit message (Collapse)Author
2022-04-20add support for Aetherblade Hideout Challenge MoteDaniel Schadt
2022-03-31EoD strikes: implement Dragonvoid analyzerDaniel Schadt
2022-03-31EoD strikes: implement Minister Li analyzerDaniel Schadt
2022-03-31EoD strikes: implement Ankka analyzerDaniel Schadt
2022-03-31EoD strikes: implement Captain Mai Trin analyzerDaniel Schadt
2022-03-09add Boss/Encounter for new EoD strikesDaniel Schadt
2021-11-22add Twisted CastleDaniel Schadt
There's not many useful things we can do with this log, other than providing a way for downstream applications to identify those logs.
2021-11-18switch order of operands in SH analyzerDaniel Schadt
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
2021-11-16Add Statues of GrenthDaniel Schadt
2021-11-13Implement the River of Souls encounterDaniel Schadt
2021-11-13add bandit trio encounter & boss IDsDaniel Schadt
2021-11-12Add kitty golem encounters from the training areaDaniel Schadt
2020-09-29return Outcome::Success if a raid was rewardedDaniel Schadt
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.
2020-09-28rename Log::npcs to Log::charactersDaniel Schadt
2020-09-28fix formattingDaniel Schadt
2020-09-23re-introduce BossDaniel Schadt
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.
2020-09-23rename Boss to EncounterDaniel Schadt
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.
2020-09-23use Log::is_boss instead of manually checkingDaniel Schadt
2020-09-23fix lintsDaniel Schadt
2020-09-23add Sunqua Peak/Ai ID and analyzer logicDaniel Schadt
2020-09-21fix CM detection for new Skorvald logsDaniel Schadt
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
2020-08-28remove leftover debug outputDaniel Schadt
Since downstream applications will also print this, we should remove it.
2020-07-24more documentationDaniel Schadt
2020-07-23more documentation & adjustmentsDaniel Schadt
2020-07-23remove default implementation of Analyzer::outcomeDaniel Schadt
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.
2020-07-23implement strike AnalyzersDaniel Schadt
2020-07-23implement Analyzer::outcome for fractalsDaniel Schadt
2020-07-23implement Analyzer::outcome for wing 7Daniel Schadt
2020-07-23implement Analyzer::outcome for wing 6Daniel Schadt
2020-07-23implement Analyzer::outcome for wing 5Daniel Schadt
2020-07-23implement proper outcome for w1-w4Daniel Schadt
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.
2020-06-28start implementing analyzersDaniel Schadt
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.
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-22 09:42:45 +0000