Clicking on your own piece after already having one of your own pieces selected should select that piece

[rmadhwal]

Hey, thanks for the great app!
As noted in the issue title, currently if you select a piece and then select another, it informs you:
Denied by engine: Move not found as a possibility
Though as it's never possiible to capture your own pieces in chess, this could be an area for improvement which allows you to move a different piece instead.
I'm new to both rust and the remarkable but would be happy to add a PR if you're ok with the change/reviewing it :)

[LinusCDE]

Hi.

Thanks for the great suggestion. I took the liberty to find where to add it myself since I don't consider the code fairly clean and didn't want to subject you to such torture.

I'm new to both rust and the remarkable but would be happy to add a PR if you're ok with the change/reviewing it :)

Nice to have a potentially new rustacian! Rust has a really nice book to learn the concepts with. I found the initial learning curve pretty harsh, but it is a really rewarding one tbh. Another source of note are the rustlings. I didn't use them, but a lot of people recommend them. Especially if you may lack a project to test stuff on.

If you really get involved, you could consider trying out a "basic" tcp game server for this app. I wanted to do this for months and even split the app into kinda client/server.

Details

The file src/proto.rs contains the packets and server logic and src/bin/chessmarkable/scene/game_scene.rs is interacting with it as the client.

proto.rs also contains the packets. enum ChessRequest contains all the packets that a client can send to the server and enum ChessUpdate are the packets the server can send to the client. Both should be already serializable using serde.

The server side logic handles by the function create_game(...) and uses tokios channels to exchange the packets over their channels (basically an async variant of rusts standard MPSC channels).

This would probably require changing some code in the constructor for GameScene to have the channels connect to a TCP Client that serialized and sends the packets to a server. The Server could probably be a fairly simple Tokio TCP Server based on this example which forwards packages to the create_game(...) function.

This could either enable multiplayer or simply run bots on servers with more cpu performance to make them more difficult and faster.

Please don't feel urged to do this. It's just something I might want to do in the future but didn't gotten to do. I personally did a few simple and retrospectively pretty dumb projects (there are better and shorter ways to do this but I didn't know better at the time). While I started really learning rust by porting plato to the rm, it is far better designed and also doesn't touch the async stuff which is probably too much in the beginning.

You can also feel free to just tinker a bit with the chess app. I'm currently not really doing active development on it anymore. So if you add a nice feature/improvement (like the one you suggested here), I would probably be glad to add it.

[LinusCDE]

Fyi, created a new release and a PR for toltec testing.

[rmadhwal]

Thank you! you're too kind. I did a rust crash course which involved the teacher asking us to do rustlings over the 5 days course and indeed did not find them too interesting (or rather didn't align too well with how I like to learn how to code). Learning by working on real projects is more interesting, and I'd love to try my hand at this change if it's not too urgent since I'm fairly swamped at work and will only be making slow progress as a budding Rustacian over the weekends :)

I understand where you're going with your server/client model, though have you considered using the LiChess API, not only could it be easier to create a game for two remarkables to play with, we could also create anonymous games for you to play other users (or perhaps to actually play ranked/normal games with your own lichess account)

[LinusCDE]

Thank you! you're too kind. I did a rust crash course which involved the teacher asking us to do rustlings over the 5 days course and indeed did not find them too interesting (or rather didn't align too well with how I like to learn how to code). Learning by working on real projects is more interesting, and I'd love to try my hand at this change if it's not too urgent since I'm fairly swamped at work and will only be making slow progress as a budding Rustacian over the weekends :)

Not sure if a rust "Crash course" is the best idea. Especially if your prior languages are moderns ones, the concepts seem pretty alien in rust (a lot borrowed from nowadays "dead" languages like lisp and so on). I personally had already learned (Java, Python, JS and a bit of php, C and very little C++ and Ruby). Rust felt like learning programming for the first time again and I could imagine a "crash course" only ending in a frustrating failure. Not sure how it would be as a true first language.

I understand where you're going with your server/client model, though have you considered using the LiChess API, not only could it be easier to create a game for two remarkables to play with, we could also create anonymous games for you to play other users (or perhaps to actually play ranked/normal games with your own lichess account)

I think I had heard of that API a while ago as well. Not sure if I wanted to do my own tcp stuff first or not. The most frustrating part would probably be the UI to log into the account (not sure whether to make it myself, force ssh and config editing or use something like simple for that ui).

It is certainly an interesting idea and I'm open to do that first instead of something custom. The backend would probably be even simpler. In the best case the create_game method could be translated to have the UI be controlled by the same protocol but as an internal proxy or abstraction layer of sorts.