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

["Jason Short" <jshort@xxxxxxxxxxxxxx>]

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

Arnstein Lindgard wrote:
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=7131 >
> 
> On Sun, 4 Jan 2004 23:19:30 -0800 Jason Short wrote:
> 
>>Here's a first implementation of client orders.
> 
> 
> 1)
> 
>>ACTIVITY_GOTO is dropped for use with client goto (it is still used for 
>>server goto, but server goto should become deprecated when client-side 
>>air goto is implemented).  Instead a unit on client orders may have any 
>>activity (it will be ACTIVITY_IDLE for standard goto) and has 
>>punit->has_orders set.  But a unit on a connect orders may have, for 
>>instance, ACTIVITY_ROAD instead.
> 
> 
> I'll define a "mission order" as an order to be executed only on the
> last position in the path. Some sprites are involved.

Very well.  This is a client-side issue only.  Once orders are fully 
implemented in the server the client should be able to do whatever it 
wants (the only problem is providing a suitable user interface).

> My interpretation is that you intend activity to be used for
> connecting workers, and for mission orders I'd expand this
> 
> enum unit_orders {
>   ORDERS_MOVE, ORDERS_WAIT
> };
> 
> with items that duplicate allowed "activities", plus a few more like
> build city. Or maybe use a union that includes unit_activity or
> unit_orders.

Yes.  I see two ways to do it:

1.  Add a new ORDERS_ACTIVITY, with a new enum activity_type variable 
added to the orders struct.  This allows you to specify any "activity" 
for the unit to do.  Of course not all activities are valid.  Additional 
orders (like build-city) would be handled independently 
(ORDERS_BUILDCITY).  Caravan and diplomat actions may be handled via 
their own enums; I'm not sure.

2.  Add each order independently.  This gives you a long list of orders: 
ORDERS_ROAD, ORDERS_IRRIGATE, ORDERS_BUILDCITY, etc.  It is potentially 
less elegant than method #1 because the overlap between orders and 
activities, but may be safer since some activities won't be included.

Not sure which is best.

> 2) Maybe a patroller should go into waiting instead of covering the
> same distance twice or more on the same turn, when moves left is
> greater than route distance.

It's supposed to be like that already.

> 3) I suggest expanding the boolean "has_orders" into an enum:
> 
> enum order_types {
>   OTYPE_NONE = 0, OTYPE_GOTO, OTYPE_STATIONARY
> };
> #define unit_has_orders(punit)        \
>   ((punit)->has_orders > OTYPE_NONE)
> 
> so that the client knows whether to display the "G" sprite, since
> you're removing ACTIVITY_GOTO. For the Mission orders patch, a
> settler retains a "B" sprite for one turn after reaching the
> destination, because he needs a MP to found city. Ie on the last turn
> there should only be a "B" and no "G". Also then we could have a
> queue of orders to be executed on the same tile, and maybe a new
> sprite other than "G".

I don't think that's good.  The client can use its own logic to 
determine which graphic to show.  If new values are to be added (because 
the client needs more data) they should be to a new enumeration within 
the client->orders struct:

   /* used by the client to know what to display. */
   enum orders_type {
     OTYPE_GOTO, OTYPE_PATROL, OTYPE_STATIONARY
   }

But this is mostly a question of semantics.

(As a side note, I don't think a "G" should be displayed for units on 
mission orders.  The user should visually see that this isn't a simple 
goto.)

jason