evtclib/src/analyzers, branch v0.5.0 arcdps EVTC reading/parsing library for Rust return Outcome::Success if a raid was rewarded 2020-09-29T15:25:26+00:00 Daniel Schadt kingdread@gmx.de 2020-09-29T15:23:01+00:00 65bd385540db567751405df000f6b063226d8b8a 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. 
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.
rename Log::npcs to Log::characters 2020-09-28T11:32:54+00:00 Daniel Schadt kingdread@gmx.de 2020-09-28T11:32:54+00:00 b50febe63e8d72b396feac4b67f55fbc52c03dae 






fix formatting
2020-09-28T11:19:50+00:00

Daniel Schadt
kingdread@gmx.de

2020-09-28T11:19:50+00:00

4be9a3bac6fda057e5c95f605c320bec2a278e68












re-introduce Boss
2020-09-23T13:41:53+00:00

Daniel Schadt
kingdread@gmx.de

2020-09-23T13:40:52+00:00

14b6a38e61b2e7b6d3d21a350283b3ec60a757ea

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 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.







rename Boss to Encounter
2020-09-23T13:23:55+00:00

Daniel Schadt
kingdread@gmx.de

2020-09-23T13:22:55+00:00

39972d54be41bfc7b8b7f38b1f5a4d60e2453da5

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 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.







use Log::is_boss instead of manually checking
2020-09-23T12:53:38+00:00

Daniel Schadt
kingdread@gmx.de

2020-09-23T12:53:38+00:00

69da697e4f77504e4042da07f4f5c26b2e8a16f9












fix lints
2020-09-23T12:50:44+00:00

Daniel Schadt
kingdread@gmx.de

2020-09-23T12:50:44+00:00

8330abd3d42aadc30d1d819c9486c1341b4244c9












add Sunqua Peak/Ai ID and analyzer logic
2020-09-23T12:33:03+00:00

Daniel Schadt
kingdread@gmx.de

2020-09-23T12:33:03+00:00

de0601a5a4fd6f0e7aa3a357fc5c6926d8bfca4b












fix CM detection for new Skorvald logs
2020-09-21T10:31:15+00:00

Daniel Schadt
kingdread@gmx.de

2020-09-21T10:24:35+00:00

dd015d3b3640fed0885fd94db78def42531b47d5

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





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







remove leftover debug output
2020-08-28T13:52:30+00:00

Daniel Schadt
kingdread@gmx.de

2020-08-28T13:52:30+00:00

7561a928912b62e0fea384840ebaec1d3c4d291c

Since downstream applications will also print this, we should remove it.





Since downstream applications will also print this, we should remove it.