Complete.Org: Mailing Lists: Archives: freeciv-dev: May 2000:
[Freeciv-Dev] Re: goto cleanup
Home

[Freeciv-Dev] Re: goto cleanup

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: goto cleanup
From: Falk Hueffner <falk.hueffner@xxxxxxxxxxxxxxxxxxxxxxxx>
Date: 23 May 2000 18:37:29 +0200

Thue Janus Kristensen <thue@xxxxxxx> writes:

> Once again - getting close to acceptable.
> 
> Does:
> -Remove code from find_the_shortest_path that tried made sure units
> moving from a transport could move due to ZOC. (units can always move fro
> ocean onto land.)
> -Rewrite/remove horribly tangled dir_ok/dir_ect.
> -integrate the used parts of some functions into the part of
> find_the_shortest_path that used them (each only used a small part), and
> move the functions to aiunit.c as they were used by other functions there.
> -Rewrite the handling of RR loops. I am not wholly sure how they were
> avoided before, but from what I could understand this is at least as
> smart.
> -Rename lots of variables
> -Document document document.

Thanks for cleaning this up a bit. I have some comments:

The comments mention the algorithm is A*, but that is not possible
because railroads defeat any lower bound for target distance. It
actually looks like Dijkstra's algorithm to me.

The code for loop detections seems very complicated. Also, couldn't
"Assign a cost >0 (1) to movement on RR in the opposite direction of
the +destination" lead to nonoptimal solutions?

I wonder if it wouldn't be easier to simply add a small constant to
the move costs on every move (with maxMoves * constant < 1). That
would also have the nice effect that for costwise equivalent paths, it
would choose the one with the least number of moves. This could be
implemented either with floats or by pre-shifting the move costs by,
say, 16 and using 1 as constant.

        Falk




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