Upgrades

Flag:	Upgrades
File(s):	Rules(md).ini
Values:	unsigned integers
Default:	0
Applicable to:	BuildingTypes

This flag specifies the number of upgrades this BuildingType can accept.

Tutorial

If you have ever played Tiberian Sun, you should remember the upgrade system that GDI had. Upgrades are buildable animations placed on top of buildings that provide additional features such as extra power or different weapons. Although not used, this system also works in RA2 and YR.

;Rules(md).ini
[Animations]
xx= (whatever you call your PowerUp#Anim)

; Rules(md).ini
[PARENT_BUILDING]
Upgrades=3  ;how many upgrade slots does this building have?

[UPGRADE_BUILDING]
PowersUpBuilding=parent_building  ;which building can be upgraded by this upgrade? Takes one building and one building only.
PowersUpToLevel=-1  ;-1 means "take first available slot", whereas positive values specify the exact slot# to use.

; Art(md).ini
[PARENT_BUILDING]
PowerUp#Anim=  ;The animation to add to this building when powered up by one level
PowerUp#DamagedAnim=  ;Damaged version of the animation to add to this building when powered up by one level
PowerUp#LocXX=  ;The x offset from the buildings draw position for this powerup animation
PowerUp#LocYY=  ;The y offset from the buildings draw position for this powerup animation
PowerUp#LocZZ=  ;Adjustment to normal Z when rendering this animation. This could be used to make the animation appear behind the building.
PowerUp#YSort=  ;Amount to add to anims sorting position so that it renders in the correct order relative to other objects

Where # references a specific upgrade slot (numbered from 1 to rules(md).ini -> [PARENT] -> Upgrades= ).

If the PowerUp#Anim(Damaged) is not specified, it will simply use [UPGRADE]Image= animation. The PowerUp#Anim(Damaged) should be omitted, because specifying the Image= on the upgrade itself is the correct way to do this.

If the Location is unspecified, (0,0,0) will be used.

What Upgrades CAN Have or Do

• Superweapons (this will add to the structure's superweapons, not override them)
• Power output/drain
• Weapon (Note: Superweapons override weapons, so structures may not have both)
• AIBuildThis: In TS it works. In YR, AI has problem in building/rebuilding this if the parent building does not have positive power or being powerplants.
• AIBasePlanningSide (in RA2 and beyond)

What Upgrades CANNOT Have or Do

• BuildLimit
• Credit production/drain
• Radar
• SpySat
• GapGenerator/GapRadiusInCells
• CloakGenerator/CloakRadiusInCells
• Sensors/SensorArray/SensorsSight
• DetectDisguise/DetectDisguiseRange
• PsychicDetectionRadius
• HasRadialIndicator/ConcentricRadialIndicator
• PowersUnit
• Upgrades cannot add to (or take away from) the Sight of their parent structure.
• Upgrades cannot add to (or take away from) the DebrisAnims list of their parent structure.
• Alter, add to, or take away from the Explosion, Explodes statement and DeathWeapon of their parent structure.
• Alter, add to, or take away from the maximum Strength of the parent structure.
  • However, if a structure is upgraded, regardless of its maximum Strength, current Strength and the Strength of the upgrade structure, its' current Strength will be set to its maximum Strength. In effect, this means that upgrades do not require a Strength value at all, as they cannot be independently damaged anyway.
• Alter the Armor of its' parent structure.
• Likewise, upgrades cannot override the ImmuneTo* statements on their parent structure.
• Override the Crew statement of the parent structure.
  • Using Ares, upgrades cannot add to, take away from, or alter in any way, the Survivors listing, TechnicianChance and EngineerChance settings.
• RevealToAll
• UnitReload
• UnitRepair
• Helipad
• Factory
• UnitsGainSelfHeal
• InfantryGainSelfHeal
• Gate+DeployTime+GateCloseDelay
• FreeUnit
• LightVisibility
• LightIntensity
• LightRedTint
• LightGreenTint
• LightBlueTint
• BridgeRepairHut
• CanC4
• ProduceCashStartup
• ProduceCashAmount
• ProduceCashDelay
• SecretLab
• AlphaImage
• DeploysInto
• UndeploysInto
• AirRangeBonus
• CanDisguise
• PermaDisguise
• DisguiseWhenStill
• Immune
• ImmuneToPsionics
• ImmuneToPoison
• ImmuneToRadiation
• ImmuneToPsionicWeapons
• Bombable
• Parasiteable
• Unnatural
• PipScale
• Ammo
• PipWrap
• InitialAmmo
• RadialFireSegments
• Reload
• EmptyReload
• ReloadIncrement

Known Upgrade Problems

• Upgrades can not add/override the DeploysInto/UndeploysInto= on their parent building.
• Upgrades can not have two different weapons. Both Primary and Secondary must point to the same weapon if the upgrade is to provide it. If you set them to be two different weapons, they will fire only if both weapons can hit the target.
• Upgrades with no Secondary defined will not fire when attacking. If you wish to use just the Primary weapon, you must specify "Secondary=none"
• Upgrades can not give the player ability to build new unit(s). If you attempt to do so, each building built after the plugin causes the new unit(s) to disappear from the sidebar, making them unbuildable again.
• The AuxBuilding superweapon logic does not work when upgrades are involved (either AuxBuilding=upgrade or the upgrade has the superweapon itself).
• A building can provide a maximum of two superweapons - if a building has more than two superweapons when adding up the superweapons from the building itself with those provided from upgrades, only the first two superweapons will get considered.
• Although unused in the vanilla games, the flags PowerUp#DamagedAnim are listed in art(md).ini – albeit with a spelling error. The last two words of the flags are switched around: e.g. they are listed as PowerUp#AnimDamaged while the correct format is PowerUp#DamagedAnim. The flags themselves, when typed in correctly, work as expected.