Complete.Org: Mailing Lists: Archives: freeciv-dev: May 2004:
[Freeciv-Dev] Re: (PR#7282) connect as orders
Home

[Freeciv-Dev] Re: (PR#7282) connect as orders

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: jdorje@xxxxxxxxxxxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#7282) connect as orders
From: "Gregory Berkolaiko" <Gregory.Berkolaiko@xxxxxxxxxxxxx>
Date: Mon, 17 May 2004 10:13:08 -0700
Reply-to: rt@xxxxxxxxxxx

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

On Sun, 16 May 2004, Jason Short wrote:

> <URL: http://rt.freeciv.org/Ticket/Display.html?id=7282 >
> 
> Here's an updated version of the patch.  It may actually now be 
> complete.  Certainly it's now ready for testing and review.
> 
> Greg said I should set the MC (move cost) to 1 and put the construction 
> time into the EC (extra cost).  This would choose the path with the 
> shortest number of moves, which is ideal for roads (but not for rail, 
> and certainly not for irrigation).  The EC is used only as a tiebreaker 
> for equal-MC paths, so the shortest-construction-time would be the 
> secondary consideration.
> 
> The problem with this is that the construction time includes the move 
> time, and there is no way to reliably calculate the move time as part of 
> the EC since the extra cost is calculated only per-tile, not per-move. 
> (That is to say, the EC function is given only a single tile, not a 
> source and destination tile.)

You are right...  It's not the first time when extra-cost calculated on 
per-tile basis is a stumbling block!  Maybe we should change it.  Or split 
into tile-extra-cost (cacheable) and move-extra-cost.  It won't affect the 
speed much since it will be disabled most of the time.

Anyway, I think the move-time is usually small compared with the 
build-time, so one soltion is to ignore it.

Another solution is to add a large number to each move cost which will 
force the rest to act as a tie-breaker.  This might not be a bad idea.  
The only worry is how large this number can be not to cause an overflow in
total_CC = PF_TURN_FACTOR * total_MC + move_rate * total_EC
where PF_TURN_FACTOR is 65536

> otherwise works as you'd expect it to.  But I digress.  The immediate 
> solution is to disable PF's turn mode by setting it to TM_NONE.  Now we 
> just calculate the total "moves" required.

Ah, a use for TM_NONE!  Very good (for a moment I was afraid we killed 
it).

G.




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