Complete.Org: Mailing Lists: Archives: freeciv-dev: January 2004:
[Freeciv-Dev] Re: (PR#7259) new function tile_has_river
Home

[Freeciv-Dev] Re: (PR#7259) new function tile_has_river

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: jdorje@xxxxxxxxxxxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#7259) new function tile_has_river
From: "rwetmore@xxxxxxxxxxxx" <rwetmore@xxxxxxxxxxxx>
Date: Sun, 18 Jan 2004 06:21:17 -0800
Reply-to: rt@xxxxxxxxxxx

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

I think you are correct. The issue is one of the extent of code cleanup vs
value derived.

The initial implementation used T_RIVER, but I believe was later enhanced
to use the S_RIVER special allowing any tile to have river properties. The
implementation now includes both flavours. I am sure that changing the
implementation to drop the T_RIVER tile type is only an implementation issue.
It would have the benefit of increasing the available basic tile types by 1.

Your Civ1 restriction on creating is of course required but shouldn't be too
difficult an implementation. Even better might be extending it to a ruleset
defined bitmap of the 15 base tile types in the process, i.e. trivial
extension of the test logic with a little ruleset work to manage it.

Cheers,
RossW
=====

Jason Short wrote:
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=7259 >
> 
> This patch adds a function tile_has_river.  It simply checks for T_RIVER 
> and S_RIVER.  This clears up the logic in several places in the code.
> 
> On that note, what is the purpose of T_RIVER?  The impression I get is 
> that this is just used for civ1 compatability.  But this could easily be 
> accomplished just by restricting S_RIVER to grassland tiles (if that 
> level of compatability is even desired).
> 
> jason




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