Feature Request: Load PTN

[TreffnonX]

The current loader function loads TPS, but the output for downloading notations is PTN.
Neither the file, nor the PTN-String can be correctly parsed by the parsing function.

Suggestion: Relable 'Load TPS' into 'Load Log' and accept both TPS and PTN strings.
Also, a file dragged into the string field should be loaded, so the user does not have to manually open the file to load it. A 'Select PTN file' button in the loading modal is also possible.

[ghost]

I like the idea of making Load flexible to recognize either notation and load as appropriate.

I can work on that.

Of course, the real value would be to let you reload a TPS (or PTN) into an ON-LINE game, and resume play at that point.

Scenario: two people are playing a beautiful game and one of them needs to leave for a while. They don't want to abandon the game, so they download a TPS or PTN. Then when they are ready to resume, one of them creates a New Game, their opponent joins the game, and then one of them does a Reload of the saved file and it gets pushed to the other player and play resumes.

I don't plan to make any enhancements to the server code, or the client-server protocol. So someone else will have to work on supporting resume of an on-line game.

[TreffnonX]

I would wait with that kind of change until chaitu finished his semester (it's just a few days now).
He will probably give new directions for playtak anyway. Maybe he will tell us that he plans for profiles and user-interaction. Then loading a game could actually be a much different process alltogether.

[ghost]

Thanks. I won't undertake that now.

[chaitu236]

The idea of being able to load a PTN to review a game locally would be nice. But I think resuming an online game from PTN isn't such a good idea because it'd require changes to UI most of which would be non-intuitive.

I think correspondence games, being able to add time to opponents' clock and games with time increment after every move would make this unnecessary anyway.

[TreffnonX]

I agree. The core feature would be restoring the saved PTN, since that is the output format downloaded after a game. To resume previous games seems a feature for when the platform is further advanced. It would also allow to 'branch' games by playing from a specific game state, but in a different direction. This would give a lot of interesting information on game states. But again - Feature for another day...

[ghost]

Does a correspondence game mean that the server will be able to maintain game state indefinitely and that a player will be able to reconnect back into that game at any point later. Or is that not what you are thinking of?

[chaitu236]

Ya, thats what I had in mind for correspondence games.

[klongeiger]

I thought about writing a quick-and-dirty PTN parser which would output a TPS string, optionally up to a certain play state. This would obviously not solve the mentioned problems regarding time and game state, but it might be a start. Anyone interested?

[TreffnonX]

hmm... from the standpoint that during the weekend I (assumably) will work a great deal on my client anyway (first to catch up with the master, then to do some long intended upgrades) I can probably go about writing an actual PTN parser that retains the steps. Would be a bit wasteful to invest any work in a quick fix. Also knowing kakaburra (a bit), quick (and dirty) solutions are not his style.

[klongeiger]

That is probably correct. I'll do the reasonable thing and familiarize myself with the existing client codebase. Maybe I can find some other things to contribute.

[TreffnonX]

Be aware, that Chaitu plans to modularize index.html which currently holds most functionality server side. Things might shift a bit before they settle somewhere. Also a similar refactoring is planned for the server, though I do not know how immediate he plans to do that.

[klongeiger]

I'll keep that in mind. Getting to know the style can't be wrong, though. Thank you, TreffnonX.