search

pwmarcz / autotable

An online mahjong table
https://pwmarcz.pl/autotable/about.html
Other
69 stars 21 forks source link

bugged wall (trying to flip doras and things got weird) #6

Open joshk0 opened 3 years ago

joshk0 commented 3 years ago

Hello! We love your project and have been using it to play "potluck mahjong" (riichi mahjong except everyone gets to make up a rule before play begins.) It's something hilarious and it's only possible IRL or on autotable (forget tabletop simulator, I am so beyond that now... yours is better)

BUT, we hit an interesting bug. It is hard to describe but you should just watch here. Twitch recording. After some frantic dragging and highlighting and dragging some more, somehow the bug went away.

It occurred while trying to flip dora, about 22:xx UTC-4 on October 5th, table Y7E4T - if you do have historical telemetry of the games.

Hope this bug report is useful, sadly I'm not sure we'd be able to help reproduce for you, but if there is any more information you might need to diagnose the problem, just let me know!

riichinomics commented 3 years ago

What's the timestamp on the twitch recording for the bug?

pwmarcz commented 3 years ago

Hi @joshk0! I did notice the streams linked from Discord. It's great to people enjoying the game, and I'm happy the engine has been so flexible to enable games like that.

I do see the problem (for the record, it's around 6:38:00 in the video). No idea about the details yet (I don't have any detailed logs server-side), but it looks like it's enough for a single player to trigger it (as opposed to some conflict between players?) Just thinking aloud here; anyway, I'll be trying to reproduce it.

@riichinomics I see you've spent some time with the code, maybe you have some idea? Your fork is impressive, BTW, hope you had a good tournament.

pwmarcz commented 3 years ago

It looks like the unmoving tile is still considered "held" by one of the players...

riichinomics commented 3 years ago

This looks like part of a series of bugs related to the fact that the client waits for the server to send it updates about whether it is holding something or not. This is a benign version, where the kamicha has clicked on a tile and it has become 'selected'. They fixed it by making another selection.

We found some issues after starting our own server, such as tiles in your hand flickering when you rearrange them, or tiles becoming 'locked' where your client thinks it is no longer holding the tile, but the other clients think that you are, so you can no longer let go of the tile and no one else can pick it up. One simple consequence of this is that if you click a tile in the original client it will become 'selected' and only once you select something else will it become free. This is emergent behaviour and not an explicit feature.

I solved these issues by preventing the server from sending updates back to a client that is sending them, and immediately updating local world state when you send updates to the server.

This is not the ideal server architecture because the server should be a source of truth in some regard, but there's no real logic on the server so whatever order the client applies the events from the server is what the view of the client becomes.

Related commits: https://github.com/riichinomics/autotable/commit/060ec259d84f9ec69c33e8fbc8aff4a82eb931d8 https://github.com/riichinomics/autotable/commit/8cd557779c8605b69f6ab650ceb26d867e1abad0 https://github.com/riichinomics/autotable/commit/c91e6b64f5c0c26f2db521964a4aad92da5b8031 https://github.com/riichinomics/autotable/commit/2a998d8830a160aa2df6b176b09fa9b78ddcbaa5

They're a bit messy and there's probably a bit missing, but you get the idea.