Setup Chronosphere, Iron Curtain and Weather Control Device animations

[Mailaender]

Depends on OpenRA/OpenRA#17787.

[sorcerer86pt]

rebase this please

[Mailaender]

No point in that really as OpenRA/OpenRA#17787 isn't even merged.

[sorcerer86pt]

HI, the OpenRA/OpenRA#17787 has been merged. I think you can rebase this and retest this

[Mailaender]

No, it is still

ra2/mod.config

Line 7 in 0bd1e28

ENGINE_VERSION="release-20200202"

[Mailaender]

Rebased

[MustaphaTR]

Needs rebase again.

[Mailaender]

Had to rebase again due to #806 going in first.

[penev92]

There are two commits called "Fix resources span multiple sheets."

[penev92]

Re using Requires<SupportPowerInfo> - I see that the argument is that we only use that for cases that would crash the game and not cases where otherwise unwanted behaviour would be introduced. That is an upstream convention and while I think it should change I won't hold it against this PR.

[Mailaender]

I think the main purpose is to modify the initialization order, which is not required in case of these rendering traits which are connected via interfaces.

[penev92]

Here are some polish points to consider:

• The Weather Control Device's charged animation should freeze when low on power. IMO it would be best to remove the lightnings, not freeze them, but currently nothing happens, which seems pretty weird.
• The Nuclear Missile Silo's charged and firing animations play on top of the default one, meaning it is clearly visible underneath! Also the missile sprite has lower ZOffset than the Silo's firing sprite, so the missile comes up from behind the structure when firing.
• The Chronosphere's animations feel like they play too fast (I think we've mentioned this about other building animations as well some time?), but I'll need to compare to the original. The charged animation should also freeze on low power though.
• The Iron Curtain's animations play too fast. They should also freeze on low power.

If the animation speed is a general mod thing not specific to these structures it can be addressed in a separate PR.

[penev92]

Considering how we currently have the new WithSupportPowerChargedOverlay trait play on top of the regular body/animation/overlay trait(s), wouldn't it be better to instead create a trait that grants a condition on support power charged and have that condition enable an overlay (disabling other rendering traits as needed)? This sounds a bit more generic and reusable.

[Mailaender]

From my experience, rendering traits work better with interfaces than loosely coupled with conditions.