39. More documentation problems in terrain.ruleset:
a.
Code: Select all
; graphic = tag specifying preferred graphic
NQR: "None" is also valid. Should have additional cooment:
Code: Select all
; This can be "None" to indicate that a graphic
; is not needed.
b. [terrain_*]
Code: Select all
; #_time = time for # activity; if 0, cannot #
; Nonzero values only affect extras with build_time 0.
; Such extras can modify time with build_time_factor.
is inconsistent with [extra_#]
Code: Select all
; build_time = how long it takes a unit to build this extra.
; Value of 0 (default) means that terrain- and
; build activity specific time is used instead.
"; if 0, cannot #" is historical baggage. Replace with "; if 0 (and/or extra's build_time_factor is 0), and extra's build_time is 0 then cannot #" - plus other variations e.g. build -> removal; # = {base, road, irrigation, mining; transform is ok.}
Also does "Value of 0 (default) means that terrain- and build activity specific time ..." mean for example "Value of 0 (default) means mining_time in the terrain section multiplied by build_time_factor ..."?
The same comments apply to removal times and other activities (# as above).
Quick question - why the gymnastics? How about the algebraic "Total mining time = build_time + mining_time * build_time_factor"? If the result is zero then cannot build the extra on the terrain." [In fact, why persist with this restriction? - "buildable = FALSE" is universal (or should be once the bug is fixed)]. I believe civ2civ3 would cope just fine (with the algebra) with +2 LoC (build_time_factor = 0 for both railroad and maglev).
c. rmact_gfx is not used for pillage - presumably the tag for 'Pg' is hardcoded - was this something that 'slipped through the cracks'?
d. [chronic]
Code: Select all
; reqs = requirements to build the extra (see effects.ruleset
; and README.effects for help on requirements)
- "build the extra" is NQR. There is black magic hard code deciding which predicates relate to creation, and which relate to existence,
and these are not documented.
e. [units_*]unit flags
Code: Select all
; "Settlers" = can irrigate and build roads
Does this include mining, build bases?
f. Closer inspection of comments in terrain.ruleset reveal the following
Code: Select all
; reqs = requirements to build the extra (see effects.ruleset
; and README.effects for help on requirements)
; rmreqs = requirements to remove the extra
Something got half baked here. I could find no use of rmreqs in fc 2.6 rulesets. There is a clear ambiguity in the semantics of the reqs vector - some predicates refer to the creation while others refer to the existence. The latter could be handled by "conflicts" but currently the city center is not a valid 'extra'. This is, and has been, a serious omission that could be simply solved - demand a (hidden?) extra that is 'always on' city center. This could then be referenced by (or could use) the conflicts field. There are a number of features of city centers that could be softcoded in the extra's definition. In additon to "conflicts", we could have "native_to" and various flags such as "NativeTile" and "Refuel" (extra) and "ParadropFrom" (base). Doing all this would allow ruleset authors to deny these features as default city attributes (thus forcing for example the building of a airport for aircraft).
Even better would be to add a [City] section as another "Causes =". Somewhere down the track this could be extended to [City_*] which would allow for features such as Civ III colonies.