| Age | Commit message (Collapse) | Author |
|---|
|
We know that the way we construct the Log, the agents are always sorted
by their address. This invariant cannot be broken, as the only way to
construct a Log is in evtclib itself, and there is no way to obtain a
mutable view on the agent vector or change the address of an agent.
Since Log::agent_by_addr is used by other functions, this speedup (even
if it is small) can show in a lot of different places.
Note that if we change the interface of Log in the future to allow
creating logs from different sources that processing::process, we need
to make sure we adjust this function.
|
|
If we already have an Encounter, it might be nice to determine the game
mode from it as well - without needing to go through the whole log
first.
This is especially useful for raidgrep, where we can use the early
filters - which don't have access to the whole Log item.
|
|
For a lot of applications, it can be useful to distinguish between logs
made in raids, fractals, ...
Note that we probably don't want further categorization (as for example
done in ezau).
|
|
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.
|
|
The wording on the evtc README is
> an npcid of 1 indicates log is generic - triggers by squadmember
> entering combat and not as a result of a boss species id.
It is not quite clear whether "generic" implies WvW or if there are PvE
generic logs as well if you manage to set up arcdps in the right way.
Therefore, the wording in evtclib is rather unspecific as well.
|
|
|
|
It makes sense to expose this logic as a function, as other programs
like raidgrep might want to use the same logic when dealing with partial
evtc files.
|
|
Just like with Event, we now have Agent defined in its own submodule.
The amount of code that it entailed was a lot, so it made sense to split
it off, especially with the deserialization being another big chunk of
Agent related code in lib.rs
The main issue was that the processing submodule accessed private fields
of the Agent struct, which is now no longer possible (since processing
is no longer a submodule of the module in which Agent is defined).
Therefore, some simple crate-public setters for those fields have been
added. Those setters are not public because we do not want outside
crates to mess with the innards of Agent (yet).
Although with (de)serialization being a thing, we need to ensure that we
can handle nonsensical values anyway, since we can no longer guarantee
that we have full control over all of the values, even without setters.
|
|
The rationale is included in the comment below. The gist is that we want
to avoid deserializing Agent<Player> (and others) directly, as that
would circumvent the checks.
As a small bonus, we now skip the phantom_data field in serialization,
as that's just an implementation detail that other consumers shouldn't
worry about.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Those functions can be used to simplify the special case handling that
was done in lib.rs on encounters that have multiple bosses.
|
|
This is now the enum that contains the IDs of the single bosses, like
Nikare and Kenut. This means we can do away with the NIKARE_ID and such.
The enum is not publicly re-exported, as we re-export Encounter (which
is more of a replacement of the old Boss).
Special casing still remains (mostly in lib.rs), but we should be able
to do away with this now with a more general Encounter::bosses and
Boss::encounter methods.
|
|
This is the first step in differentiating between Encounters and Bosses.
It sounds a bit weird at first, but there are some events without any
bosses (like the River of Souls), and some events which have multiple
bosses (like Twin Largos or the kodan strike mission). If we want to
support this better, without relying on extra IDs, special casing and
constants (like NIKARE_ID), we should differentiate between Encounters
and Bosses.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Otherwise, this would only return Nikare, and not Kenut.
|
|
It turns out that the different encounters do require quite some
encounter-specific logic, not only to determine whether the CM was
activated, but also to determine whether the fight was successful, the
duration of the fight, later the phases, ...
Wrapping all of this in pre-defined "triggers" (like CmTrigger) feels
like it will be a bit unfitting, so with this patch we have introduced
the evtclib::Analyzer, which can be used to analyze the fights.
Currently, the whole CM detection logic has been moved to this new
interface, and soon we also want the success-detection logic in there.
The tests pass and the interface of Log::is_cm is unchanged.
|
|
|
|
|
|
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).
|
|
|
|
|
|
|
|
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.
|
|
|
|
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}.
|
