Closed ctm closed 1 month ago
I will not be working on this until after I pick up trash. Between now and then I'll choose which solution to implement first. I do expect to have a working solution by this evening's tournament.
I'm going with the simplest solution to this specific problem, which is to go back to having NickMapper
sending the chat messages to all the people at the table (players and observers), which is how we did it before #1414, but to keep the code that I added that uses RoutedChat
to route a chat message to the Table
. The difference is that I'll then have the Table
hold on to the chat message for replay only, since it will already have been sent by NickMapper
.
The above solution will not add timestamps, but they're largely orthogonal and nowhere near as important as allowing people to chat after the tournament is over. As it is, Trail cleanup took a little longer than expected in part due to getting bitten by ants but also due to me regalingboring my fellow trashpeople-for-a-day with a tale of mist, rain, sleet, hail, lightning, a tornado and beer.
Fixed. Deploying now.
Fix so players can chat after the end of a tournament.
This is a regression that I must have added when I changed the code for preserving chat at a table (#1414). Logically, it makes sense, because I pushed chat support up from
NickMapper
toTable
, but withRunningEvent
in between, but guess what? There's noRunningEvent
after the end of a tournament. Duh.Turns out, the
Tables
are removed at the end of a tournament, too. The old way of doing chat,—viaNickMapper
—did what we want (except
for preserving chat for replay) specifically because it didn't use aTable
; it used its own knowledge of which players and observers were attached to a table (the logical construct, not theTable
struct).The replay log is, however, stored in the
Table
, so if we want to continue with the solution that I implemented for #1414, I need to make it so thatNickMapper
still sends the actual chat messages, but also sends a message toTable
telling it to record the chat message for later. However, a better solution would either be to move all of the replay log toNickMapper
(since one of the first thingsNickMapper
does on a reconnection is tell theTable
toreplay
).A more complex, but perhaps better, solution is to have
NickMapper
hold on to the chat messages, but to attach a timestamp to the messages inTables
replay log and to the chat messages thatNickMapper
uses and then use those timestamps to knit the two sources of messages together in order. If we do that, we can also choose to pass timestamps for all the replayed messages and that would allow people to see when each chat message was initially written rather then when it was received.OTOH, if we assign replay functionality solely to
NickMapper
we don't need to knit the messages back together, but we can still add timestamps if we want that functionality (and we do; I just don't know if it's worth doing while fixing this issue).