I just looked again at the post-Casas convert hack I was trying some time back--- ATM my preferred solution is that post-Casas converts auto-upgrade on beginning work in a colony.
The various type readers in Specification.java default to additive
behaviour if you just respecify something, so I had some hopes for the
following spec-fragment:
<freecol-specification id="convertUpgrade">
<founding-fathers>
<founding-father id="model.foundingFather.bartolomeDeLasCasas">
<ability id="model.ability.upgradeConvertsAtColony" value="true"/>
</founding-father>
</founding-fathers>
<unit-types>
<unit-type id="model.unit.indianConvert">
<upgrade unit="model.unit.freeColonist" enterColony="true">
<scope ability-id="model.ability.upgradeConvertsAtColony"/>
</upgrade>
</unit-type>
</unit-types>
</freecol-specification>
However this crashes immediately in FoundingFather.readAttributes(),
which assumes, not unreasonably, that certain attributes are always
present (in this case "type"). So I copied over the father and
convert attributes from classic/specification.xml, retried, and it
worked.
This is not very satisfactory though. Mod writers should not have to
collect attributes from the parent super-specification/s and/or work
out which ones are critical, and it makes it hard for mods to coexist.
An immediate workaround is to hack the FreeColObject.readFromXMLImpl
to not call the real class-specific readAttributes(), but only call
the basic id-setting FreeColObject.readAttributes() if a magic
attribute is present:
protected void readFromXMLImpl(XMLStreamReader in)
throws XMLStreamException {
if ("true".equals(in.getAttributeValue(null, "preserveAttributes"))) {
readAttributes(in, null);
} else {
readAttributes(in);
}
readChildren(in);
}
With that hack in place, the spec-fragment becomes:
<freecol-specification id="convertUpgrade">
<founding-fathers>
<founding-father id="model.foundingFather.bartolomeDeLasCasas"
preserveAttributes="true">
<ability id="model.ability.upgradeConvertsAtColony" value="true"/>
</founding-father>
</founding-fathers>
<unit-types>
<unit-type id="model.unit.indianConvert"
preserveAttributes="true">
<upgrade unit="model.unit.freeColonist" enterColony="true">
<scope ability-id="model.ability.upgradeConvertsAtColony"/>
</upgrade>
</unit-type>
</unit-types>
</freecol-specification>
...which is much nicer for the mod author. However, there is not much
granularity there, so the problem will just recur as soon as a mod
needs to add or change an attribute. I am unsure of the right
direction here. Any suggestions folks?
Cheers,
Mike Pope
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ Freecol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freecol-developers
