From: Alexander W. <a.w...@ph...> - 2008-11-16 17:33:13
|
Pierre Boulenguez wrote: Hello Pierre! Nice to hear from you again! :) Admitting that I've ben just to busy for "professional" reasons, and thus a bit silent myself for quite a while. > Indeed sending a string to the clock is not implemented > yet. Noticed that :) Now that I've the possibility to play arround with a clock it came to my mind to try. But besides sending a string like "Nf3" to the clock, it would IMHO be of much greater value if one could use "Mode 23", that is set the timing on the clock by an external source. This would be very handy for playing on FICS e.g. where Scid makes a pretty good client these days and it could also come in handy for the playing functionality that got added to Scid recently as well. However, for the latter I'm about to add also the inverse, ie. that the external clock can be used to set Scids internal game clocks, as the DGT clock offers much more flexibility today than Scids timing functions. > Regarding the clock, do you mean that when the clock is > pluged to the board but the power switch is turned off, > dgtnix returns 'not present' ? If so, it's not a bug, > just a lack of documentation. No. If I plug to clock to the board, turn it on but not yet start it, it reports "not present". That is the clock is there but just halted. That is everything is ready for a match. The point is not entirely catastrophic as I get a time event once the clock starts running, but it takes me the possibility to present a nice button to the user "Use external time source" which I could disable if no clock is found. However, it gets critical once I could use Mode 23, cause then I'd have to set one time reference. Ah, and I also noticed a slight inconvenience while handling the board descriptor. As both, the clock and the move events come in on the same descriptor, a half move however consists of two board events (remove piece and place piece) I usually see at least one clock event between the two events for a move, simply cause the clock event comes in every second at the least. This gets even worse for casteling, where a single ply consists of 4 board events. It took me a while to fiddle all these incoming events apart without deadlocking the move recognigion. Things would IMHO be easier if the clock events would come in via a separate descriptor, or the clock would not generate any events on the descriptor but move the time information dgtnixGetClockData(). The API is a bit inconsistent here (IMHO), as there is actually no need to see the bare clock events as there is a nice function that delivers them in usable form. My first approach was to set the board to UPDATE_BRD instead of UPDATE. Funny enough this got me the clock hooked of entirely, though I tried to send a DGT_SEND_CLK before invoking dgtnixGetClockData(). (BTW: there seems a function missing that allows to send bare DGT commands to the board.) I was a bit confused here and then resorted back to fiddling appart the both event types in my own code. BTW: The clock I've here is version 1.14, according to the imprints, my boards electronics is 1.9. -- Kind regards, / War is Peace. | Freedom is Slavery. Alexander Wagner | Ignorance is Strength. | | Theory : G. Orwell, "1984" / In practice: USA, since 2001 |