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

["Gregory Berkolaiko" <Gregory.Berkolaiko@xxxxxxxxxxxx>]

On Fri, 29 Aug 2003, Jason Short wrote:

> 
> 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.

How about not focusing on units which have ACTIVITY_GOTO?
Yeah, ok this you did in the patch and it didn't work, but the client must 
be told at some point that the unit has changed the activity from 
ACTIVITY_GOTO to ACTIVITY_IDLE, and at this point you may want to return 
the focus to the unit, rather then have it on all the time.

This should be done carefully as there is a possibility of jumping 
focus.  Ugh, now I actually read your email and this is what you wrote...

Another way is to explicitly tell the client that the unit is waiting.  
Either by adding an extra field to unit_info packet or by recycling the 
activity_count field.

G.

> 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