| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
The amount of non-properly-implemented events is growing
|
|
|
|
|
|
thiserror seems to be the more modern approach that also works with the
new Error trait from std.
|
|
|
|
This was a change in Rust a while back, so we're updating to the new,
non-deprecated syntax.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
