ChessUSA.com TalkChess.com
Hosted by Your Move Chess & Games
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

@HG: auto moveing and lift,put,drag
Post new topic    TalkChess.com Forum Index -> Computer Chess Club: Programming and Technical Discussions Flat
View previous topic :: View next topic  
Author Message
Daniel Shawul



Joined: 14 Mar 2006
Posts: 2275
Location: Ethiopia
PostPost subject: Re: @HG: auto moveing and lift,put,drag    Posted: Fri Jun 01, 2012 5:07 pm Reply to topic Reply with quote
hgm wrote:
Somewhat better internet access today! Cool

Welcome back
Quote:

I am not sure how exactly your current implementation is. (I.e. does your GUI only send something to the every on button press events, or also for button release?)

It sends only one click on a Mouse pressed event (none on release). Pressed-hovered-released are required only when are going to make a move leg by leg, with the clicks method any click pattern of randomly sorted squares of the move will do. For hovering, a piece has to be clicked first.

Quote:

But let me explain what I am concerned about:

I fully understand that drag-drop is cumbersome/undesirable of smart-phone devices. But that should just mean that a smart-phone GUI does not allow the user to perform drag and drop, and thus will never send the corresponding commands (such as 'hover') to the engine. But there are other GUIs running on more powerful hardware, where drag-drop is preferred, and both the protocol and the referee should also support that. It is not clear to me that this is the case in your current referee implementation.

The referee i.e Nebiyu has all the previous code, only my simplistic gui for android doesn't provide support for hover. The guis click are meant to indicate selected squares to the referee.
Quote:

It seems to me that it can never hurt to diversify the GUI->Engine 'click' command into two flavors: press and release. The GUI would normally drag pieces that you click, if they are of the side to move. I am not sure if that requires more smartness than even a dumb GUI provides. It seems the GUI must have an idea of who is to move, or it could not maintain the clocks. But it could be that it is enough to let the GUI send a 'click' command for every release event on a different square than the corresponding press (and stay silent if the up-click is on the same square). But the engine would never know when exactly you are dragging, and this might be a problem (e.g. how to respond to 'hover'). In WinBoard I use a release on a different square to clear any highlights (because the leg of the move for which the highlights were intended is now finished), so that the engine never has to worry about clearing highlights. On a static click the highlights stay on after the release event, however, because the leg entry has still to be completed by a second click.

Yes i could have used 'put' instead of new command 'click' I guess. I am not sure why but the code for the lift-put-hover in nebiyu is complicated. I suspect it is because winboard doesn't use an external referee, and the engine playing the same game is used as referee. So I had to keep a different search stack , keep track of commas and other things... So rather than modifying that I prefred to use a different command 'click' and do a simple comparsion of list of clicked squares to check which moves have them. ALSO the response from the refree in case of click is different from the 'put' of the previous version. Now the refree is sending moves back to the gui , so a new command was necessary.
Quote:

Another requirement I would like to impose is that the system can still provide basic functionality without a special referee engine, i.e. using an engine that supports nothing but original WB protocol. (In which case the engine should be able to act as its own referee.) You would lose the highlighting and one-click moving, for sure, but these are merely frills. Move entry and legality checking should always work, though. So there must be some simple default mechanism for the GUI to synthesize moves from the clicks, without using any rule knowledge.

Yes a bug I made and still didn't fix is that in FICS mode I do not use the refree. After I reverted to this new way, the app started crashing because even in FICS mode it needs refree! Well I added the previous code that sends moves on the 2nd click, and constructs them in plain e2e4 notation.
But this is not good because other games with 3 or more clicks could be served, and also complete lack of highlighting. A more serious problem I observed is that boards are not displayed until servers sends them so it could do away with a refree that will update the board as soon as the human enters the moves... So I am thinking to use a referee as well. Without the referee you can only come up with solutions that are good for a specific kind of game.
Quote:

I agree that the Ctrl key for partial moves is a pain, though. (I'd much rather use it for something else...) Making the engine or referee responsible for this would be nice. I am just not sure that this is always possible, though. Take again the example of the Chu-Shogi Lion. It can do two King moves (even if both are captures) in one turn. But it can also do just one. So how can you enter that? After clicking Lion and first victim there is already a legal move, but there could also be a continuation (eight, actually). But if you want to stop there, how can you tell it to the engine?

Good question I didn't notice that ..
Quote:

I guess reverse entry could be a convention to make this work. Click any number of empty or opponent squares before you click a piece of your own, and it will capture them all with a multi-leg move (i.e. send 'usermove LEG1,LEG2,LEG3,...' to the engine). With an engine that supports 'click' there would be much more flexibility: the GUI could send the individual squares in any order, and keep that up until the engine/referee responds with 'move' (in the mean time performing highlighting as requested). An engine would be aware of the possible ambiguities in move termination, and could apply its own conventions to resolve them (e.g. to terminate entry that might have continued, click the same piece again as last time).

I will think about this for a while. It seems to me that some signaling maybe requrired to make the shorter move, since the longer continuations always contains the squares in side the shorter ones. Otherwise it will get stuck (never makes a move) because it can't resolve it. We can use 'clicking on the from' square _again_ as a signal to tell it to make the move now, that means the move that contains exactly all the squares that are clicked and no more. Is that what you meant ?

Quote:

Problems I don't clearly see a solution for at the moment are:
- With reverse multi-leg entry, how can you force a reset of the entry process after the user makes an erroneous click? (Both with stand-alone GUI or engine-mediated.) It should always be possible for the user to change his mind before the full move is committed. Perhaps also click the last selected target a second time, just as WB allows you to click your own piece a second time to deselect it? I guess multiple (square-border or arrow) highlights could be supported, that go on even if you click opponent pieces or empty squares, and would all go off on a deselect click.

That is implemented already. If the user make a wrong continuation, Nebiyu resets its clicked squares list that it keeps inside and the clicking is restarted from the last square. This works already.
Quote:

- If the user does want one-click moving to be off, how to achieve that? It would be nasty if a click-supporting engine has to know it is off, yet a GUI would have to send all the clicks to evoke highlighting responses. Just shelve the referee's move until the user has clicked all the squares stipulated by the move? And send 'undo' if he aborts or deviates?

I see. We will have to think a way for that. Right now I turn both on or off..
Quote:

- It would be nice if highlighting could somehow be used to determine clicks illegal already in the GUI: waiting for an 'Illegal move' engine response to undo the just entered move produces notable glitches in the display.

I forgot how we used highilight to mark illegal squares in the previous method. I guess that was on hover or not? Anyway this is another thing to discuss.
_________________
https://sites.google.com/site/dshawul/
https://github.com/dshawul
Back to top
View user's profile Send private message Visit poster's website Yahoo Messenger
Display posts from previous:   
Subject Author Date/Time
@HG: auto moveing and lift,put,drag Daniel Shawul Sun May 27, 2012 3:28 pm
      Re: @HG: auto moveing and lift,put,drag Daniel Shawul Sun May 27, 2012 11:06 pm
      Re: @HG: auto moveing and lift,put,drag H.G.Muller Tue May 29, 2012 8:27 am
            Re: @HG: auto moveing and lift,put,drag Daniel Shawul Tue May 29, 2012 2:46 pm
                  Re: @HG: auto moveing and lift,put,drag H.G.Muller Tue May 29, 2012 3:36 pm
                        Re: @HG: auto moveing and lift,put,drag Daniel Shawul Tue May 29, 2012 4:23 pm
                              Re: @HG: auto moveing and lift,put,drag H.G.Muller Wed May 30, 2012 7:29 am
                                    Re: @HG: auto moveing and lift,put,drag Daniel Shawul Wed May 30, 2012 9:12 pm
                                          Re: @HG: auto moveing and lift,put,drag H.G.Muller Fri Jun 01, 2012 3:51 pm
                                                Re: @HG: auto moveing and lift,put,drag Daniel Shawul Fri Jun 01, 2012 5:07 pm
                                                      Re: @HG: auto moveing and lift,put,drag Daniel Shawul Fri Jun 01, 2012 9:10 pm
                                                      Re: @HG: auto moveing and lift,put,drag Daniel Shawul Sun Jun 03, 2012 1:27 pm
                                                            Re: @HG: auto moveing and lift,put,drag H.G.Muller Sun Jun 03, 2012 2:29 pm
                                                                  Re: @HG: auto moveing and lift,put,drag Daniel Shawul Sun Jun 03, 2012 2:46 pm
                                                                        Re: @HG: auto moveing and lift,put,drag H.G.Muller Sun Jun 03, 2012 6:13 pm
                                                                              Re: @HG: auto moveing and lift,put,drag Daniel Shawul Sun Jun 03, 2012 7:44 pm
                                                                                    Re: @HG: auto moveing and lift,put,drag H.G.Muller Mon Jun 04, 2012 4:05 am
                                                                                          Re: @HG: auto moveing and lift,put,drag Daniel Shawul Mon Jun 04, 2012 11:27 am
                                                                                          Re: @HG: auto moveing and lift,put,drag H.G.Muller Mon Jun 04, 2012 4:06 pm
                                                                                          Re: @HG: auto moveing and lift,put,drag Daniel Shawul Tue Jun 05, 2012 12:51 am
      Re: @HG: auto moveing and lift,put,drag Engin Üstün Sun Jun 03, 2012 3:49 pm
            Re: @HG: auto moveing and lift,put,drag Daniel Shawul Sun Jun 03, 2012 4:34 pm
                  Re: @HG: auto moveing and lift,put,drag Engin Üstün Sun Jun 03, 2012 5:26 pm
                        Re: @HG: auto moveing and lift,put,drag Daniel Shawul Sun Jun 03, 2012 9:46 pm
                              Re: @HG: auto moveing and lift,put,drag H.G.Muller Mon Jun 04, 2012 3:49 am
Post new topic    TalkChess.com Forum Index -> Computer Chess Club: Programming and Technical Discussions

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum




Powered by phpBB © 2001, 2005 phpBB Group
Enhanced with Moby Threads