On 02.01.2013 11:29, Michael T. Pope wrote:
> 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"/>)
>
That won't work. You either need to use several scopes, or introduce an
ability and use a scope with that.
> [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.]
>
At the very least, it is confusing. Twice, at least, I meant to revamp
the scopes and limits to use something more like standard predicate
logic, but I never got around to it. Maybe this year...
>
> 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?
>
That way lies madness, in my opinion.
> Cheers,
> Mike Pope
>
Regards
Michael
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/freecol-developers
