Age | Commit message (Collapse) | Author |
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
The reason why we "unwrap" the error so late is because we want to
recover from this error, which means the file pointer has to be at the
right position. Unwrapping early would leave the pointer in the middle
of an event, which is not what we want.
If we want to bullet-proof this, it might be good to read the whole
event first into a buffer, and then read from that buffer instead.
|
|
|
|
This is not defined by arcdps, but we'd have to adjust evtclib every
time a new statechange is introduced. This way, we stay
forward-compatible.
|
|
|
|
|
|
The sacred texts have been received and can now be used to make sure we
detect the Cardinal Sabir Challenge Mote correctly!
|
|
Currently, I seem to not have a Cardinal Sabir CM log though.
|
|
|
|
|
|
|
|
This is something that a lot of applications will probably have to
implement anyway, so we might as well provide it and do it within Rusts
standard traits.
This does not provide localization, but it uses the English names, which
should be good enough for most cases.
Since we provide FromStr for those classes as well, it makes
double-sense to add Display. However, not all cases are currently
reversible ("Cairn the Indomitable" vs "Cairn"), although the status quo
seems fine for now (most people type Cairn, but when outputting we can
use the full name).
|
|
The given buff is the Countdown effect that each player has:
https://wiki.guildwars2.com/index.php?title=Countdown
The logic is from GW2-Elite-Insights-Parser (Cairn.cs, IsCM), but we
count this as a buff instead of a skill.
|
|
This is the start of an effort to clean up lib.rs a bit by moving out
functions into their own module and re-exporting them.
|
|
|
|
|
|
|
|
This still needs a bit of work, as some of them are untested (Conjured
Amalgamate, Fractal CMs).
|
|
|
|
|
|
For the same reason that Boss implements FromStr, we might want users to
be able to specify professions or elite specializations in textual form.
|
|
fnv was used in the old statistics module, which has been removed.
Therefore, we no longer need or use fnv.
|
|
|
|
|
|
|
|
|
|
We can always do this conversion, because we can just throw away the
events field.
The other way around is not possible, as we need a file to parse the
events from.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The API guidelines for Rust state that readers should be taken by
value[1]. If the caller wants to re-use the reader, they have to borrow
it.
This patch adjusts the parsing functions to do just that.
[1]: https://rust-lang.github.io/api-guidelines/interoperability.html#generic-readerwriter-functions-take-r-read-and-w-write-by-value-c-rw-value
|
|
The source code itself is pretty small, however, the repository also
contains >40MB of test data in the form of evtc log files. We don't want
all consumers of this library to download all of this test data just
because they want to use the library.
This commit excludes everything except for the source (and some metadata
files) from the cargo package, allowing a thin distribution.
The git repository will still contain the tests, and the CI will still
run them.
|
|
|
|
There is "cargo clippy -- -D warnings", but that stops after the first
warning - and it displays them as an error. Not really the best
solution. The hacky workaround here is to make the script have a
non-zero return status when it found warnings, but still display them as
warnings only.
|
|
|
|
|
|
|
|
Those are methods that are probably useful to some applications, and it
feels like some of that data should even be in the file header. Due to
the evtc limitations though, we need to loop through the events to
access it, which means that every application would have to implement
this.
Those functions should be kept in a separate impl though, as they are
more costly to call than the other accessors. Maybe they should even be
moved to an "extension trait", though it's not clear whether putting
this behind a trait would be idiomatic Rust. The advantage would be that
users would have to specifically import the trait, thereby making sure
they're aware of the performance implications.
|
|
|