PowersUpToLevel

Flag:	PowersUpToLevel
File(s):	rules(md).ini
Values:	Signed integers: All whole numbers from -2147483648 to 2147483647; in rare cases, only from -32768 to 32767. (Limited to: -1, 1, 2, 3)
Applicable to:	BuildingTypes (upgrades)

Specifies the number for this power up or upgrade that gets plugged into the slots of parent bulding.

Values

When using positive values of 1, 2, or 3, these represent the corresponding slot number on the parent buildings. In this case, once an upgrade has been installed on a parent building, it cannot be installed again.

Using -1 also prevents other upgrades that use 1, 2, or 3 from being installed on the same parent. However, any upgrades, whether itself or others, that also use PowersUpToLevel=-1 can continue to be installed until the number specified by the parent building's Upgrades= is reached.

Any upgrades using other values cannot be installed on buildings.

Notes

While the simultaneous firing of both Primary and Secondary weapons is applicable to all the upgrade numbers, in Tiberian Sun there is hardcoded restriction for the Component Tower to not allow this for PowersUpToLevel=2 and PowersUpToLevel=3 as those are coded for RPG and SAM Upgrades.

Primary and Secondary usually have same weapons when used in upgrades. There are issues if different weapons are used as those would show the firing cursor depending on the range of the weapons but have problems in actually firing.

Upgrade Image

When upgrades are installed to parent buildings, the parent buildings will play the animations specified by their Image= setting. If there are multiple upgrades, multiple animations will be played. A special case is that for parent buildings named [GACWTR], they are hardcoded to be treated as turrets.

Among them, upgrades with PowersUpToLevel= values of 1, 2, or 3 will also cause the parent buildings to play animations specified by their own PowerUpXAnim= setting.

The animations created by the images of the first three upgrades will also, according to their creation order, use the data from the three PowerUpXAnim* settings except flags for specifying the animation entity type, meaning they use the same coordinate and layer settings. For those beyond the third, they are fixed at the origin of the coordinate system.

Note
In a way, in Red Alert 2, only upgrades with PowersUpToLevel=-1 work fairly well.

Bugs/Side-Effects/Unexpected Limitations

However, at least since Red Alert 2, there have been issues with the invocation rules for the animations specified by PowerUpXAnim.

1. PowersUpToLevel=1 does not create any of them,
2. PowersUpToLevel=2 creates the animation specified by
   1. _
   2. PowerUp2Anim
   3. _,
3. PowersUpToLevel=3 creates the animations specified by
   1. _
   2. PowerUp2Anim
   3. and PowerUp3Anim.

When parent buildings are damaged, it removes the animations created by the upgrades' Image= and creates Damaged versions of the above animations. In all three cases, it additionally creates the animation specified by PowerUp1AnimDamaged. Specifically:

1. PowersUpToLevel=1 creates the animation specified by
   1. PowerUp1AnimDamaged
   2. _
   3. _,
2. PowersUpToLevel=2 creates the animations specified by
   1. PowerUp1AnimDamaged
   2. and PowerUp2AnimDamaged
   3. _,
3. PowersUpToLevel=3 creates the animations specified by
   1. PowerUp1AnimDamaged
   2. PowerUp2AnimDamaged
   3. and PowerUp3AnimDamaged.

For upgrades with PowersUpToLevel=-1, they do not use PowerUpXAnim, but PowerUpXAnimDamaged will correctly replace the animations created by the first three upgrades based on the number of existing upgrades when parent buildings are damaged, and the fourth and subsequent upgrades still use the animations created by their Image=.

---

However, there are even worse things. We previously mentioned that PowerUpXAnim* is effective for upgrades with PowersUpToLevel=-1 in corresponding slots, and the animation specified by PowerUp1Anim= never appears, while the animation specified by PowerUp1AnimDamaged= always appears when damaged state. Here, there is actually a more serious algorithm issue:

• First, to supplement a point we didn't mention before, when upgrades have PowersUpLevel= 1, 2, or 3, the animations called by their Image= always occupy slot#1. If you first install upgrades with PowersUpToLevel=-1 on another parent building of the same type, the program will remember the animations called by the Image= of the last upgrades installed in slot#2 and slot#3.
  • When installing upgrades with PowersUpToLevel=1, there is no effect because only one animation is created, which is determined by the upgrade's Image=.
  • When installing upgrades with PowersUpToLevel=2, it creates two animations; For the second one:
    • if the program recorded the last upgrade with PowersUpToLevel=-1 installed in slot#2, it will create the animation specified by its Image=;
    • if it doesn't exist, it creates the animation specified by the parent building's PowerUp2Anim=.
  • When installing upgrades with PowersUpToLevel=3, it creates the second and the third animations in the same way.

To summarize:

• If you first install two upgrades with PowersUpLevel=-1 in the order A then B on a parent building with Upgrades=4, then when you install a PowersUpToLevel=3 upgrade on another parent building, it will create the animation specified by upgrade B's Image= in slot#2 instead of the one specified by PowerUp2Anim=, and in slot#3, it will create the animation specified by PowerUp3Anim=.
• Then, if you install four upgrades with PowersUpLevel=-1 in the order B, A, B, A on another parent building, when you install a PowersUpToLevel=3 upgrade on another parent building, it will create the animation specified by upgrade A's Image= in slot#2 instead of PowerUp2Anim=, and in slot#3, it will create the animation specified by upgrade B's Image= instead of PowerUp3Anim=.

Note
This bug only affects the creation of animations; the actual installation of upgrades is not abnormal.

For upgrades with PowersUpLevel set to a positive value, if the animation called by the upgrade's Image= is not an infinite loop, then it will not prevent upgrades with PowersUpLevel=-1 from being installed on this parent building. Considering that upgrades with PowersUpLevel= 1, 2, or 3 occupy a corresponding number of slots, therefore, the same parent building in this case can first install one upgrade with a positive PowersUpLevel, and then install (Upgrades - PowersUpLevel) upgrades with PowersUpLevel=-1.

Footnotes

In Phobos

Starting from Phobos Build#39, building upgrade animations can use power controls through the use of new flags:

• PowerUpXPowered,
• PowerUpXPoweredLight,
• PowerUpXPoweredEffect,
• PowerUpXPoweredSpecial.

Starting from Phobos Build #44, this part has been implemented:

• For upgrades with PowersUpLevel= 1, 2, or 3, they will only create animations specified by PowerUpXAnim= or PowerUpXAnimDamaged= corresponding to their own sequence number, based on whether the parent buildings are in a damaged state.
• Another change is that when PowerUpXAnim= is present, it will no longer create animations specified by the upgrade's own Image=, and this also applies to upgrades with PowersUpLevel=-1 that are installed on the first three parent buildings.
• Moreover, when parent buildings are in a damaged state, non-damaged state animations will be correctly deleted.
  • Of course, if damaged state animations are not specified, the original non-damaged state animations will be used instead.

See Also

• PowersUpBuilding
• WallTower
• IsPlug