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

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

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

Morgan Jones wrote:
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=7259 >
> 
>>>So we agree that we want to remove the T_RIVER terrain type?! I'm
>>>for it. Less special cases.
>>
>>Drawbacks:
>>
>>- Incompatability with civ1 tilesets.
>>
>>- Future incompatability with civ1 saved games.
>>
>>Does anyone care about this?  I suspect not.
> 
> The way to do it would be to write a script or something to 'fix' Civ1
> saved games and/or tilesets to work with Freeciv.

Well, that's easy enough.  Support for this can go into savegame.c, 
converting the "old" T_RIVER into the "new" grassland + S_RIVER.  This 
corresponds to a change in the code, not (specifically) a change in the 
ruleset.

But we still have the problem that if a ruleset is changed things will 
break.  For instance, if the terrain listings (enum tile_terrain_type = 
{T_RIVER, ...}) is removed from the code and all terrain is put directly 
into the ruleset, then simply reordering the terrain in the ruleset 
would cause all old savegames to break.  These types of problems are 
hard to fix (though I suspect Ross is right: it's just a question of 
effort) and there are a _lot_ of them.

> The savegame format is going to have to change from time to time and
> IMO this is the best way to ensure  backward compatibility without
> losing efficientness.

For each ruleset change someone could write a converter script.  But I 
doubt anyone will take the initiative to do this.  After a while people 
will find it's just not worth it.

Another (better?) option is to store the ruleset information directly in 
the savegame.  Then when you load a civ1 game you don't have to specify 
"-r data/civ1.serv" since the ruleset information is already there. 
This has the drawback of making saved games larger.

Some time ago there was a discussion (that I didn't take part in) of 
unifying server options and ruleset values.  If this were done then 
presumably they'd all be stored in the savegame (as server options are 
done now).  But this discussion never got anywhere; this is also a 
difficult topic.

jason