On 01.06.2012 14:59, Michael T. Pope wrote:
> 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
>
I think the correct approach would be to check whether the object has
already been initialized or not. If so, we should not require any
particular attributes. If not, we should require them.
Regards
Michael
------------------------------------------------------------------------------
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
