| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
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
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The old function turned a bit into a mess, so the functionality is now
split up.
|
|
|
|
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.
|
|
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.
|
|
|
|
|
|
We can now make compile-time guarantees about the contained kind, so
that Log::players for example can return players directly.
|
|
Since we know that we're only returning Agents which are Players, we can
save downstream users some time and also provide access to the &Player.
Ideally, we'd want something like PlayerAgent, or Agent<Player>, but
that not only incurrs code duplication (in the first case), it'd also
mean cloning the player data (second case), as we couldn't just return a
reference into the pool with all agents.
For now, this is still the better option, until other ways have been
explored. Maybe cloning here wouldn't be too bad, but we'd also run into
the issue that we cannot use record unpacking for records that have
different generic parameters, so going from Agent<AgentKind> to
Agent<Player> would mean manually copying over all record fields.
We now no longer need the matches! macro, as we can simply use
AgentKind::as_{player,character}.
|
|
Both of those are only used in lockstep anyway. If the AgentKind was
Player, the AgentName was also Player. Having the possibility of
mis-matched enum variants here was bad and always required an extra step
of "unwrap" that was not necessary.
This combination is the first step to simplify the handling of different
agent kinds.
|
|
The types are so small that a reference would be slower than just
copying the number itself.
|
|
The .ok_or() method on Option is enough for those two occasions that we
don't need to activate the complete try_trait feature just for a very
small and questionable ergonomics gain. This also allows us to more
easily discern which data exactly was invalid, as the .ok_or() in
different places could take different error values.
This also allows evtclib to be used on stable now.
Some noise is introduced in the diff due to automatically re-formatting
the source.
|
|
Those are not used anymore and can be disabled. Maybe we can even get
rid of try_trait in a nice way, allowing us to run on stable instead of
nightly-only.
|
|
The implementation was short, but since we're using thiserror anyway, we
might as well be consistent and derive the implementation.
|
|
|
|
The way the trackers worked was rather... "adventurous", and while there
were some good ideas and it mostly worked, the implementation and
interface could do better.
Additionally, it was incomplete, for example there were a lot of
mechanics just missing.
While I'm not against having this functionality provided by evtclib, I
think it would be more worthwile with a better designed implementation &
API, so this "proof of concept" implementation is gone until there is a
better way of doing things.
gamedata is being kept, as the boss identifiers are useful and
applications shouldn't have to deal with keeping this low-level list
themselves.
|
