Complete.Org: Mailing Lists: Archives: freeciv-dev: July 1999:
Re: [Freeciv-Dev] terrain ruleset implementation
Home

Re: [Freeciv-Dev] terrain ruleset implementation

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Subject: Re: [Freeciv-Dev] terrain ruleset implementation
From: Jeff Mallatt <jjm@xxxxxxxxxxxx>
Date: Mon, 19 Jul 1999 10:35:55 -0400

At 1999/07/19 08:56 , David Pfitzner wrote:
>Jeff Mallatt <jjm@xxxxxxxxxxxx> wrote:
>
>> I started off to make the various terrain types more like those in Civ2...
>> .. What I wound up doing was implementing the terrain ruleset!
>
>>     ftp://dumuzi.codewell.com/pub/prj/freeciv/terrain_patch.tar.gz
>
>I tried it out, and I like it a lot!
>I think it should be a good "bullet point" for the next release :-)
>
>Some comments:
>
>The main problem is that it does not read old savefiles.  
>IMO the server should _always_ read old savefiles as best
>it can.
>
>The attached patch fixes this, I think.  In this case it means 
>using a default value for game.farmfood, and treating the extra 
>specials as zeros.

This is great!

>Also you must save the game.ruleset.terrain 
>string!  I assume that for old-style savegames the "classic"
>terrain.ruleset would be appropriate.

Yes, I forgot.  I've been playing, er.. testing, and found a few bugs.
This is one of them, the rest I'll mention below.

>Concerning the ruleset files, it looks to me now that the
>Civ2 terrain.ruleset is actually the same as the new default.
>So I guess the only reason for introducing it (and the data/civ2
>dir) is for future use?  I guess on reflection I agree that this
>is a good idea.  But the classic terrain.ruleset should be
>data/classic_terrain.ruleset (after my other patch) because the
>classic dir, while still in CVS, is no longer included in the
>tar distribution!

Yup, I figured Freeciv would want to progress beyond Civ2.

And data/classic_terrain.ruleset is perfect, since it'll only ever be one
file.

>Also, it looks like you have the default terrain data both
>compiled into the executable, and in the default ruleset file.  
>In general I am opposed to this duplication, because it means
>that updates to the default set would have to be carefully
>done to both, or become out of sync.  I would prefer just the
>ruleset file, and no default compiled-in terrain data.

Sure.  As you might guess, I first hard-coded the data, and when it all
worked, then worried about reading the ruleset file.  I just left it, but,
you're right, it is useless duplication.  I'll remove it.

>Since this patch breaks old tiles.xpm, I wonder if this would
>be a good time to split tiles.xpm into terrain.xpm and 
>special.xpm?  (Would this be good?  The latter would be 
>numbers, hit-point bars, etc).  And perhaps also give hills, 
>forests and mountains a full terrain line, rather than just 
>four tiles (no vertical continuity).  (Initially the full line 
>could just be duplications of those four, but it would allow 
>for later improvement).  On the other hand I don't think the 
>terrain.ruleset patch should be delayed for this or other 
>unnecessary reasons.  Maybe after terrain.ruleset but before 
>the next release...

Yes!!  I think we sould split tiles.xpm into terrain.xpm and something
else.  However, I, also, didn't want to delay the patch.  As soon as things
got merged, I was going to suggest it...


I've found a few bugs.  Including those mentioned above, they are:

- Remove hard-coded terrain data (mentioned above).

- I forgot to save the game.ruleset.terrain value (mentioned above).

- When a unit can build Farmland, the menu says "Irrigation" -- it should
say "Farmland".

- Under Civ2 rules, river tiles (a.k.a. S_RIVER tiles; Civ1 style rivers
being T_RIVER tiles) should add 1 Trade -- I forgot this.

- I mistakenly disallowed Transforming of S_RIVER tiles.  You should be
able to.


My question is: when would it be easiest for me to submit fixes for these
four bugs (and, for any more bugs I may find specifically in the terrain
ruleset code)?  Should I wait until the patch is merged, then submit diff's
against the latest CVS, or should I make the changes now and submit diff's
against my current copy?  Or, something else?  I'm happy to do whatever
makes the job of Mr. Merge the easiest ;-)  (I've been there...)

jjm


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