Currently founding fathers are defined in the FreeColMessages.properties file, ala:
model.foundingFather.thomasJefferson.description=Increases Liberty Bell production in colonies by 50%.
model.foundingFather.thomasJefferson.text=A powerful voice of Patriotism, Jefferson was credited with writin\ g the Declaration of Independence. He later became the 3rd President of the US.
The effect of the founding fathers is defined in the ruleset-specific specification.xml file:
<founding-father id="model.foundingFather.thomasJefferson" type="political" weight1="4" weight2="5" weight3="6"> <modifier id="model.goods.bells" type="percentage" value="50"> <scope ability-id="model.ability.person" matchNegated="true"/> </modifier> </founding-father>
A ruleset may want to tinker with the definition of existing founding fathers. For instance, maybe change Jefferson's liberty bell effect from 50% to 25%. But the description would also need to be adjusted to match. This creates a problem, in that the user could select either classic, freecol, or this imaginary new ruleset at runtime, so the Colopedia is going to be unreliable for at least one of these rulesets.
It might seem sensible to change the .description to something like:
model.foundingFather.thomasJefferson.description=Increases Liberty Bell production in colonies by %AMOUNT%.
however, what if the ruleset mod wished to completely change Jefferson's power? So the more general case would be to allow the founding father descriptions to be overridable. specification.xml seems like the sensible place for this to be done, but then this breaks translations!
Another option would be inserting ruleset specific strings into FreeColMessages.properties. This approach is already taken with settlement names:
So we could think about having:
model.foundingFather.thomasJefferson.classic.description=Increases Liberty Bell production in colonies by 50%.
model.foundingFather.thomasJefferson.foobar.description=Increases Liberty Bell production in colonies by 25%.
But I think this gets pretty messy when you start thinking about more than a couple alternate rulesets. As well, this doesn't help third-party rulesets distributed separately from freecol. They'd need to patch this file to add their strings, and their patches would bitrot quickly. Some ruleset customizations may desire adjustments to other strings in that file we might not foresee.
The only other idea I can think of would be to actually merge data/strings into data/rules/classic/, and then have a mechanism for derived rulesets to inherit classic's strings and override them with their own. Then strings specific to freecol could be split out into the data/rulesets/freecol/ dir. This would also necessitate setting up translations to handle these divisions.
With such a change, the ruleset maker would be able to confine all their changes to their data/ruleset/*/ directory, and then easily tar that directory up for redistribution.