Complete.Org: Mailing Lists: Archives: freeciv-dev: September 2001:
[Freeciv-Dev] Re: [PATCH] Cleaned up magic code ingotohand.c (PR#944)
Home

[Freeciv-Dev] Re: [PATCH] Cleaned up magic code ingotohand.c (PR#944)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: jdorje@xxxxxxxxxxxxxxxxxxxxx
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: [PATCH] Cleaned up magic code ingotohand.c (PR#944)
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 10 Sep 2001 11:51:04 +0200
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Mon, Sep 10, 2001 at 01:25:28AM -0400, Jason Dorje Short wrote:
> "Ross W. Wetmore" wrote:
> > 
> > dir_ok and straightest direction are both buggy in the same way.
> 
> Actually, I think straightest_direction has an extra bug.  Even if
> you're moving directly in a cardinal direction, it will move you
> diagonally if possible.
> 
> > The best thing is to replace them, not fix magic numbers and then
> > throw out the fixes when you replace the whole routine :-).
> 
> They definitely need to be replaced.  However, fixing the magic numbers
> is so easy there's no reason not to do it first.
> 
> > However, I wouldn't even do this patch until you apply the rotation
> > direction patch, as it doen't really gain you anything.
> 
> Huh?  Do you mean this patch I submitted?  It gets rid of the magic
> numbers, making the code more stable and easier to read.
> 
> > The algorithm in the corecleanups works by dividing the full square
> > into 8 octants using the 2x+y, 2y+x, 2x-y and 2y-x lines as borders.
> 
> Well, that's a good algorithm.  It's hard to understand from your
> diagram and paragraph, but I agree entirely with what you're saying.
> 
> straightest_direction has units currently moving like this for goto
> routes:
> 
> X is a unit
> Y is the target
> * is the route
> 
> X     Y
>  *   *
>   * *
>    *
> 
> In other words, it strongly prefers to move on a diagonal.  Your
> algorithm would correct this behavior.
> 
> 
> However, I think an even better algorithm might be possible.  Your
> algorithm is a huge improvement, but will still result in the unit
> traveling in either a cartesian direction or a diagonal one to get to a
> place where it's a straight cartesian/diagonal route:
> 
>   
> X****
>      *
>       *
>        Y
> 
> or
> 
> X
>  *
>   *
>    *
>     ***Y
> 
> The "best" algorithm, I think, would have a unit traveling into as close
> to a straight line as possible:
> 
> X
>  **
>    **
>      **
>        Y
> 
> I believe this algorithm would be substantially more complicated,
> though, whereas yours should still be pretty simple.

You have here flexibility which you should give to your caller. The
caller may want to move at the edge of known-unknown area or may want
to prefer safer route.

        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]