UnitPerks and Upgrades grant Promotions

[HandyVac]

This resource adds two new database tables, which allow units to gain promotions from being upgraded.

What It Does
The UnitUpgrades_Promotions table attaches a promotion to an affinity-level upgrade. All units which recieve that upgrade will get the promotion.

<UnitUpgrades_Promotions>
  <Row>
    <UpgradeType></UpgradeType> <!-- the upgrade you want to grant a promotion -->
    <PromotionType></PromotionType> <!-- the promotion you want it to grant -->
  </Row>
</UnitUpgrades_Promotions>

The UnitPerks_Promotions table attaches a promotion to one of the selectable perks in an affinity-level upgrade. Units will get the promotion if this perk is picked when recieving the upgrade.

<UnitPerks_Promotions>
  <Row>
    <UnitPerkType></UnitPerkType> <!-- the perk you want to grant a promotion -->
    <PromotionType></PromotionType> <!-- the promotion you want it to grant -->
  </Row>
</UnitPerks_Promotions>

How it Works
Various events trigger a lua script, which checks whether any unit on the map has one of the Perks or Upgrades in these two tables. If it does, the script gives it the corresponding promotion.

A modified version of UnitUpgradePopup.lua makes sure the promotion's Help TXT_KEY is shown in tooltips on the Unit Upgrade screen. (The code to grant the promotions will still work without the modified UnitUpgradePopup.lua, but you won't see the promotion's effects listed in the Unit Upgrade tooltips.)

How To Use It
Simply include the following three files in your mod:

• PGP_Create_New_Tables.xml - flagged as OnModActivated->UpdateDatabase
• PerksGrantPromotions.lua - flagged as InGameUIAddin
• UnitUpgradePopup.lua - flagged as Import Into VFS = true

Limitations
Units will not gain promotions immediately when they're built or when an upgrade is applied, they will gain them the turn *after* they're built or the upgrade is applied.
Fixed: Units now gain promotions immediately.

Perks gained as a FreePerk inherant to a UnitUpgrade will not trigger the promotion-granting system. Use the UnitUpgrades_Promotions table instead if you want a promotion inherant to an upgrade.

Download Here
An example mod and instructions are also included in the folder.

 

[lilgamefreek]

You can get around the "turn after" limitation by checking upon a UnitSetXY command. This will get triggered everytime the unit is placed anywhere on the map, including when it is spawned. I use it anytime I need to globally check units for some property.

Documentation: http://modiki.civfanatics.com/index.php/GameEvents.UnitSetXY_(Civ5_API)

You can also probably make the upgrade lag invisible to the player through use of Events.SerialEventUnitUpgradeScreenDirty(). This triggers whenever there is a change made to the Unit Upgrade Screen and forces it too update. It's a good time to check the player's units as well. At the moment, I think it triggers only when the player selects an upgrade and when the player changes a unit to view. It's usually not good practice to tie game-state altering functions to events, but it's unlikely your script will drive an infinite loop of any kind.

 

[HandyVac]

Ah, thank you. I'd been looking for some kind of "Unit Created" event, but hadn't realised that UnitSetXY would trigger when units are created.

I'll try out that serial event as well, as you say it should eliminate the lag for the player even if it doesn't trigger when the AI gets an upgrade.

 

[HandyVac]

Updated to (v3)

Both human and AI player's units gain promotions immediately when built. Human player's units gain promotions immediately when getting upgraded, AI units get them after a small delay (either the turn after the upgrade or when the unit moves, whichever comes first).

 

[Machiavelli24]

I built a snippet to do this exact same thing but it looks like you finished up a week before me. Looking through your code, it looks solid but I used a slightly different algorithm that provides some advantages and disadvantages relative to the approach you currently have.

Disadvantages of the approach I used:
1) I use a couple (four or so) blank promotions that will add cruft to the civilopedia and show up as blank lines when mousing over units to see their promotions.

Advantages of the approach I used:
1) No need to put UnitPerks that are inherent to a upgrade in a different table than UnitPerks that are chosen as part of an upgrade.
2) Less performance impact. The algorithm I'm using isn't going to scan through the new table every time any unit moves (which is multiple times per turn for every unit). I only need to scan the table when a unit actually upgrades and the rest of the time I'm able to avoid doing unneeded scans.
3) The algorithm will work the same if a user playing with multiple mods that use the snippet.