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: Tue, 13 Jan 2004 01:02:47 -0800
Reply-to: rt@xxxxxxxxxxx

<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?!

> > > +  punit->has_orders = packet->has_orders;
> > > +  punit->orders.repeat = packet->repeat;
> > > +  punit->orders.vigilant = packet->vigilant;
> > 
> > The has_orders field could be moved into the orders struct.
> 
> COuld be, yes.  Is there any advantage to doing so?

It is cleaner.

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

> To do it would be simple: simply send the orders list back to the 
> client.  Changes to the drawing code to draw the orders are a little 
> more complicated.  Deciding how the user interface would work is 
> probably the biggest problem.  I think clicking on a unit should not 
> cancel the orders, but rather activate the unit and cause the existing 
> orders to be displayed.

In the current code the goto destinaition is shown if you press the
middle-mouse button. I think this can be reused. At least I did so for
the goto-agent.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "The BeOS takes the best features from the major operating systems. 
  It's got the power and flexibility of Unix, the interface and ease 
  of use of the MacOS, and Minesweeper from Windows."




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