| Age | Commit message (Collapse) | Author |
|---|
|
Overall, evtclib is doing quite well on the .unwrap()/.expect()/panic!()
calls, except for some doctests (which can be changed at some point) and
the actual tests.
One case where we do panic (and should document it!) is Log::boss. The
documentation has been added there.
Another (rare if not impossible for proper evtc files) case was the
conversion of the language event, which assumed that we will definitely
be able to convert the u64 to the right language. In all normal cases
this should be true, but if evtclib deals with untrusted input, we might
not want to panic a whole program because someone smuggled in a
malicious file.
|
|
|
|
It turns out that arcDPS gives each boon stack an ID which is also
re-used in the BuffRemoval or StackReset events.
|
|
As it turns out, the padding bytes are not just padding, but for some
events they contain useful information. Therefore, we've adjusted the
parser to save those bytes (if available).
|
|
|
|
|
|
|
|
|
|
Otherwise the text will be garbled (reversed and probably cut short).
|
|
|
|
The reason why we "unwrap" the error so late is because we want to
recover from this error, which means the file pointer has to be at the
right position. Unwrapping early would leave the pointer in the middle
of an event, which is not what we want.
If we want to bullet-proof this, it might be good to read the whole
event first into a buffer, and then read from that buffer instead.
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
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 amount of non-properly-implemented events is growing
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This basically implements the "event logic" as described in the README,
though it produces easier-to-digest events.
The test binary show 0 failed events on an example log, but of course,
not all mechanics are used there, and the parsing logic may very well
contain some errors.
|
