#2606 Founding father descriptions should be overridable by alternate rulesets

Unspecified
closed-rejected
nobody
None
5
2014-12-09
2013-11-20
No

Currently founding fathers are defined in the FreeColMessages.properties file, ala:

model.foundingFather.thomasJefferson.name=Thomas Jefferson
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.
model.foundingFather.thomasJefferson.birthAndDeath=1743-1826

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:

model.nation.dutch.settlementName.classic.0=New Amsterdam
...
model.nation.dutch.settlementName.freecol.0=Nieuw Amsterdam

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.

Discussion

  • Mike Pope

    Mike Pope - 2013-11-20

    Why not just supply your own definition for model.foundingFather.thomasJefferson in the FreeColMessages.properties file that should be present in your mod?

     
  • Bryce Harrington

    You can close this out.

    You're right, it can be overridden through FreeColMessages.properties in the mod. I have no idea why I didn't try that out before filing the bug.

     
  • Mike Pope

    Mike Pope - 2013-12-04
    • status: open --> closed-rejected
    • Group: Current --> Unspecified
     
  • Mike Pope

    Mike Pope - 2013-12-04

    OK, thanks for the follow up.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks