This process is a bit crazy, and it has some odd edge cases I've been unsuccessful at attempting to support. If you would like to help review/test, the code for the merge itself is all in AnalyzedFightPerformance.java. It's a complicated process but I'd say the intentions/desired behavior is well commented across the file, so I'll save explaining all the details that go into how it works in this issue. One thing I'm particularly confused about is mentioned in the // TODO comment¹.
Related plugin component(s)
Fight Analysis/Fight Merge panel
Describe the bug
There are occasionally fights that cannot get merged and I'm not sure why. It seems to be caused by one client missing an attack, but I've attempted to prevent against that - if an attack log can't find a matching log, it should just be ignored without causing the rest of the matches to fail.
¹Mentioned in the //TODO comment: The first part of the process, which finds matching FightLogEntries and ensures those matches have a consistent tick difference, it fails if we go through all the logs of a fight (if you stop using attacksToCheck/make it huge), rather than the first ~8-32, even if those attacks are all able to find a match afterwards when using the tick difference found in the first ~8-32 attacks (presumably valid, since there is a match for all attacks). This leads me to believe there is a bug in the first part that can be improved, as it should be able to find a consistent tick difference across all logs, if it is possible.
If you would like to help with this and anything is confusing, feel free to reach out or comment here and I'll explain any component/process of the plugin to the best of my ability.
Here is some fight data to test this with:
1) A fight where one client missed an attack, this one completely breaks the merge. (Either or both players were lagging a lot, and this may somehow be the cause).
hitVanishT1.txthitVanishT1opp.txt
2) A regular fight that works with the way the process is now, but does not get merged if we verify the tick difference for all logs/attacks (see //TODO comment)
1_1opp.txt1_1.txt
This process is a bit crazy, and it has some odd edge cases I've been unsuccessful at attempting to support. If you would like to help review/test, the code for the merge itself is all in AnalyzedFightPerformance.java. It's a complicated process but I'd say the intentions/desired behavior is well commented across the file, so I'll save explaining all the details that go into how it works in this issue. One thing I'm particularly confused about is mentioned in the // TODO comment¹.
Related plugin component(s) Fight Analysis/Fight Merge panel
Describe the bug There are occasionally fights that cannot get merged and I'm not sure why. It seems to be caused by one client missing an attack, but I've attempted to prevent against that - if an attack log can't find a matching log, it should just be ignored without causing the rest of the matches to fail.
¹Mentioned in the //TODO comment: The first part of the process, which finds matching FightLogEntries and ensures those matches have a consistent tick difference, it fails if we go through all the logs of a fight (if you stop using attacksToCheck/make it huge), rather than the first ~8-32, even if those attacks are all able to find a match afterwards when using the tick difference found in the first ~8-32 attacks (presumably valid, since there is a match for all attacks). This leads me to believe there is a bug in the first part that can be improved, as it should be able to find a consistent tick difference across all logs, if it is possible.
If you would like to help with this and anything is confusing, feel free to reach out or comment here and I'll explain any component/process of the plugin to the best of my ability.
Here is some fight data to test this with:
1) A fight where one client missed an attack, this one completely breaks the merge. (Either or both players were lagging a lot, and this may somehow be the cause). hitVanishT1.txt hitVanishT1opp.txt
2) A regular fight that works with the way the process is now, but does not get merged if we verify the tick difference for all logs/attacks (see //TODO comment) 1_1opp.txt 1_1.txt