Talk: Effects

we need to know the enabled_by, disabled_by sets as well as the value of a given effect

we need to know which effects a certain effect type has

this for the get_*_bonus functions

for the AI, heh, i need to think about it a bit

Consolidation idea

One suggestion would be to figure out a way to consolidate some of the effects, for example the temple+oracle+mysticism example could be consolidated to the following:

 <effect type="Make_Content">
   <enabled_by>
     <req type="Building" id="Temple" range="City" value=1/>
     <optional>
       <req type="Tech" id="Mysticism" range="Player" value=1/>
       <req type="Building" id="Oracle" range="Player" value=1/>
     </optional>
   </enabled_by>
 </effect>

This would give the same effect as the current example, only more consolidated and easier to look up cumulative effects. You can only get the effects inside inner <optional> tags if you have already fulfilled all of the <req> tags in the level of the <optional> tag, and since the oracle and mysticism are in separate <req> tags, they can be added independently.

You could also nest <optional> tags, for example:

 <effect type="Production_Multiplier">
   <enabled_by>
     <req type="Building" id="Smeltery" range="City" value=25%/>
     <optional>
       <req type="Building" id="Factory" range="City" value=50%>
       <optional>
         <pick num=1>
           <req type="Building" id="Power_Plant" range="City" value=25%>
           <req type="Building" id="Solar_Plant" range="City" value=25%>
           <req type="Building" id="Hydro_Plant" range="City" value=25%>
           <req type="Building" id="Nuclear_Plant" range="City" value=40%>
         </pick>
         <req type="Building" id="Manufacturing_Plant" range="City" value=50%/>
       </optional>
     </optional>
   </enabled_by>
 </effect>

Meaning you have to have a Smeltery before you can have a Factory, and you have to have a Factory (and a Smeltery) before you can have a Manufacturing Plant or any kind of power plant. the <pick> tag means that only 1 of the following can be enabled (not really necessary if the buildings or requirements themselves are mutually exclusive).

The benefits for doing it this way is that the effects are more hierarchical according to effect type, and so all effects of the same type will be in the same tree. It also removes a lot of redundant (and error-prone) lines as when you change something in one place (for instance changing Smeltery bonus from 25% to 30%) you have to look for all the other locations where the smeltery bonus is located and change them accordingly. Also, the values shown can be rather confusing, since each [effect] shows a value of 1, which to some lay readers may imply that the effect of having a temple+oracle+mysticism is still 1 (rather than 3). Also having all 3 might get interpreted as having a cumulative value of 4 (temple, temple+oracle, temple+mysticism, temple+oracle+mysticism)

Alternatively, the <req [requirements]/><optional>[subrequirements]</optional> could be replaced by <req [requirements]>[subrequirements]</req> if there is only 1 requirement for the subrequirements.

The registry version would use references to other effects for nested requirements:

[effect id = "Oracle_Effect"]
type = "Make_Content"
value = 1
enabled_by = 
  {"type", "id", "range"
   "Effect", "Temple_Effect", "City"
   "Building", "Oracle", "Player"
  }

On the other hand, the downside of this whole framework (the original effects framework) is that buildings and techs no longer have effects, but that effects have buildings and techs, which makes looking up the effects a building/tech/etc. has much slower (though that would just be computed and stored once when parsing the effects file, and updated if changes are made).