On Sat, 29 Dec 2012 08:25:20 PM Michael T. Pope wrote:
> On Sat, 29 Dec 2012 09:53:28 AM Michael Vehrs wrote:
> > > Then for now how about we just rename the existing basicProduction as
> > > basicPerUnitProduction and add a new field for the non-unit production.
> > 
> > I had this idea, too. For the sake of compatibility, I think it would be
> > better to keep the (misleading) name basicProduction and introduce a new
> > field with a new name for non-unit production, however. In fact, why not
> > call it nonUnitProduction?
> 
> OK, lets go with that for now.  I fear the backward compatibility code is
> going to be awkward either way.

Actually, I think we can get most of the way with scopes.  Or at least we can 
get closer now that I have fixed them to work with modifiers attached to 
Buildings (svn.10433).  If Buildings then calculate bonuses with 
getModifierSet(... <unitType> ...) for the units present and getModifierSet(... 
<buildingType> ...) for the building itself, then something like:

    <building-type id="model.building.townHall" basicProduction="3"
                   produces="model.goods.bells">
      <modifier id="model.goods.bells" type="additive" value="1">
        <scope type="model.building.townHall"/>
      </modifier>

should work.  (Although not so well with the crosses situation, unless a 
model.building.cathedral matches a <scope type="model.building.chapel"/>)

[Aside: while digging into this, I was trying to use a matchesNull="false" 
scope attribute, which did not appear to work.  Deep inside 
FeatureContainer.getModifierSet() we have:

            if (fcgot == null) {
                result.addAll(modifierSet);
            } else {
                for (Modifier modifier : modifierSet) {
                    if (modifier.appliesTo(fcgot, turn)) result.add(modifier);
                }
            }

which looks like that if the object (fcgot) is null then all the modifiers are 
just accepted, and thus a matchesNull test will never get a chance to fail.
I tried dropping the null test case, but that broke a tile production test,
which (surprise) is the only place current where matchesNull=false is 
relevant, so either I am wrong, or we have two other problems:-S.]


Fixing things with spec changes is of course not going to work for existing 
saved games.  In future should we think about adding a version to the spec and 
auto-upgrade specs seen in saved games, or is that getting too intrusive?

Cheers,
Mike Pope

Attachment: signature.asc
Description: This is a digitally signed message part.

------------------------------------------------------------------------------
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612 
_______________________________________________
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Reply via email to