adding/removing techs

GREGOREK

Making progress on updating Jurassic. Mutation is the key to evolution, so adding shrooms that grant unit property changes for a period of time. Doing this generated questions. Found a few posts on the subject but no favorable resolution. I will continue with the unique unit names, but asking if there is a better way.

Applying unitType property changes via triggerAttachment, causes a global change rather than just the target player. It requires separate unit names per player. The following activates, counts down, removes a movement bonus only to player Kimmeridgian's unit pterodactylus_B and sharovipteryx_B. The '_B' tag to prevent a global pterodactylus/sharovipteryx change bothers me. It will show in the purchase panel. The system distinguishes player.unit icons. Why not player.unit properties?

<attachment name="triggerAttachmentKimmeridgianADDbirnbaums" attachTo="Kimmeridgian" javaClass="games.strategy.triplea.attachments.TriggerAttachment" type="player">
    <option name="conditions" value="conditionAttachmentKimmeridgianbirnbaums"/>
    <option name="when" value="after:KimmeridgianPlace"/>
    <option name="removeUnits" value="all:birnbaums" count="1"/>
    <option name="placement" value="Fig:birnbaum" count="6"/>
    <option name="unitType" value="pterodactylus_B"/>
    <option name="unitProperty" value="movement" count="5"/>
    <option name="unitType" value="sharovipteryx_B"/>
    <option name="unitProperty" value="movement" count="4"/>
    </attachment>

<attachment name="triggerAttachmentKimmeridgianTCKbirnbaum" attachTo="Kimmeridgian" javaClass="games.strategy.triplea.attachments.TriggerAttachment" type="player">
    <option name="conditions" value="conditionAttachmentKimmeridgianONEbirnbaum"/>
    <option name="when" value="before:KimmeridgianPlace"/>
    <option name="removeUnits" value="Fig:birnbaum" count="1"/>
    </attachment>

<attachment name="triggerAttachmentKimmeridgianSUBbirnbaum" attachTo="Kimmeridgian" javaClass="games.strategy.triplea.attachments.TriggerAttachment" type="player">
            <option name="conditions" value="conditionAttachmentKimmeridgianONEbirnbaum:conditionAttachmentKimmeridgianNOTTWObirnbaum"/>
            <option name="when" value="after:KimmeridgianNonCombatMove"/>
            <option name="removeUnits" value="Fig:birnbaum" count="666"/>
            <option name="unitType" value="pterodactylus_B"/>
            <option name="unitProperty" value="movement" count="4"/>
            <option name="unitType" value="sharovipteryx_B"/>
            <option name="unitProperty" value="movement" count="3"/>
            </attachment>

The Tech route got confusing, even with POS2 G40 AOT xml's as guides. It seems to involves supportAttachment. How are custom techs defined, and then turned on and off? And, not stacked if multiple triggers turn the tech on? There was also a post concerned with the battle calculator not being accurate under this tech route.

TheDog

@gregorek
If the tech upgrade per creature are linear (or mostly linear) then consider this.

New Tech = new purchase unit and remove old purchase unit from player productionFrontier, this will have to be done per player.
This leaves the old units on the map, as dont need to remove and only new purchases have the upgrade.

As its a new unit you dont need a mass of custom properties, just a mass of units.

Would this work for you?

GREGOREK

@thedog ,
The mutations are temporary and purchasable in any order and concurrently. Started the frontier/rule swaps, but it got messy fast. The unit_### unique names is clean and will work, but I dont like the ### tags. Techs are supposed to add to common units and not affect other players. But, as stated, it gets too confusing and the implementations dont clearly define on/off conditions. EX: Grok thinks there's a removeTech option and tech adds, but that's not backed by the example game files. Or, I'm just not reading it right.
I'll continue with the unit### unique names (keeping them short without the full player name attached). Already scripted. Working today on a graphics script to spawn all the units with team colors (and a new drop shadow - hoping for a semi 3D effect). You are all more experienced in the xml coding. Maybe there's a method that clears the _### tags.

wc_sumpton

@gregorek

Techs can be applied but can't be removed. They are cumulative. Tech_A could add +1 to a unit's movement while Tech_B adds -1 to the same unit's movement while Tech_C adds another +1. All three techs would be applied to the same unit, making its final movement +1. Techs are applied to all units belong to a player. Giving a +1 movement bonus to Kimmeridgian pterodactylus would be given to all pterodactylus, but only to the Kimmeridgian player.

Cheers...

GREGOREK

PROGRESS UPDATE
I will move this discussion to Map/Mods, but have one last issue semi-appropriate here. Confirming the player.unit.tagging for buying techs works with one problem. The process 1) buy shroom named birnbaums to make birds fly faster. 2) place shroom anywhere. 3) trigger deletes shroom and plants 6 birnbaum (no s) in capital. 4) grove reduces by one after nonCombatMove each round. 5) when gone, trigger returns movement speed to normal.
All going well, except for stage 5. pterodactylus_I movement in hills is a 4 (the max value, terrain effects reduce elsewhere), but it got reset to a 3. Code for removal (SUB) is reverse of code for initializing (ADD), which did not have a problem assigning two properties different values. Will investigate further tomorrow for coding error, but maybe triggers are only supposed to handle one unitProperty value and I'll need to activate separate triggers (???). The movement clearly says 4 in code, but only reset to 3.

    <attachment name="triggerAttachmentPliensbachianADDbirnbaums" attachTo="Pliensbachian" javaClass="games.strategy.triplea.attachments.TriggerAttachment" type="player">
        <option name="conditions" value="conditionAttachmentPliensbachianbirnbaums"/>
        <option name="when" value="after:PliensbachianPlace"/>
        <option name="removeUnits" value="all:birnbaums" count="1"/>
        <option name="placement" value="Fwi:birnbaum" count="6"/>
        <option name="unitType" value="pterodactylus_I"/>
        <option name="unitProperty" value="movement" count="5"/>
        <option name="unitType" value="sharovipteryx_I"/>
        <option name="unitProperty" value="movement" count="4"/>
        </attachment>
    <attachment name="triggerAttachmentPliensbachianSUBbirnbaum" attachTo="Pliensbachian" javaClass="games.strategy.triplea.attachments.TriggerAttachment" type="player">
        <option name="conditions" value="conditionAttachmentPliensbachianONEbirnbaum:conditionAttachmentPliensbachianNOTTWObirnbaum"/>
        <option name="when" value="after:PliensbachianNonCombatMove"/>
        <option name="removeUnits" value="Fwi:birnbaum" count="666"/>
        <option name="unitType" value="pterodactylus_I"/>
        <option name="unitProperty" value="movement" count="4"/>
        <option name="unitType" value="sharovipteryx_I"/>
        <option name="unitProperty" value="movement" count="3"/>
        </attachment>

What happened?

wc_sumpton

@gregorek

The values are being grouped together.

<option name="unitType" value="pterodactylus_I"/>
        <option name="unitProperty" value="movement" count="5"/>
        <option name="unitType" value="sharovipteryx_I"/>
        <option name="unitProperty" value="movement" count="4"/>

Is being red like

<!-- unitType can take multiple values -->
      <option name="unitType" value="pterodactylus_I:sharovipteryx_I"/>
<!-- unitProperty can not take multiple values -->
      <option name="unitProperty" value="movement" count="5"/>
<!-- The first value is being overwritten -->
      <option name="unitProperty" value="movement" count="4"/>

Cheers...

GREGOREK

@wc_sumpton
So the error is on the ADD wherein 5/4 both got set correctly, but SUB overwrote the 4 with the 3 as it should.
I'll break the unitProperty modifiers into separate triggerAttachments and call activateTrigger.
Thank you.