| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Makes it easier to deal with boss ids, as they are usually given in
numeric form.
|
|
|
|
|
|
This comes with several changes:
First, the revision header field is now properly parsed and saved,
instead of just being hardcoded to zero. This is the first step in
allowing newer log files to be parsed. To accommodate this, the Header
struct has been extended with the "revision: u8" field.
To be able to parse both formats, the CbtEvent struct has been changed.
It is now the unification of both the new struct and the old struct, as
the changes are pretty minor and mostly concern the parsing itself. The
data types have been adjusted, and two fields have been added. Moving
fields around does not concern CbtEvent at all. If the struct diverges
more from this in the future, some splitting might be introduced, but
for now, the change is pretty transparent to other code.
During this process, the structs have lost their [repr(C]) property. It
was never used, as the structs were not directly involved in C FFI. It
has been a relic of the past from earlier iterations.
Finally, the parsing function has been changed from parse_event to
parse_event_rev0, with the addition of a parse_event_rev1. parse_events
now takes the event parsing function as an additional parameter, and
parse_file correctly choses the implementation based on the revision
number.
|
|
Somehow, new files (after ~2018-08-10) won't parse without this.
|
|
|
|
|
|
The arcdps update has introduced new state change events, namely
BuffInitial, Position and Velocity. It is now possible to track the
movements of all players.
Unfortunately, this meant that evtclib could not ready any logs created
by the new arc version, as the new CbtStateChange was not read
correctly. evtclib just returned "Invalid data".
This fix adds the new enum variants to the CbtStateChange enum, making
it again possible to read files. However, there are no high-level events
for those yet, so the conversion will fail.
|
|
|
|
|
|
|
|
If we throw away all empty queues before we register that they are
empty, we end up never removing some boons, getting crazy uptimes.
The current state is still not perfect, but it's much closer to what we
expect.
|
|
|
|
Exemplary done with Xera.
|
|
Does only the PoV player have the enter combat event...?
|
|
|
