On Wed, 2 Jan 2013 04:33:21 PM Michael Vehrs wrote: > 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.
OK. Perhaps I should take my own suggestion upthread and see if the
autoproduction functionality would work in these cases.
> > [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...
The more I look at this one the more worrying it looks. Pretty much anything
involving modifiers ends up in that routine, and I really like being able to
trust that the spec means what it says. I will have a closer look at this
soon.
> > 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.
OK. No in-game spec upgrades is the policy. Mods are confusing enough as it
is (speaking of which, as of svn.10428, user mods should be working again).
Cheers,
Mike Pope
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 [email protected] https://lists.sourceforge.net/lists/listinfo/freecol-developers
