Complete.Org: Mailing Lists: Archives: freeciv-dev: November 2005:
[Freeciv-Dev] Re: (PR#14652) Patch proposal: resources cleanup
Home

[Freeciv-Dev] Re: (PR#14652) Patch proposal: resources cleanup

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
Subject: [Freeciv-Dev] Re: (PR#14652) Patch proposal: resources cleanup
From: "Jerome Plut" <Jerome.Plut@xxxxxx>
Date: Mon, 21 Nov 2005 02:41:41 -0800
Reply-to: bugs@xxxxxxxxxxx

<URL: http://bugs.freeciv.org/Ticket/Display.html?id=14652 >

> <URL: http://bugs.freeciv.org/Ticket/Display.html?id=14652 >
> Having read the design (but not the patch) here are my thoughts.
> 
> First of all, this is a big change (175k patch) that's going to take
> some time to work on.  However, this is a change that I've long wanted
> and it would be nice to get it in before 2.1...though we will not hold
> up 2.1 waiting for it.

If you look closer into the code, you will see that the majority of
the volume of the patch is due to a cousin of
s/special/modification/g. The actual code changes are rather few.

> Next, I agree "specials" is a bad name.  "Resources" is a bit better,
> though perhaps not perfect in the context of my intended design (see
> below).  "Infrastucture" and "modifications" are also possible terms
> ("infrastrucutre" is used in the code in a few places).

I thought about this, and did _definitely not_ want nuclear fallout to
be classified as infrastructure... :-) Besides, get_infrastructure_set
would have been very self-confusing code.

> Now, as for the design I had originally envisioned: I want to replace
> hard-coded specials entirely.  Resources/modifications/infrastructure
> should be defined entirely from the ruleset.  This allows great
> flexibility in that the ruleset can then also define what each activity
> does to each infrastructure and what effects each bit of infrastructure
> has.  However there are definite problems too...

I totally agree, and what I wrote was, in my mind, a step in this
direction. But it would be uneasy to fit this into the ruleset syntax,
which doesn't easily allow for complex data structures (in this case,
a function of terrain x activities -> results).

> One of the biggest problems is savegame compatiblity.

Why not provide a savegame translator (in the distribution, but
separate from civserver)? This is a mass of program that is mostly
encumbering in the civserver, considering that it only has to be used
in some specific cases. (I agree that this would however shift a bit
more weight on the user, which is a bad thing. Or maybe you could have
savegame.c autorun this converter).

But if you want to keep (upwards) savegame compatibility, you will
someday need to rewrite most of the way the terrain specials are
saved. 





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