Complete.Org: Mailing Lists: Archives: freeciv-dev: January 2004:
[Freeciv-Dev] Re: (PR#7131) client orders to replace client goto
Home

[Freeciv-Dev] Re: (PR#7131) client orders to replace client goto

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: jdorje@xxxxxxxxxxxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#7131) client orders to replace client goto
From: "Raimar Falke" <i-freeciv-lists@xxxxxxxxxxxxx>
Date: Sat, 17 Jan 2004 00:32:18 -0800
Reply-to: rt@xxxxxxxxxxx

<URL: http://rt.freeciv.org/Ticket/Display.html?id=7131 >

On Thu, Jan 15, 2004 at 07:09:21PM -0800, Jason Short wrote:
> 
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=7131 >
> 
> Raimar Falke wrote:
> > <URL: http://rt.freeciv.org/Ticket/Display.html?id=7131 >
> > 
> > On Sun, Jan 11, 2004 at 07:04:59AM -0800, Jason Short wrote:
> > 
> >>>>+  p.dest_x = punit->x;
> >>>>+  p.dest_y = punit->y;
> >>>>+  send_packet_unit_orders(&aconnection, &p);
> >>>
> >>>What is the purpose of the dest_* fields?
> >>
> >>Well, there's a slight ugliness since the movement orders don't 
> >>include positions.  So it's not particularly easy to recalculate the 
> >>ending position of the orders list.  These values simply provide the 
> >>ending position to the server.  This is needed so the goto_dest may be 
> >>set.
> >>
> >>If we were going to calculate the ending position manually at the 
> >>server, these values would still be useful as a safeguard.
> > 
> > Hmmm. So we agree that these values should be removed eventually when
> > the server sends the orders back to the client?!
> 
> Probably so.  Of course they may be useful even then, since they cannot 
> easily be recalculated from the list of orders.

Come on. This is a for loop over MAPSTEP.

> >>>I would also rename ORDER_WAIT to ORDER_FINISH_TURN. "Wait" is too
> >>>general.
> >>
> >>It corresponds to the "wait" command at the client.
> > 
> > 
> > But wait IS too general. Will it wait till a certain condition is met? 
> > Is it really an abort? FINISH_TURN makes this clear.
> 
> How about WAIT_ONE_TURN?

Some people could read this as WAIT_NEXT_TURN. Better would be
WAIT_THIS_TURN.

        Raimar
-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 Make a software that is foolproof, and only fools will want to use it.




[Prev in Thread] Current Thread [Next in Thread]