Remote play (against friend or tutor) about picochess HOT 33 CLOSED

So, Remote play is basically working - you can play a game from board and web and all gameplay features are working. I also fixed quite a few bugs in the front end code, and made a few things work properly that didn't.

However, I need input from the group as to how some elements should work:

1. Clock - The web front end has no clock, so the web player cannot see the time-control or remaining time. How should this work? Add a clock to the web?
2. Takebacks - Allowed or not? How to agree with other player?
3. Multiple clients - The system allows for (correctly) multiple web connections for observers. Observers can make moves on their board to explore variations, but there is no distinguishing between the web player and a web observer so anyone can make moves that get sent to the board player. How to distinguish a web player from a web observer and to agree who is who?

Just a few initial questions... there may be more.

Pablo

from picochess.

Very happy that remote play is working! Some suggestions in answer to your post:

1. I'd suggest that clock times be displayed on the clock and the web server, although it may of course be problematic to have accurate time display over the Internet (esp. in bullet games) because of connection delays or interruptions. Displaying the remaining thinking time on the web is interesting to observers.
2. I'd say: no takeback. Taking back moves would be extremely confusing for those people who are playing without a screen (only board, clock and Pi).
3. With a chat connection the people logged on could sort out who is playing and who is watching. There are lots of chat programs out there, so this function does not need to be built into the web server. A "disconnect" function may be implemented in the web server to select misbehaving observers and kick them out of the room (or even blacklist their IP). A "private game" option (accessible by the DGT clock and/or the web server) might be built to allow exactly one connection and keep all observers out.

from picochess.

On 17. sep. 2015, at 20.51, DJ Dekker [email protected] wrote:

1. I'd suggest that clock times be displayed on the clock and the web server, although it may of course be problematic to have accurate time display over the Internet (esp. in bullet games) because of connection delays or interruptions. Displaying the remaining thinking time on the web is interesting to observers.

In perfect world, times should be synced on both the clock and the web interface, but I fear this is techically really problematic.

1. I'd say: no takeback. Taking back moves would be extremely confusing for those people who are playing without a screen (only board, clock and Pi).

I agree. No takebacks.

1. With a chat connection the people logged on could sort out who is playing and who is watching. There are lots of chat programs out there, so this function does not need to be built into the web server. A "disconnect" function may be implemented in the web server to select misbehaving observers and kick them out of the room (or even blacklist their IP). A "private game" option (accessible by the DGT clock and/or the web server) might be built to allow exactly one connection and keep all observers out.

With multiple connections only the first one connected should be able to make moves and nobody else. There can be silent observers and that's it. The two players playing should be able to make the game private or not with a checkbox, everything else is probably redundant. I say keep it simple.

Jonas Žnidaršič
[email protected]

from picochess.

How does it work? (I tried invoking it via white queen e5, but it does nothing.)

On 17. sep. 2015, at 12.37, Pablo [email protected] wrote:

So, Remote play is basically working

• Jonas Žnidaršič
  [email protected]

from picochess.

I dont think its committed yet?

One more suggestion after this feature is done.

We should have a way to move pieces and share analysis from web interface
to web interface.

The chat functionatity is not hard if you just use tornado broadcast
message which is broadcasting other message anyway.

Shiv

On Thu, Sep 17, 2015 at 3:26 PM, Izmet Fekali [email protected]
wrote:

On 17. sep. 2015, at 20.51, DJ Dekker [email protected] wrote:

1. I'd suggest that clock times be displayed on the clock and the web
   server, although it may of course be problematic to have accurate time
   display over the Internet (esp. in bullet games) because of connection
   delays or interruptions. Displaying the remaining thinking time on the web
   is interesting to observers.

In perfect world, times should be synced on bot the clock and the web
interface, but I fear this is techically really problematic.

1. I'd say: no takeback. Taking back moves would be extremely confusing
   for those people who are playing without a screen (only board, clock and
   Pi).

I agree. No takebacks.

1. With a chat connection the people logged on could sort out who is
   playing and who is watching. There are lots of chat programs out there, so
   this function does not need to be built into the web server. A "disconnect"
   function may be implemented in the web server to select misbehaving
   observers and kick them out of the room (or even blacklist their IP). A
   "private game" option (accessible by the DGT clock and/or the web server)
   might be built to allow exactly one connection and keep all observers out.

With multiple connections only the first one connected should be able to
make moves and nobody else. There can be silent observers and that's it.
The two players playing should be able to make the game private or not with
a checkbox, everything else is probably redundant. I say keep it simple.

Jonas Žnidaršič
[email protected]

—
Reply to this email directly or view it on GitHub
#22 (comment).

from picochess.

Thanks for the feedback everyone. You're thinking is all pretty much the same as mine, but always good to get a sense check. So here's what I'm intending to do:

1. Add clock to web client. I think I can conceive of a means of keeping them sync'd. I agree with DJ that not only the web player, but any observers would appreciate it as it's an important part of the state of the game.
2. No takebacks.
3. First client connected is the web player and the others become observer only, although can still exchange variations (not seen by either player).

I'm reluctant to include chat in the web client. I realise it's technically not very difficult, but it assumes that the board player is near a computer, and picochess was supposed to be a 'standalone' thing. If the board player has to have a computer with them anyway, why not just play on ICC/FICS or any other service that supports the board - they will always have better options and more features. If you were a true standalone user, how would it even work? I suppose we could try to convince DGT to make an electronic Ouija board!? :)

Once I've finished the above, I'll push a version that we can start testing with and discuss further from there - I'm sure we'll all think of other boundary use cases.

Pablo

from picochess.

I have more features to the board such as adding in comments, proper display of variations for pgn export. I will merge these in after your remote play code and fixes.

On chat, I think adding a comment to a position is almost like chat anyway. I will test that out in remote mode :)

Go ahead with whatever you are comfortable with and we can provide more feedback and I will merge in my changes.

Thanks!, Shiv

On Sep 18, 2015, at 1:58 AM, Pablo [email protected] wrote:

Thanks for the feedback everyone. You're thinking is all pretty much the same as mine, but always good to get a sense check. So here's what I'm intending to do:

1. Add clock to web client. I think I can conceive of a means of keeping them sync'd. I agree with DJ that not only the web player, but any observers would appreciate it as it's an important part of the state of the game.
2. No takebacks.
3. First client connected is the web player and the others become observer only, although can still exchange variations (not seen by either player).

I'm reluctant to include chat in the web client. I realise it's technically not very difficult, but it assumes that the board player is near a computer, and picochess was supposed to be a 'standalone' thing. If the board player has to have a computer with them anyway, why not just play on ICC/FICS or any other service that supports the board - they will always have better options and more features. If you were a true standalone user, how would it even work? I suppose we could try to convince DGT to make an electronic Ouija board!? :)

Once I've finished the above, I'll push a version that we can start testing with and discuss further from there - I'm sure we'll all think of other boundary use cases.

Pablo

—
Reply to this email directly or view it on GitHub.

from picochess.

Shiv. In order to make the code tidier easier to work with, I removed the ton of commented out javascript code in index.html, where you were making it work initially I expect. Is that a problem for any of your planned features?

from picochess.

That is entirely ok. I have a lot of changes in a different private repo, which I can merge in to board.html

Shiv

—
Sent from Mailbox

On Wed, Sep 23, 2015 at 1:28 PM, Pablo [email protected] wrote:

Shiv. In order to make the code tidier easier to work with, I removed the ton of commented out javascript code in index.html, where you were making it work initially I expect. Is that a problem for any of your planned features?

Reply to this email directly or view it on GitHub:
#22 (comment)

from picochess.

Hi all

sorry for having 'vanished' for the last couple of weeks - I've had a family situation that required me to be away from home to help my dad. Coming to a finish now - normality is returning!

So, today I am pushing up the remote play work so far. It is NOT complete, but is fully useable for testing purposes. The 'to-do' list looks like this:

1. Disable takeback
2. Restrict play to first connected session - everyone else is a spectator. If you choose to look in the code, you will see the start of some work for this (IP based), but I've had to change approach to deal with multiple clients behind the same NAT - edge use case but realistic.
3. Add draw/resign support to web app
4. Add clock to web app - written and in unit test.
   Other than that it's good to go - for testing anyway.

To use:
Select 'REMOTE' from game menu on clock OR place the second white queen on e5 when in a starting position.
Connect web client (this order doesn't matter just yet but it will)
All time control and play mode (ie play white or black) is still from the clock
Moves made on the board are instantly reflected on the web app
Moves made in the web app (when in remote mode) are displayed on the clock, the clock stopped until the move has been made on the board then the clock resumes.
If pico is not in remote mode, moves on the web app create variations as now.
Attempts to select a new level/engine/book result in the display of 'remote' on the clock and are disabled.

I wanted to get this pushed out asap, now I'm back working on it again, as it will benefit from some testing and use and there's also a number of bug fixes to various things that should really get into the build quickly.

So far, I've used it to play from the UK to local friends and players I know in New York, Los Angeles, Sydney, Paris and Dallas.

Bug reports to this thread please.

from picochess.

im not sure....but you changed pgn.py back to old stage?
If yes, that wont work.
In your "vanished" time, i changed your engine code abit..that includes pgn

from picochess.

Yes I saw all that, and I understood why you did it. Unless there was some kind of pronlem when I merged from jromang/master the pgn writer wasn't working - it was onlky ever display a custom starting fen and a result - all the moves were missing. I didn't restore to original state, just a few lines here and there that set things up to the pgn writer.

Unless, as I say, something went very weird when I merged in all the recent changes???

from picochess.

for me the easy way would be, you take my code (from my master) and update it with yr remote code and commit again.
I don't have a board with me for some time (so can't check what i'm doing is not breaking something).
For sure only speaking about pgn.py , not all

from picochess.

Are you unhappy with the commit? I have tested it all from my pico and board (it takes some time to test fully now, doesn't it!).

I'm pretty reluctant to do as you suggest - it was a pretty lengthy and complex merge as it produced many conflicts that took some time to resolve.

from picochess.

Im sorry, if i made y angry.
I like very much what you did (=>remote).

Only your code in MY(!) view wont work, cause for example at line 86, there is no "custom_fen" anymore.
I changed your coding in meantime.... for me, that's now more clear (and it will also work when the user using a remote engine). For sure, i can repair it myself too (but as said, i don't have a board - for testing, so its free-fall for me).

Mea culpa!

from picochess.

Ahhh...now I see. It's OK as I recompute and added back the custom_fen attribute toeh messages in picochess.py - you're right it would fall in a heap of exceptions otherwise.

You didn't make me angry at all!! So sorry if it came off that way.

from picochess.

Thing is... without setting the custom fen attributes and walking the node tree, the pgn exporter in 'chess' see's no moves to output at all.

from picochess.

lines 86-91 is old code (and NOT working btw for example if its a chess960 game)
pgn = chess.pgn.Game()
pgn.setup(message.game)

is much easier. What y decribed, i had too (but now, its solved).

from picochess.

I'm confused! pgn.setup() only sets the starting condition, which seems to get set to the 'final' fen of the game (which is what I saw happening), yes? What builds the node tree for the exporter to use? You're understanding of the chess library is much greater than mine...how does this work?

from picochess.

Just grabbed the files from your repo and it seems to do the same as I saw in the main repo. The pgn files produced have no moves, just the final fen in the FEN field:

[Event "PicoChess game"]
[Site "?"]
[Date "2015.10.14"]
[Round "?"]
[White "Pablo"]
[Black "Stockfish 150215"]
[Result "0-1"]
[SetUp "1"]
[FEN "rnbqkb1r/pp2pppp/2p5/1B6/4p3/7P/PPPP1PP1/R1BQK1NR w KQkq - 0 6"]
[WhiteElo "-"]
[BlackElo "2900"]

0-1

Is it me ??????

from picochess.

OK...my chess-python knowledge seems to be CRAP :-(

I was 100% sure, it worked but now i can't see how it ever could. So, i quit for now...taking a look at this evening in peaceful surrounding (=not here) and see how to fix the issues we have now cause we both working at same place of code.

from picochess.

Peaceful surrounding - YES! Sounds good.

I think we have no 'issues' now as it all works correctly, but it might be possible to make it nicer - which is always preferable. I just stuck back in what it needed to make it 'not broken'. I'm quite certain you can make it work better though. :)

from picochess.

when i play some moves, saying "newgame" => pgn writer => crushing with this custom_fen error.
But what do i know? haha. I feel strange, how this could ever happen to me..i was sooo sure, ha.

from picochess.

Need more peaceful surroundings! Haha

You know, pico has so many features now, perhaps we should think about some kind of automated testing? Perhaps we could drive it through your keyboard interface??

from picochess.

ok..some new version..without (big) errors i hope ;-)

from picochess.

Looks a lot nicer now. Good job!

You missed one "custom_fen=" in picochess.py in the DRAWRESIGN case. ;)

from picochess.

not only this. This morning had (again) some problems with merge
Perhaps y can take a look at pgn.py:
It seems this two lines (maybe must be changed? see: old_engine var) missing:
if message == Message.ENGINE_NAME:
self.engine_name = message.ename

Can't test my code (cause no board right now) nor do i - due to time limits - had the time to take a closer look at the new code

from picochess.

OK, I'll take a look at it. Have you checked in all your new code?

from picochess.

Hmmmm..... Had a look : the code looks OK, everything how it should be. Had a play: it all checks out fine - I would say no problems in this area.

Of course I found a different bug in another area (also from the merge - but my fault in resolving a conflict)
;)

from picochess.

with "new" i mean YOUR code. During conflict solving i saw some strange situations. Not sure, i decided them all correctly.
One is what i said above...another at picochess.py line 219. This would shoot a computer-move-done in remote play. Sounds strange for me, at first...But i admit not fully understood yr code (see above/time)

from picochess.

Hahaha - that actually really did make me 'lol'.

I did check my code too... I was really asking if you had checked back in 'the code' after the conflict resolution. The answer is the same - it seems OK and certainly plays OK. Did notice one strange thing (not in either of our new code - maybe related to chess lib), but it didn't repeat, so I'll just keep an eye out for it.

The 'remote mode' appears to most of the system simply as a different engine type - the move just comes from a remote web app not a local engine process. So it utilises all the normal behaviours and functions - actually have to cripple some (like takeback) to meet the situation. This will also allow a hook into remote UCI or server based play, if we decide either of those things are wanted - or not!

from picochess.

Will give new code a try today and or in the weekend.

Thanks!, Shiv

On Oct 15, 2015, at 2:05 AM, Pablo [email protected] wrote:

Hahaha - that actually really did make me 'lol'.

I did check my code too... I was really asking if you had checked back in 'the code' after the conflict resolution. The answer is the same - it seems OK and certainly plays OK. Did notice one strange thing (not in either of our new code - maybe related to chess lib), but it didn't repeat, so I'll just keep an eye out for it.

The 'remote mode' appears to most of the system simply as a different engine type - the move just comes from a remote web app not a local engine process. So it utilises all the normal behaviours and functions - actually have to cripple some (like takeback) to meet the situation. This will also allow a hook into remote UCI or server based play, if we decide either of those things are wanted - or not!

—
Reply to this email directly or view it on GitHub.

from picochess.

Can this issue be closed? Or is there something to do with Remote?

from picochess.