Complete.Org: Mailing Lists: Archives: freeciv-dev: January 2004:
[Freeciv-Dev] Re: (PR#6931) Goto waypoint bug
Home

[Freeciv-Dev] Re: (PR#6931) Goto waypoint bug

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: a-l@xxxxxxx
Subject: [Freeciv-Dev] Re: (PR#6931) Goto waypoint bug
From: "Raimar Falke" <i-freeciv-lists@xxxxxxxxxxxxx>
Date: Sat, 24 Jan 2004 23:59:16 -0800
Reply-to: rt@xxxxxxxxxxx

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

On Sat, Jan 24, 2004 at 10:56:35PM -0800, Jason Short wrote:
> 
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=6931 >
> 
> > [ali - Sun Nov 23 16:25:51 2003]:
> > 
> > Bug: maybe_cancel_goto_due_to_enemy() should idle the unit,
> > like in maybe_cancel_patrol_due_to_enemy().
> > 
> > Otherwise, unit retains the goto state when a non-attackable unit
> > unexpectedly exists on a waypoint (only when using waypoint).
> 
> The goto (now orders) returns GR_FAILED.  If this happens then the goto
> should be canceled; the unit will be left in idle.  It looks like the
> goto/orders function expects the caller to do this, but of course the
> caller doesn't.
> 
> Execute_orders should just return a bool indicating whether the unit
> survives.  Any other handling should be done within the function. 
> Perhaps a wrapper function would be helpful (to handle the different
> return values).  If not then the GR_*** enumeration can just be dropped.

I'm for the wrapper. Else the functions grow too much.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "At the beginning of the week, we sealed ten BSD programmers
  into a computer room with a single distribution of BSD Unix.
  Upon opening the room after seven days, we found all ten programmers 
  dead, clutching each other's throats, and thirteen new flavors of BSD."




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