🚀 go-pugleaf

In article <3A930A08.EA39FA05@wretched.demon.co.uk>,
Simon Waters  <Simon@wretched.demon.co.uk> wrote:
>Tim Mann wrote:
>
>> * Modified premove again.  Now we are back to displaying the move
>> locally immediately after sending it to the server, as in versions
>> prior to 4.2.1.  This is good because it lets you register your next
>> premove sooner.
>
>Sorry - does this mean you can register multiple premoves - or is this
>only if it is the same piece?

No, you can't register multiple premoves at once.  Here is a little more
detail on what the change log entry means.

In 4.2.3, when your opponent's move arrives and you have a premove 
reply registered, the sequence of events is:

 1) receive opponent's move
 2) show opponent's move on board (not animated, even if animation is on)
 3) send your premove reply to server
 4) show your reply on board (animated, if animation is on)
 5) at this point, you can make another premove

In 4.2.0 and earlier, it was the same, except that in step 2 the opponent's
move was animated (if animation was on).  The animation takes time, which
comes off your clock.  Thus the change.  This problem was pointed out by
DAV of FICS.

In 4.2.1 and 4.2.2, there was a different attempted solution for this problem,
but it was a bad idea.  The sequence of events was:

 1) receive opponent's move
 2) send your premove reply to server
 3) show opponent's move on board (animated, if animation is on)
 4) wait for the server to echo your reply back to you
 5) show your reply on board (animated, if animation is on)
 6) at this point, you can make another premove

This was bad because step 4 could take a long time (not to mention the
time taken by the animation in 3 and 5), so you could not make your next
premove as quickly as you might like.  In fact, if you tried to make your
next premove during step 4, it would get sent to the server as a normal
move, and you'd get an "It's not your turn" error.  Very bad.

	--Tim

-- 
Tim Mann  tim.mann@compaq.com  http://www.tim-mann.org
Compaq Computer Corporation, Systems Research Center, Palo Alto, CA