[Freeciv-Dev] (PR#4683) allow pauses during client-side goto

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

[jdorje - Wed Aug  6 02:31:29 2003]:

> [jdorje - Fri Jul 25 09:54:33 2003]:
> 
> > ChrisK@xxxxxxxx wrote:
> > > On Fri, Jul 25, 2003 at 01:52:16AM -0700, Jason Short wrote:
> > >
> > >
> > >>+       * for tririemes.  FIXME: we shouldn't lose the movepoints
> > but should
> > >>+       * instead return GR_WAITING and just sit tight. */
> > >
> > >
> > > I think that, too. :-/
> > 
> > This may do the trick.  It's a little riskier; I'm not sure if
> > GR_WAITING needs special handling anywhere.  It also takes client
> > changes to get the focus to advance properly - I think these changes
> > are
> > fundamentally sound but may cause problems in other situations.
> 
> The second patch here is buggy.  If you execute a goto the focus will be
> advanced, and if that goto runs to completion you'll erronously have the
> next unit focused rather than the unit that just finished its goto.
> 
> I'm not sure how this can be solved using client-side focusing.

When a goto is executed, the client must decide whether to advance the
focus or not.  Currently it does not.  If it did (as in the patch), then
we once a goto was completed we'd be stuck with the wrong unit focused
(the gotoing unit should be focused).  But if it doesn't, then a unit
that completes its goto for this turn but still has some moves remaining
will still be the active unit.  Neither situation is acceptable.

I see only two solutions using client-side focusing, and both have
drawbacks.

One method is to have the server take away all of the unit's MP when it
pauses its goto.  This is the way my earlier goto-pause patch works, and
it lets the client know to advance the focus.  The drawback, of course,
is that it steals MP that the player may want to use.

Another method would be to advance the focus when the goto starts, but
return it if the goto is completed.  Now we would have an invariant that
no unit on goto would ever be focused (which is probably a good thing;
currently with a high-lag connection some weird things can happen).  The
drawback is that when we advance the focus the screen will jump, and
will jump back (and stay there) when the goto is actually executed.

The third solution, of course, is to use server-side focusing.

Of these, only the first seems workable to me.

jason