Complete.Org: Mailing Lists: Archives: freeciv-dev: August 2001:
[Freeciv-Dev] Re: [PATCH] Corecleanup_07Part1 has been put in incoming
Home

[Freeciv-Dev] Re: [PATCH] Corecleanup_07Part1 has been put in incoming

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: rf13@xxxxxxxxxxxxxxxxxxxxxx
Cc: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>, freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: [PATCH] Corecleanup_07Part1 has been put in incoming
From: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Date: Sun, 26 Aug 2001 15:28:46 -0400

At 06:36 PM 01/08/26 +0200, Raimar Falke wrote:
>On Sun, Aug 26, 2001 at 10:42:30AM -0400, Ross W. Wetmore wrote:
>> If the search distance is 1 this looks like it doesn't search.
>In both cases (the old one and the my new one) it loopes over one
>tile.
>> That would be counter-intuitive, and a completely different idea of
>> search distance than used elsewhere.
>
>Maybe, but thats another problem.
>
>> But a blind update is as you sugggest. I think there is a fix needed
>> here somehere though. 
[...]
>I don't understand.

I think at the point in question, the AI is trying to find a place to 
unload units that are to march on an inland city generally some squares 
away. 

In this case it appears to want to find a landing square that is "closer"
than the current ship position. This is ok, but finding a square that is
"as close as" is just as reasonable.

In the case where the sea unit is adjacent to the city, this will never
find a landing place though, as the only "closer" square is inside the city.

To make the function generally applicable, it should use the standard
definition of distance as a distance of "1" is adjacent tiles, and not
the current tile.

I think the submitted code "fixes" the bug and does this correctly.

>       Raimar
>-- 
> email: rf13@xxxxxxxxxxxxxxxxx
> "USENET is *not* the non-clickable part of WWW!"

Cheers,
RossW
=====




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