The issue at hand is at most a handful of events every now and then having positions that are way outside the boundary of where the fight generally is. this leads to a zoom out so far that you cant see anything anymore.

Should be reasonably simple to figure out when doing some kind of median position / standard deviation thing. Figure something out.

Users should not be able to arbitrarily zoom and pan around the plot.

• no going into the negative on either axis
• not going way beyond the end time of the encounter (in seconds)
• no zooming to the point where the plotted graph is functionally invisible / unusable

All of the lists in the DBView tab should have buttons for pagination so you can go through all of the data that is stored in the DB.

The AutoGenerateColumn event could be used to cancel columns before they are added to the data grid, and user-defined columns could be injected (?is that the right term?).
When combining this with custom attributes like for example:

[ColumnHeader("Name"), TextColumn(Align: "Left")]
public string Name { get; }
[ColumnHeader("DPS"), BarColumn]
public Custom.TotalMetric DPS { get; }

There is an option to generate columns based on the listed attributes, instead of having to add them to the .xaml file manually.

The columns need to be created via code, set up with everything bla bla bla, and in the end its probably not going to be all that great.
But it might be worth thinking some more about at a later time.

Once the DataGrid contains a lot of rows it goes offscreen and part of the data becomes functionally invisible to the user. This should not be allowed to happen.

There should be a target selection for damage, simple as. This can be provided as an optional TargetGUIDFilter

huge discrepancy between this and WCL in that regard.
https://www.warcraftlogs.com/reports/jJFmybRZqQt4VB8T#fight=19&type=healing WCL shows 32k~ healing, this app comes out to 66.5k with the same file.

Prerequisit: ability to parse UNIT_DIED / PLAYER_DIED / whatever the actual event is in the Combatlog.

Deaths should be displayed by WHO died, WHEN they died, and WHAT killed them (name of the Ability, "Environment"/"Falling" if not applicable.)

When looking at Combatlogs/Performances/Players, clicking on an item in the ListView duplicates (visually) the entries that are being shown.
That obviously shouldnt happen.

Should use the "index" of the entities, not the Id, as that is not future-safe (deleting things should be possible at some point)

you should have an option to archive logs. archive status should be included in the LogMetadata entry for it.
Archiving should just be putting a log .txt file in a .zip for simplicity.

This is meant as an alternative to completely deleting logs from the directory / database. .zip'ing sufficiently large log files has the potential to save several hundreds in megabytes of storage space. Which adds up fairly quickly when using this a lot.

For situations where adds need to die and you have an addon that automatically marks it with the "Skull" marker, its interesting to be able to see who is doing how much damage to the target.

This requires only an additional EventFilter parameter that gets passed a TargetRaidFlagFilter (needs to be created first) with the correct mark set.

The "done by spell" (per entity) breakdown should include other info like "average hit", "crit rate", and "biggest hit".

Implementation for this requires:

• replacing the long value of the dictionary that is returned by those methods with an appropriate data type
• adding new DataGrid columns that display those new fields

The code for generating damage / healing / etc. breakdowns should not be in the SingleEncounterView.xaml.cs file.
All of this should be in a different file. Most likely this should be part of the EncounterInfo class, or an extension for it.
Any parameters such as which player or mode is selected should be used as a parameter for the method.

Already did this with strings where i went from 8MB to 1MB of duplicate strings
But there are still 4MB of sparse arrays.
some offenders that are guaranteed to be because of me:

• CombatlogEvent[] - 610KB - example: 38% unused, array length: 204606

• AdvancedParamEvent[] - 331KB - example: 25% unused, array length: 163840

• DamageEvent[] - 84KB
  and other events too of course.

• PowerType[] - 107KB - (many of these are 4B each, with 100% (1) unused, which would just be Mana, i think that can be safely ignored.)

The UX when importing a log should be improved.

• No longer only import on start-up, have a dedicated button for it.
• Show a progress bar for the individual steps while importing a log.
• Show a warning popup when a log has already been imported. (Just dismiss, no other actions to be taken)

You should be able to remove combatlogs from the stored metadata, and/or re-import entire logs (delete old metadata, create new)
this is mostly so that if a version was bugged during import, the data can get updated.
addition: versioning for this app maybe? just an idea

After inspecting an encounter and going back to the DB View, the loaded combat data remains in memory, which can be >20MB each.
Unused combat data should get garbage collected but there is something preventing it from happening automatically

The Searchbar for Players (as a part of MainWindow.xaml right now) has a bunch of problems right now:

• input breaks, only allows one character, then resets.
• using the arrow keys to go down should not cause the player to be "selected" for inspection in the PMView.
• Doesnt display all information (realm, class color)

Besides that it might be a good idea to seperate it out into its own control and provide an event for when a player is "really" selected

I want a config option that determines whether log files are stored as is in plaintext, or whether they should by default be compressed as a .zip archive.
Compressing files obviously leads to lower harddrive usage, while increasing load times.

Users should be able to give a label to a combatlog, rather than just being shown a file name.

Every basic SpellSchool type should have its own color/brush associated with it.

Additionally it would be really cool if every spell school that was a combination of multiple basic ones had a Gradient Brush across all the basic types as its Brush.
(Optional: adjust the type structure to be equivalent to what was done for ClassColors and their Brushes.)

Relevant classes / files: SpellSchoolColors, ClassColors

You should be able to navigate between encounters in the same combatlog.

This can either be implemented:

• directly in the SingleEncounterView
• as a CombatlogView that embeds a SingleEncounterView with the selected encounter.
• as a CombatlogView that links encounters via changing the MainWindow content to a new SingleEncounterView

The second option is most likely the one that is favoured.

Selecting a specific player as source should provide a list of abilities and how much damage/healing they did.

Augmentation Evokers _SUPPORT events should be taken into consideration when creating performance metadata created by importing a combatlog file.
the way to do it is already implemented in the Single Encounter View code right now, but it has not been copied over to CombatLogParser.ProcessPerformances yet

Havent yet looked into why, but it just leaves the view blank after reading the encounter. very weird
Note that this doesnt happen when navigating to the encounter view via the player page

In situations where a subtlety rogue uses Secret Technique, the damage dealt by the Akaaris Soul NPC that is spawned is currently not always counted as being done by the rogue.
There can be SPELL_CAST_SUCCESS events associated with these Souls, but they are unreliable when the rogue is far away from the person that is logging. In the case that they do appear however, the Advanced Parameters of the event refer to itself and subsequently provide the GUID of the rogue it belongs to.
For situations where only one rogue (with the relevant talent) is in the raid, the soul can just be linked to the rogue without any additional checks, and the NpcId (144961) should be used for this.

The implementation of this will probably require a bit of a rewrite of things where special rules and such can be allowed.

• count of classes/specs within raid group
• talent check (talents in general need to be properly done first, the IDs in the COMBATANT_INFO are difficult to figure out)

Next to Damage done/taken and healing, one of the interesting aspects of fights are buffs and debuffs.
This comes in different varieties for different purposes:

• Tracking buffs / debuffs across the raid
  • This aids in seeing when someone used a group affecting ability a Bloodlust effect or healing cooldown (e.g. Divine Hymn) and vice versa with large raid wide debuffs applied from the boss
• Tracking debuffs by certain players on enemies
  • Useful for seeing uptime on DOTs and other damage increasing debuffs

The "Total" line should not be a regular line in the DataGrid in order to prevent it from being included when sorting it by one of the columns via the DataGrid headers.

For some (as of now unknown) reason, the dps sums in the single encounter view are very wrong. about 3-4% off from what its supposed to be.
(For all intents and purposes, the overview/import dps is correct - within 0.02% margin of WCL on average)

Theres something going wrong in the dps calculation thats done in the encounter view source code.
Needless to say: The goal here is not to temporarily fix the encounterview damage/healing calculation, but to rewrite this into one combined method that works for both import and inspection.
After all, both should start out with the EncounterInfo object that is used to generate the dps totals.

When importing a log, the user should be shown a popup giving information about the error that occurred.
This includes but is not necessarily limited to:

• the line the program is currently parsing
• the underlying error message with stack trace
• link to github issues page to create a bug report

As is C# standard, you shouldnt really have public fields exposed and should use get properties instead.
An example of where this currently isnt the case is the DamageEvent class.

Some events are properly using properties, while some arent. This should be fixed to get the codebase all around up to standard.