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

[Jérôme Plût <Jerome.Plut@xxxxxx>]

Duodecimo Kalendas Decembres MMV scripsit Jason Short :
> 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've been thinking about this for a while, and here are some (purely
theoretical) results. The most difficult problem with ruleset-defined
infrastructure will be to have proper handling of the unit activities
rules. There are two possible policies to manage this:
 - first, to delete completely the concept of "activity" such as
   mine/irrigate/..., and the possible unit orders become
    . build infrastructure (arg: a modification),
    . change terrain (arg: a terrain type),
   the data is then a list of possible terrain/modification types for
   each unit (for instance, a Worker could change Forest to Plains,
   but it would need an Engineer to change to Hills).
 - second, to keep the concept of activities, the data is then a
   function of (activity type) x (terrain type) -> (result).

The first policy is close to what CtP does: it is quite
straightforward, but has the grave inconvenient of breaking keyboard
shortcut compatibility.

The second one is much more complicated, but probably still
manageable. The main problem is that (result) is a compound type
(think of the 'R' activity: it builds a road if nothing is present,
and a railroad if a road is present). So it would require something
like this in the ruleset:

[modification_railroad]
prereq = "road"
move = 0
tech = "Railroad"
base_cost = 2
auto_cities = 1 ; auto-built on cities
infrastructure = 1 ; is infrastructure
; (trade/shield bonuses and other added effects go here)

[activity_road]
shortcut = 'R'
result = {
  "type",  "what"
  "build", "road"
  "build", "railroad"
}

[unit_workers]
activities = "Road", "Mine", "Irrigation"

[unit_engineers]
activities = "Road", "Mine", "Irrigation", "Terraform", "Clean"

The idea is fhat the first non-built modification should be the
selected target. But this gets even more awkward when trying to
reproduce the "irrigate swamp -> grassland" behaviour: the ruleset
syntax does not easily allow matricial data, so this would lead to
something like

result = {
  "terrain", "type"   , "what"
  ""       , "build"  , "irrigation"
  "swamp"  , "terrain", "grassland"
}

I find this rather awkward, but fail to see any clearly better design.
(Of course, the actual code data structures could easily be derived
from this ruleset syntax).

What do you think of it? Some of it can be implemented one step at a
time (by first encapsulating the modification types and moving, for
instance, the prereq and auto_city data to some separate place in the
code - note that this is needed to de-hardcode infrastructure,
whatever path is chosen to handle unit activities). As for the
compatibility, I think that my last resource patch goes toward
addressing the savefile compatibility issue (since modifications are
now saved by name).