Improve round end information, and add DiscordRoundEnded plugin #256
Conversation
Adds round-tickets regex to logparser; this will fire when the server prints new log lines related to tickets and factions. Adds round-ended regex to log parser and event; this event forwards round tickets where we have both a winner and a loser to the main server object. discord-roundended: This plugin is similar but functionally different from round winner, due to cases where the server experiences a draw.
|
Got this error on mine when I added it. |
Missing Early Return
|
It appears I missed the early return for draws
This should be fixed |
It appears the ticket totals we get may not always be super accurate. Squad has long had an issue of tickets getting subtracted during/after the scoreboard appears, I believe this is the issue under the hood. Will need additional testing to see how this occurs. The above was generated on a map that timed out after the test server emptied for the night |
Is that really the case? |
Yes, the above log lines are directly from testing. In the past, before OWI added the 'victory flags' animations to the scoreboard, you would often see tickets getting adjusted slightly during the scoreboard screen. It was entirely possibly that before moving to the next match both teams would have negative tickets.
The accuracy is an issue if anyone starts tracking ticket differentials. The data may be harder to understand if the winning team has less tickets logged than the loser. The tickets don't have an effect in code until someone decides to write plugins off the event, or include them in Dblog etc |
Thomas-Smyth
changed the title
Thomas-Smyth
added
core feature request
This is an initial commit, and will need additional work.
Currently known issues:
We only see round-tickets when the map is not a draw, this is fairly often, however our current round-winner event always fires (though incorrectly labels all matches with a winner, even if they are a draw).
The larger issue is the changes required in DBlog and elsewhere to smooth things over, these will result in schema changes that require DBlog to alter tables.
Further, in the case of FTP logging, we currently assume the log and rcon state are closely coupled, this is not always the case;
This means plugins like discord-roundwinner, that take the previous map are not guaranteed to be correct, and further issues around how we construct that data abound (layers.json missing data, see #222 )
The well defined path here should be stable, but edge cases around FTPlogging and such make the "draw" path much harder to handle.
The above is a map with a draw,
Currently NEW_GAME will report
But this is incorrect, and the new log lines will not appear, leaving an ambiguous state.