[Freeciv-Dev] (PR#10703) RFC: dependencies, requirements, and sources

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

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

Thesis:

1. A "requirement" has a type, an id, and a range.

2. Requirements are used in lots of places.


Background:

In the effects code we have the idea of an effect "requirement".  This 
is a condition required for the effect to be active.  It has a type 
("Tech"), a name/id ("Gunpowder"), and a range ("Player").

In the effects code we also have he idea of an effect "source".  It also 
is a condition required for the effect to be active!  The difference is 
that the type can only be "building" - this restriction is because the 
nifty indexed super-fast lookup cache is only written for buildings.  Of 
course it also has a name ("Magellan's Expedition" and a range 
"Player").  However it's important to note that an effect source is 
logically the same as an effect requirement that is used as an "index" 
(even though it's not coded that way at all).

In the building code we have the idea of a "req".  Buildings have 
several types of hard-coded reqs.  Each req has an implied range: techs 
have range "player", buildings have range "city", etc.  There are also 
terr_gate and spec_gate, which are just "Terrain" and "Special" 
requirements with range "Adjacent" (however we should forget about these 
for now).

Units also have requirements.  These are also hard-coded, but in exactly 
the same way as a req for a building.  There are tech and building reqs. 
  In PR#10630 Per has a patch to add government reqs.

And of course techs have requirements.  A tech may have up to 2 tech 
requirements.

With tech_req there are a few special-cases worthy of mentioning.  Of 
course there is "None", meaning no requirement.  There is also "Never", 
which is an ugly special case that used to be required but can now be 
removed (along with all items that have tech_req "Never").  Finally 
there is the "root_rech", which I'm not sure how to deal with in the 
above system (but works okay as an independent special case).

In addition to PR#10630 there is PR#5122.  This includes a patch from 
Remi that allows building requirements for techs and also a 4-year-old 
patch from Marko that does "generalized" reqs somewhat similar to what I 
have above.  What I'd like to do is more general than what Remi has but 
simpler than what Marko has...


Design:

I suggest then that we agree on a design, then bring each element to use 
the design one at a time (similar to what Marko did before).  The design 
is basically what I have above.  We can start by working with the req 
code in effects.c, and pull this out into a separate file so that other 
elements can use it.  For requirements of other items I think we should 
limit ourselves to 2 requirements, and-ed together: just like we have 
now for techs.  We thus have something like

   [unit_fanatics]
   req1 = {"tech", "Fanaticism", "Player"}
   req2 = {"gov", "Fanaticism", "Player"}

   [building_university]
   req1 = {"tech", "University", "Player"}
   req2 = {"building", "Library", "City"}

   [tech_republic]
   req1 = {"tech", "Code of Laws", "Player"}
   req2 = {"tech", "Literacy", "Player"}

and so on.  For now we don't add any new req types or ranges, although 
later we should (to handle terr_gate and spec_gate, if nothing else).

In code the data should look something like:

jason