[oldmariner]

Pretty cool, thanks!

I was casting my pieces off, guaranteed a win, but my opponent left, so it didn't count as a win for me to my disappointment.

Perhaps if someone leaves and doesn't return within 60 seconds, the game should be a win for the person remaining if the remaining person's pip count is lower.

[anamexis]

I think whoever abandons the game should forfeit, otherwise you get weird incentives (like to quit anytime your pip count is higher)

[oldmariner]

That's why I only mentioned a different condition which hopefully doesn't lead to bad sportsmanship.

[oldmariner]

Happened a second time :-( although this time my opponent still had a chance.

Both games where my opponent left, now show as wins in my history.

Also, I like the dice addition, but on desktop, the dice images are not matching up with what is rolled and displayed in the log.

How long does an opponent have until they auto forfeit if they don't move?

[tslocum]

Thanks. The way inactivity is handled is covered in the FAQ: https://bgammon.org/faq/#what-happens-if-a-player-goes-inact...

You shouldn't need to wait more than 30 seconds to see a win in your history after you also leave the game.

Will you please share a screenshot of the dice issue?

[oldmariner]

https://imgur.com/a/bqyWblS

Maybe it was the Firefox addon Canvas Blocker? That addon was crashing the game, so I disabled it and appears to work now. The game still makes my laptop fans kick on though.

[tslocum]

Thanks. Yes, that makes sense. The web version of the game is powered by WebAssembly and renders to a canvas.

The game is only able to utilize one CPU core when running in the browser, maxing that core out probably set off your fans.

[NooneAtAll3]

...isn't webassembly supposed to be more efficient?

[tslocum]

The reduced performance is a Go problem rather than a WebAssembly problem. See this issue for more info:

https://github.com/golang/go/issues/28631