Notices

Originally Posted by jukey

[*]Sometimes we had to press the "play" button several times. It was hard to decide what seems to be the reason: I think on the one hand the button is to small but on the other hand the game logic sometimes seems to need some time until the requested move was done.[*]Sometimes we felt it a little bit to much to press play after each move but I think I we need some more impressions to decide if it is a good or not so good idea.[/LIST]Ciao jukey

Originally Posted by jukey

• In the 3 or 4 games we never used the "back" button
• Sometimes we had to press the "play" button several times. It was hard to decide what seems to be the reason: I think on the one hand the button is to small but on the other hand the game logic sometimes seems to need some time until the requested move was done.
• Sometimes we felt it a little bit to much to press play after each move but I think I we need some more impressions to decide if it is a good or not so good idea.

Originally Posted by mitweeeeh

Hi,
i wanted a pgn viewer for my N900 and i found Chessmonk, by Kanishou. I would very happy if i could work my openings with.

Is there any package for it? Nor sources? I posted on the old thread but i've no answer. The dev said it was functionnal, so?

Thanks a lot.

Originally Posted by geneven

... Scid ...

Originally Posted by mitweeeeh

I quote myself. Any possibility to contact the author?

Thanks

Protocol draft for Miniature-P2P
================================

We will assume that P1 and P2 have already found each other and are able to
chat ("match nick" in FICS).


A Chat
======

* "tell [nick|#channel] msg"
Why nick and #channel? Because later we migt want observers in P2P (so
there'd be a channel #obs, because you dont want the players so see the chat
of kibitzs).

* http://www.freechess.org/Help/HelpFiles/tell.html

* This command is the *only* one that will work in every situation, without
exception. It does not change the current game state.


B Game mode negotiation
=======================

* Both of the players can now propose a game mode, similar to
http://www.freechess.org/Help/HelpFiles/seek.html

* We can skip the parameters we dont support yet, so we need at least be able
to send/parse this:

"seek [time inc] [rated|unrated] [white|black]"

* Examples:
"seek 5 0 r w": 5 minutes, no incr, rated, seeker wants white,
"seek 5 0 rated white": same as above,
"seek 2 10 u b": 2 minutes, 10s incr, unrated, seeker wants black

* When the other player receives a seek, he can either accept the offer or
ignore it. Both players could propose game modes sending as many seeks as
they want, and at any time! But that would be silly in our case, so let's
simplify this dramatically:

1 host player (P1) sends seek,
A client player (P2) accepts seek: send "play" → 2
B P2 ignores seek: P2 can now send a seek
A P1 accepts seek: send "play" → 2
B P1 ignores seek: → 1
2 game starts (http://www.freechess.org/Help/HelpFiles/play.html)


C Moves
=======

* In FICS, once it is your turn, it is sufficient to enter "e2-e4" to move your
pawn, for example.

* FICS sends the new position to each player, obviously this simplifies sync
issues. So I think we should send sth like "move e2-e4; fen
rnbqkbnr/pppppppp/8/8/4/P/3/8/PPPP1PPP/RNBQKBNR b". The FEN position string
can be seen as checksum for the move, so we are able to always detect sync
issues. In case of an sync issue, the FEN position *overrides* the move, and
the error is logged (maybe even send "sync error" back to sender, so both
peers are aware). How to handle that beyond logging the error, I do not know.
Let's see if it really happens first. The more general approach is to have
the receiving peer always confirm a move with a checksum, based on the
position info it was able to compute, and the sending peer then compares this
checksum, and complains.

* The peers compute the status (check, checkmate, ...) themselves, based on the
position info send

* Move requests that are sent when it is not the player's turn should
be silently discarded.


D Takeback
==========
* FICS is a bit funny here, showing its age wrt verbose & racy protocol
implementation "takeback 2 - accept - withdraw", note how accept and withdraw
can happen at the same time.
http://www.freechess.org/Help/HelpFiles/takeback.html

* Again, let's simplify:
"takeback n", request to take back n moves, answered by "takeback n" (the
same n) to accept. Now it doesn't even matter who sends it first.
1 P1 sends "takeback n",
A P2 accepts: send "takeback n" → 2
B P2 declines: nothing happens → 3.
2 N half-moves are taken back.
3 P2 or P1 sends his next move (notice how this can clash with a "takeback n"
confirmation in case it was P1's turn, in which case the takeback
confirmation should win, as P2 is free to ignore P1's move after confirming
the takeback).

* Same as with moves, we send: "takeback n; fen current/fen/pos/ w|b", so that
the fen position is the one to be expected after takeback n would be
performed (assuming we go without the general approach of sending checksums
after every position change).

* A takeback request can be simply ignored without further actions.


E Draw
======
* http://www.freechess.org/Help/HelpFiles/draw.html

* We don't support claiming a draw yet, but that will be easy to implement:
before the other peer gets chance to say ok, "draw", we query the logic
analyzer, which is entitled to enforce a technical "draw".

* Otherwise, same as in takeback, without position sending:
1 P1 sends "draw",
A P2 accepts: send "draw" → 2
B P2 declines: nothing happens → 3.
2 Game ends in draw.
3 P1 sends his next move (P2 is not allowed to demand a draw if it is not his
turn, also, same conflict resolution as in takeback: draw confirmation wins
over P1's move, and P2 is free to ignore the move).


F Resign
========
* http://www.freechess.org/Help/HelpFiles/resign.html

* Players can resign at any time, I guess? No confirmation by other player
needed, game ends.


G Adjourn
=========
* http://www.freechess.org/Help/HelpFiles/adjourn.html

* I like the 2 cases presented on FICS, esp. the courtesy adjourn which handles
time-outs gracefully.

* Similar to draw and takeback:
1 P1 ran out of time, unresponsive
A P2 sends "adjourn" → 3
(B P2 claims the win, not important yet for our case)
2 P1 sends "adjourn"
A P2 accepts: send "adjourn" → 3
B P2 declines: nothing happens
3 Game is adjourned, both sides save the current position locally, game ends.