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

["Arnstein Lindgard" <a-l@xxxxxxx>]

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

On Thu, 27 Nov 2003 09:26:59 -0800 Mike Kaufman wrote:
> I am against a patch like this. I for one do not like throwing more and
> more crap into the server that really belongs in the client.
> 
> > A single order done in the end of a goto is fine but it sets a precedent.  
> > And soon we might have clients sending python programs to the server and 
> > such.
> 
> I do not like this sam i am.
> It should be in the client.

On Wed, 26 Nov 2003 01:29:20 -0800 Raimar Falke wrote:
> I'm not sure about the generalization here. If I unterstood you the
> patch add a mini-program of the form:
>  1) goto (x,y)
>  2) execute action foobar
> ??
>
> Now one could design a more flexible program. But this is IMHO all
> very unfair since these programs are all executed in the server and so
> the player which uses these programs more gets the more quick
> execution of their actions.
>
> I'm not sure if your patch already has this unfairness.

The mission will be an integral feature of the game; "Orders" renamed
to "Mission Orders", and many players say they like to use it. So I
strongly feel player's convenience (lag, responsiveness) should be
more important than a limited server complication for the coders, for
this particular patch. I would like to commit the current patch with
the understanding that it

- Remains simple, and
- Does not set a precedent for throwing more and more (and more)
  crap into the server.

I would argue this is not a step towards scripting because no
decision making is involved. 15 out of 20 mission orders only
affect unit's "activity" which is not handled at the time.
The consequences of the remaining listed exhaustively below:

enum unit_mission_orders {
  ORDERS_NONE = 0,
  ORDERS_BUILD_CITY,    Creates a new city.
  ORDERS_BUILD_WONDER,  Affects city's production.
  ORDERS_DISBAND,       May affect a city's production.
  ORDERS_HOMECITY,      Affects city's support.
  ORDERS_TRADEROUTE,    Affects city.
  ORDERS_UNLOAD         (un-sentries other units)
  ORDERS_AIRBASE,       (activity)
  ORDERS_AUTO_ATTACK,   (activity)
  ORDERS_AUTO_EXPLORE,  (activity)
  ORDERS_AUTO_SETTLE,   (activity)
  ORDERS_FALLOUT,       (activity)
  ORDERS_FORTIFY,       (activity)
  ORDERS_FORTRESS,      (activity)
  ORDERS_IRRIGATE,      (activity)
  ORDERS_MINE,          (activity)
  ORDERS_PILLAGE,       (activity)
  ORDERS_POLLUTION,     (activity)
  ORDERS_ROAD,          (activity)
  ORDERS_SENTRY,        (activity)
  ORDERS_TRANSFORM,     (activity)
};

Already, there are 2 such cases of server handling that I can think of:

1) As Thomas poitned out, attacking is integral part of the goto.

2) The activity "auto explore" has special handling in

  server/unithand.c: handle_unit_change_activity():
    {
    ...
    /* Exploring is handled here explicitly, since the player expects to
     * see an immediate response from setting a unit to auto-explore.
     * Handling it deeper in the code leads to some tricky recursive loops -
     * see PR#2631. */
    if (punit->moves_left > 0 && activity == ACTIVITY_EXPLORE) {
    ...
    }

Mission Order execution will be handled from one of three
places in the server:

1. handle_unit_goto()      (received goto without a route)
2. handle_unit_route()     (received goto with a route)
3. update_unit_activity()  (at the end of turns)


Arnstein