Complete.Org: Mailing Lists: Archives: freeciv-dev: January 2004:
[Freeciv-Dev] Re: (PR#6941) Mission Orders
Home

[Freeciv-Dev] Re: (PR#6941) Mission Orders

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: a-l@xxxxxxx
Subject: [Freeciv-Dev] Re: (PR#6941) Mission Orders
From: "Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>
Date: Wed, 28 Jan 2004 13:57:15 -0800
Reply-to: rt@xxxxxxxxxxx

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

Arnstein Lindgard wrote:
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=6941 >
> 
>>On Wed, 28 Jan 2004 10:42:25 -0800 Jason Short wrote:
>>
>>
>>>struct unit_order {
>>>   enum orders_type type;
>>>   union {
>>>     enum unit_orders order;
>>>     enum unit_activity activity;
>>>     enum unit_actions action;
>>>     enum diplomat_actions diplomat;
>>>   } order;
>>>   enum direction8 dir;
>>>}
>>
>>...
>>
>>>If the type doesn't need to be associated with the union, how do you 
>>>tell which type the union is?
> 
> 
> Sorry, I missed that point. "type" is what I want to introduce
> to hold
> 
> enum orders_type {
>   GOTO_ORDERS, PATROL_ORDERS, STATIONARY_ORDERS
> };
> 
> I previously suggested changing "has_orders" from a bool into
> such a 3-item enum because my client needs more info, and you
> said I should expand the unit struct. It's got nothing to do
> with the union.

Ahh, yes.

I think it would be better to have the client infer this information 
from the route itself.

E.g. if the next order is a move, then use either goto or patrol sprite. 
  Otherwise use stationary patrol sprite.

The client is then free to introduce new categories.  The only drawback 
is that the client doesn't currently know the route.  So as long as this 
remains the case the enumeration is the way to go.

jason




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