(strict) Rengo finally started, but one of players was not here. Turns out creator didn’t know what “casual mode” is. Game was cancelled, casual mode challenge was created, but this time it didn’t start, people not returned…
looks like “casual not default” is small problem, big problem - people don’t even know WHAT “casual mode” is.
The default to casual mode is on its way. I guess we could also consider inverting the checkbox and calling it “strict mode”, default off.
bug:
“Tie”, when in fact one of Colors won
@benjito Maybe not working afterall 
Lol interesante. @stone.defender any chance of a link?
my profile
Thanks @BHydden!
So it looks like black_won and white_won aren’t accurate, but outcome and annulled might be okay:
I can’t do a whole lot about the B/W/Tie because that’s a server issue (server code isn’t publicly available). Here’s the options I could help with:
Any thoughts?
far from perfect
perfect is to show color and show which color user was
someone(who can) needs to fix black_won and white_won then
He’s already said that someone isn’t and can’t be him.
He listed the changes that he personally can make.
Or call it shared clocks 
I think that’s a large part of it, but I know it also encompasses the design/timeout stuff too.
I don’t know a brief but obvious name for that, if you didn’t already know that was the case in rengo.
In this tie by 28 points
In the api near the bottom there’s
"winner": 780398,
"outcome": "28 points",
https://online-go.com/api/v1/games/40477686
Can we just check which team the player with that id is on? In this case it appears as the first player under rengo_teams in black.
Team clock/individual clocks?
This isn’t the key thing about casual/strict. The key thing is dropouts-dont-kill-it. The fact that you need individual clocks for this to make sense is derivative.
I think looking at each game individually is infeasible because of the way PaginatedTable works. The data needs to come from the player/%%/games endpoint. If you see something in there that might help, let me know!
This is a good way of approaching it, though there is a moderate risk that any declaration from the server about “who the winner is” is wrong, because of “if player is black else white” logic.
An alternative is if you can help me understand what scenarios are broken, I can find and fix them.
The challenge at the moment for me is there are so many scenarios it’s daunting.
We need to know whether the result is correct in the case of
I couldn’t stand the thought of this having to be fixed in the client, and went digging. 
I think I have found a place to fix it “for all cases”, so standby. 
Can you post some screenshots - that would help a lot
I haven’t seen that
There are 2 chats. If you post message in chat above, it shows below only some time later
if you post message below, it shows above, but shows below only some time later
I think seen case where message appears below first and only then above, but couldn’t recreate. Maybe it happens when someone else posts?
Is there any technical reason why we cant have rengo games in the same game history with all the other ones? Maybe have those marked as R or with some multiperson-symbol.
(sry for off-topic idea, i should post it prolly on github) - handicaps could also be marked in the same place at game history.
Just FYI
When I separated them, it was because it seemed like we may want different information laid out differently for Rengo.
I also thought we’d want to be able to say “show me my rengo games”, and since the table we use doesn’t support filter by columns, it needed a separate table for rengo.
Oh, and when it was first done, most of the normal fields in the normal game history had no chance of being populated correctly for rengo
There is no technical reason why they can’t be folded back together if they become similar enough.
