aboutsummaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
2020-07-23implement Analyzer::outcome for fractalsDaniel Schadt
2020-07-23make Log::boss_agents/is_boss work on Largos TwinsDaniel Schadt
Otherwise, this would only return Nikare, and not Kenut.
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.
2020-06-12add Log::spanDaniel Schadt
2020-06-12implement CBTS_TAGDaniel Schadt
2020-05-21fix formattingDaniel Schadt
2020-05-21ignore unknown statechanges in parse_eventsDaniel Schadt
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.
2020-05-19implement Error statechangeDaniel Schadt
2020-05-19add CbtStateChange::UnknownDaniel Schadt
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.
2020-05-19add Attribute and BuffCategory enumsDaniel Schadt
2020-05-19add BreakbarState, BreakbarPercent & Error statesDaniel Schadt
2020-05-11fix formattingDaniel Schadt
2020-05-11add Display implementation for gamedataDaniel Schadt
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).
2020-05-10add Cairn CM detectionDaniel Schadt
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.
2020-05-09move process_* out of lib.rsDaniel Schadt
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.
2020-05-09update documentation and READMEDaniel Schadt
2020-05-09add process_stream and process_file functionsDaniel Schadt
2020-05-08add first support for determining CMsDaniel Schadt
This still needs a bit of work, as some of them are untested (Conjured Amalgamate, Fractal CMs).
2020-05-04implement FromStr for Profession and EliteSpecDaniel Schadt
For the same reason that Boss implements FromStr, we might want users to be able to specify professions or elite specializations in textual form.
2020-05-02fix formattingDaniel Schadt
2020-05-02add docs about parse_events and the parserDaniel Schadt
2020-05-02implement From<Evtc> for PartialEvtcDaniel Schadt
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.
2020-05-02implement Hash, Default, PartialEq for raw typesDaniel Schadt
2020-05-02add a note about writing evtc filesDaniel Schadt
2020-05-02use getters for EventDaniel Schadt
2020-05-02add more documentationDaniel Schadt
2020-05-01add a comment about redundant closuresDaniel Schadt
2020-05-01take readers by valueDaniel Schadt
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
2020-04-29fix long number literalDaniel Schadt
2020-04-29add some convenience methods to LogDaniel Schadt
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.
2020-04-29formatting fixesDaniel Schadt
2020-04-29implement TryFrom for non-referencesDaniel Schadt
2020-04-29delete main.rsDaniel Schadt
This file was a big mess of different local experiments of playing around with the API. It didn't get updated with the rest of evtclib and consisted of 80% commented lines that once tested something and are now useless. We can have a nice small main.rs in the future that can be used to print out some basic information about a given log file, or rely on examples to demonstrate the API capabilities. But this abomination that was main.rs should be gone.
2020-04-29replace own from_raw with TryFrom implementationDaniel Schadt
Hooking into the standard Rust system is probably better in the long-run than having those separate from_raw methods on all of our objects. Most end users probably won't even need them, as they will use the higher level functionality provided by evtclib::process.
2020-04-29make event submodule publicDaniel Schadt
The module contains some useful structs which were otherwise not exposed in the public API, so it's better to make it public. The re-export of Event and EventKind can stay, for convenience.
2020-04-29implement TeamChange, AttackTarget and TargetableDaniel Schadt
2020-04-28more inliningDaniel Schadt
2020-04-28add more shorthands to Agent<Player|...>Daniel Schadt
2020-04-28derive Hash for WeaponSet and ActivationDaniel Schadt
2020-04-28implement Position/Velocity/Facing/MapId eventsDaniel Schadt
2020-04-28fix documentation for CbtStatechangeDaniel Schadt
2020-04-28more documentationDaniel Schadt
2020-04-28restructure how agents are constructedDaniel Schadt
The old function turned a bit into a mess, so the functionality is now split up.
2020-04-28move boss_id() to encounter_id(), add encounter()Daniel Schadt
2020-04-28add Profession and EliteSpec enumDaniel Schadt
In the high-level "Player" struct, dealing with the low-level numbers seems a bit off, especially because it means that applications have to keep a table of id-to-profession mappings anyway. We're already including a Boss enum for the same reasons, so we might as well include Profession and EliteSpec data - which is also not changing as frequently as Boss.
2020-04-28derive Hash for Player/Gadget/Character/AgentDaniel Schadt
It is very much possible and likely that someone would want to use a Player or Agent in a HashSet or HashMap, and there's no reason why that should be forbidden.
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-15 09:53:35 +0000