Side
As an Object
Side is defined as a key in the [Sides] list, and it corresponds to a value list composed of countries.
- In Tiberian Sun, there are mainly two factions: GDI and Nod.
- In Red Alert 2, they are not removed but instead used to represent Allied and Soviet, with internal code still being GDI and Nod.
- In Yuri's Revenge, a ThirdSide is added to serve as Yuri Side.
Besides these player-selectable Sides, there is also a Civilian Side used to carry Neutral houses (neutral factions on the map that are hostile to the player) and a Mutant Side used to carry Special Houses (neutral factions on the map that are friendly to the player).
References
In vanilla, the parameters of each side are hardcoded to use some values set in the game(md).exe or globally rules, and cannot be defined using an INI Section, but in Ares, this is allowed. Refer to Ares documentation.
As a Flag on (Themes and) Houses/Countries
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Flag: | Side |
| File(s): | theme(md).ini, rules(md).ini |
| Values: | Strings: Normal text. |
| Default: | null |
| Applicable to: | Themes, Countries |
Sidebar and EVA.etc
On countries/houses, this can define the Side it belongs to, overriding the default grouping in [Sides], and use the corresponding sidec0#.mix as the sidebar graphic. However, if you set a Side value that does not exist, it will still use sidec01.mix.
For BGM selection
Here, it does not use zero-based numerical values to correspond to the index of sides in [Sides]. Instead, based on the registration order in [Themes] and [Countries]/[Houses], it checks the value of this flag on each BGM[1] and country/house. The specific content of the value is not processed; it simply checks whether it has appeared in earlier entries or not. Then, it sorts each type of value in the order of their earliest appearance, thereby constructing two sequences based on the Side= values for BGM and counties/houses. Subsequently, it assigns BGM and countries/houses according to these constructed sequences.
- For BGM that do not have Side= set—that's fine, they will be assigned to the BGM list of all countries/houses.
- For countries/houses that do not have Side= set—they will follow the classification in [Sides] to be used. If a Side value cannot be obtained in this way, then using this country/house will immediately crash.
Example:
| BGM | Side | index(BGM) |
| ①🔵 | ||
| ②🟠 | Type_C | 0 |
| ③🟡 | Type_B | 1 |
| ④🔴 | AnyOther | 2 |
| ⑤🟢 | Type_C | 0 |
| ⑥🟣 |
| Countries/Houses | Side | index(C/H) | BGM |
| A | (Nod)[2] | 0 | ①🔵②🟠⑤🟢⑥🟣 |
| B | Nod | 0 | ①🔵②🟠⑤🟢⑥🟣 |
| C | (GDI) | 1 | ①🔵③🟡⑥🟣 |
| D | V3ROCKET | 2 | ①🔵④🔴⑥🟣 |
| E | GDI | 1 | ①🔵③🟡⑥🟣 |
In summary: the content of the value is not important, and the positions of BGM and counties/houses in their respective ini files are not important. What truly determines the assignment method is the order in the registry and the number of types of values after the Side= entry.
Footnotes
- ↑ Regardless of whether this BGM cannot actually be played or displayed in the list due to reasons such as the wav file not existing.
- ↑ Here, the form (<side>) is used to indicate that it does not have Side=set, but due to the grouping in [Sides], it is assigned this side value.
- Note: These Side values assigned by default through the grouping under [Sides] will be arranged after all other Side values explicitly specified by countries/houses (including Neutral and Special) have been arranged.
- For example, if all Side{{tt|= entries are left blank except for Neutral and Special, then the GDI corresponding to countries on the GDI side will use #2 (0-based), and the Nod corresponding to countries on the Nod side will use #3 (0-based). Other side values assigned only by default through grouping will be arranged in sequence thereafter. Of course, if a countries/houses explicitly specifies them, then they will be forced to be placed in a more forward position.