| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This makes sure that at least the basic functionality is working. The
logs are "real world" logs, unmodified, directly from arcdps. Some of
the names have special characters in them, so that part of the code is
tested as well.
|
|
|
|
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}.
|
