[Freeciv-Dev] Re: (PR#9760) RFC: numbering of terrains

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

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

Marcelo Burda wrote:

> I not understand where is the problem. simply include new terrains befor
> T_UNKNOWN

I want to be able to change the terrains without editing the source.  So 
a modpack can add new terrain types without requiring users to recompile 
the code.

> the lastest has to be T_UNKNOWN, (it is not set in ruleset)
> T_ANY is not a real terrains type, it is used as spetial value, it go
> after T_UNKNOWN

This doesn't *have* to be last.  But some places in the code assume it 
is.  There are some (terrain >= T_UNKNOWN) checks, for instance.  But 
this is ugly and should be done away with anyway.

> T_LAST is simply used to count, as T_UNKNOWN as to be the last real
> terrains type we can use it to count, T_LAST (or T_COUNT) are not needed, 

T_COUNT is used to count.  T_LAST is usually used as a flag (like T_ANY) 
meaning there is no terrain.  See terr_gate, aff_terr, 
irrigation_result, mining_result, transform_result.  There is also 
MAX_NUM_TERRAINS which is intended to be a hard limit on the number of 
terrains.

Eventually T_COUNT should be a variable (read from the ruleset) and 
MAX_NUM_TERRAINS should be defined as MAX_NUM_ITEMS.  Then rulesets can 
add up to this many terrains with no problems.

With techs we have a similar situation.  But there we have A_LAST == 
MAX_NUM_ITEMS.  However again this is just used as a flag (kindof ugly, 
it should be A_NONE also).  And there are more flags A_UNSET, A_FUTURE, 
A_UNKNOWN.

So we *could* change T_LAST to be MAX_NUM_ITEMS, with T_UNKNOWN=T_LAST+1 
and T_ANY=T_LAST+2.  But why not just make it negative and avoid this 
limitation?

jason