Re: [Freeciv-Dev] terrain ruleset implementation
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
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!
>I tried it out, and I like it a lot!
>I think it should be a good "bullet point" for the next release :-)
>The main problem is that it does not read old savefiles.
>IMO the server should _always_ read old savefiles as best
>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
Yup, I figured Freeciv would want to progress beyond Civ2.
And data/classic_terrain.ruleset is perfect, since it'll only ever be one
>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
- 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
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...)