ilari wrote:
Hi,
Unfortunately there are a couple of problems with that:
1. The Result and Termination tags are at the beginning of a PGN game, but their values can only be determined when the game is over
I am not sure this is a problem. You can simply let those games flagged with an asterisk in the result tag, indicating the games are in progress. Also, you can overwrite the whole PGN game when the game is over.
2. The -concurrency option would have to be disabled or else the resulting PGN file would be a mess. Alternatively multiple output files could be used.
Maybe a workable approach would be enqueue game events using a worker thread which would synchronize the write into a single output file. One would expect a worst performance when using this feature though...
I think the sensible way to do what you want would be to have a separate debug-type file where the moves would be written in real time.
I don't know if it is the best way to do that. I would prefer a 'transparent' solution to the end user. You could use a separate file as long as you write the games in a PGN format. This feature would allow end users to broadcast their tournaments using a tool like pgn4web.
bhlangonijr wrote:I don't know if it is the best way to do that. I would prefer a 'transparent' solution to the end user. You could use a separate file as long as you write the games in a PGN format. This feature would allow end users to broadcast their tournaments using a tool like pgn4web.
I was just going to ask if broadcasting the games was the reason why this feature was needed. It sounds like there should be a better way of providing updates to pgn4web without periodically polling the PGN output. I'll see what can be done.
I would be very much in favor of some broadcasting standard for GUIs. PGN seems a very bad format for this, because it requires both game-state and rule knowledge in the viewer to decipher the SAN moves. I would prefer a long-algebraic format.
My ChessLive! viewer relies entirely on long-algebraic, and therfore can be totally dumb. It does not even know what castling is; I just let the server send both the King and the Rook move. Something like e1g1h1f1.
This is of course a problem if you want it to display SAN. Currently I have it display the long-algebraic, but I am thinking of upgrading the format such that it can also display SAN, by sending extra info. Together with each move I already do send score/depth/time info. I could add the leading part of the SAN move to that. Everything except the to-square, which it could take from the long-algebraic. Like "f3e5.Nfx" would move f3 to e5, and would print in the move list "Nfxe5".
bhlangonijr wrote:I don't know if it is the best way to do that. I would prefer a 'transparent' solution to the end user. You could use a separate file as long as you write the games in a PGN format. This feature would allow end users to broadcast their tournaments using a tool like pgn4web.
I was just going to ask if broadcasting the games was the reason why this feature was needed. It sounds like there should be a better way of providing updates to pgn4web without periodically polling the PGN output. I'll see what can be done.
Since it is written in java script, the alternatives wouldn't be so different than polling a file or a dynamic page providing the data. Surely you can reduce the size of the payload sent, by incrementally updating the chess board using the long-algebraic format as suggested by HGM.
Personally I don't see any problems with the way it is, unless someone is wanting to broadcast very fast matches - which I think doesn't make much sense...
hgm wrote:I would be very much in favor of some broadcasting standard for GUIs. PGN seems a very bad format for this, because it requires both game-state and rule knowledge in the viewer to decipher the SAN moves. I would prefer a long-algebraic format.
My ChessLive! viewer relies entirely on long-algebraic, and therfore can be totally dumb. It does not even know what castling is; I just let the server send both the King and the Rook move. Something like e1g1h1f1.
This is of course a problem if you want it to display SAN. Currently I have it display the long-algebraic, but I am thinking of upgrading the format such that it can also display SAN, by sending extra info. Together with each move I already do send score/depth/time info. I could add the leading part of the SAN move to that. Everything except the to-square, which it could take from the long-algebraic. Like "f3e5.Nfx" would move f3 to e5, and would print in the move list "Nfxe5".
I agree with you, but creating a new standard would require some effort in the specification, adapt all the GUIs/tools to make it compliant, etc. I think it is rather a simple requirement and even if someone come up with a better solution, the use of the PGN file should stick as an option.
As this very thread proves, GUIs have to be modified anyway. We might as well modify them straight away into something useful. Subverting a standard even before it has been defined, by offering inferior alternatives, seems a very imprudent strategy.
