Lailloken
commented
3 months ago This was raised a while ago in #298.
The main issue is still "buffering" or holding the previous map's log-data while the new run has already started. There are too many unforeseeable things that can happen in between map 1 and 2:
-
client/PC crash during the loading screen
-
random disconnects
-
accidental click on portal (i.e. leaving the map again immediately after entering)
First of all, I would have to implement a lot of workarounds for these hypothetical scenarios because the tool would have to know how to "behave" in these situations. Secondly, in the event of a full system-crash (however unlikely), you would lose the kill-count for the previous map altogether (which won't happen with the current implementation).
Additionally, assuming the kill-count only works while chaining map-related content. As soon as you do something unrelated in between (e.g. lab, some hypothetical league-mechanic, etc.), the kill-count will be off the next time it's refreshed at the start of a map.
Scenarios where you periodically switch characters (e.g. having a dedicated bossing character) are also problematic.
The current implementation is simply the most consistent one that works in parallel with what is happening in the game/log-file. If you want to streamline it a bit, you can create a /kills macro and use that whenever the panel flashes. Clicking on the panel is not strictly required, the panel is merely signalling that the tool is waiting for the /kills command.
I always remember to press the Omni Key when I enter, but could you make it so that the new map start counter automatically assumes the number of kills from the end of the previous map if I didn't log it?
I don't understand why it needs to record the kills at the end of the last map and then again at the beginning of the new map as it would be the same. It would be easier if pressing the Omni Key once at the start of the new map could handle this, rather than having to remember to click the little flashing counter.