| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
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...?
|
|
|
|
|
|
Deriving it puts the Default trait bound on X, T and D, even though this
is not necessary.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We need to know the stack size and the boon type anyway, so there's no
point in guessing them for unknown boons. We just restrict ourselves to
the known ones.
|
|
still missing:
* spirits
* superspeed
* any other non-boon thing (Empower Allies, banners, spotter, ...)
* ...
|
|
|
|
|
|
This prevents calling BoonQueue::simulate a lot of times. Still needs
more profiling to make it even faster.
|
|
|
|
Trackers help us to keep the code somewhat cleaner, especially in the
statistics::calculate function.
|
|
|
|
This is already pretty good to calculate the overall boon uptime/average
stacks.
|
