Secret Lab System

The "Secret Lab" logic was introduced in Yuri's Revenge : when you captured a building, you gained the ability to build a semi-random object you otherwise couldn't. However nicely this sounded, the logic is dreadfully screwed up.

How it works

Needs Transcribing

Pseudocode relevant to this article is available at http://dc.strategy-x.com/src2/ScenarioClass/GenerateSecretLabBonuses.cpp. Please update this article with information revealed by the pseudocode.

1. At map load time:
   1. The engine enumerates all the buildings with SecretLab=yes present on the map.
   2. The engine constructs a single list from objects specified in [General]→SecretInfantry, [General]→SecretUnits and [General]→SecretBuildings and using pseudorandomness assigns each building one of the objects on this list.
      • Note: this step only happens if the number of Secret Labs on the map does not exceed the total number of potential bonuses.
2. During gameplay:
   1. Each frame the game asks each of those SecretLab=yes buildings what object they can build.
      1. If the building has SecretInfantry, SecretUnit or SecretBuilding specified, it will report that it can build that, in that order (if SecretInfantry is set, it is reported, otherwise it falls back to SecretUnit and then to SecretBuilding).
      2. Otherwise, the building will report that it can build the object assigned to it by the pseudo-random process in step 1.
   2. The Rules(md).ini does contain a SecretHouses flag, which is parsed, but entirely unused.

Drawbacks

The process has quite a few drawbacks:

1. The bonus you get is determined at map load time rather than at building capture/acquisition time:
   1. A captures lab → B captures lab → A recaptures lab → D captures lab : All get the same object.
   2. Libya captures lab → gets Grand Cannon as bonus. France captures that same lab → gets Grand Cannon which it already could build.
   3. You cannot have a buildable lab (well, technically SecretInfantry/Unit/Building on the lab itself will be granted, but that part is completely unrandomized, so it behaves like any run-of-the-mill prerequisite building).
2. You cannot define multiple labs with varying bonuses - all secret labs pick pseudorandom bonuses from the same pool of choices.

Bugs/Side-Effects/Unexpected Limitations

1. If you place more labs on the map than there are choices for bonuses, none of the labs will give any bonuses at all.
   • This bug has been fixed in Ares 0.1.
2. The code for random bonus assignment is terribly quirky and not at all random: The closer an object is to the beginning of the combined bonus list, the more chances it has to be picked. For example, the very last object in the combined list will either be granted by the very first Secret Lab on the map (first in the [Structures] section of the map) or not at all.
   • In vanilla, three lists are merged into one pool, and each element is assigned a number for drawing. WW designed a mechanism where, after drawing a number, that number and its corresponding item are removed to ensure players get different rewards. However, the drawing process actually uses the current available numbers arranged into a set of indices (which are array indices starting from 0) for selection. But instead of using the drawn index to find the corresponding number, the code uses the index itself as the number to directly look up the item in the pool. This results in the numbers and indices not matching perfectly unless every draw hits the last item. Additionally, items earlier in the list are more likely to be matched repeatedly. It also causes each item from the end of the pool to become increasingly unable to be drawn as the number of draws increases, because the total number of indices keeps shrinking. Even if the drawn index could correspond to the item's number, the game uses the index to fetch another item's number.
     • For example, the pool has Infantry_A🔴, Infantry_B🟠, Vehicle_C🟡, Vehicle_D🟢, Building_E🔵, Building_F🟣, corresponding to numbers ⓪🔴, ①🟠, ②🟡, ③🟢, ④🔵, ⑤🟣. Before the first draw, they correctly correspond to indices 0,1,2,3,4,5.
     1. Assume the first draw picks index 3 - number ③🟢 - Vehicle_D🟢. Coincidentally, gamemd.exe uses index 3 as number ③🟢 to fetch Vehicle_D🟢 from the pool, and then removes this ③🟢, resulting in numbers ⓪🔴, ①🟠, ②🟡, ④🔵, ⑤🟣 corresponding to indices 0,1,2,3,4.
     2. Then the second draw picks index 4 - number ⑤🟣 - Building_F🟣. However, gamemd.exe uses index 4 as number ④🔵 to fetch Building_E🔵 from the pool, and then removes this ⑤🟣, resulting in numbers ⓪🔴, ①🟠, ②🟡, ④🔵 corresponding to indices 0,1,2,3.
     3. Next, the third draw picks index 3 - number ④🔵 - Building_E🔵. However, gamemd.exe uses index 3 as number ③🟢 to fetch Vehicle_D🟢 from the pool, and then removes this ④🔵, resulting in numbers ⓪🔴, ①🟠, ②🟡 corresponding to indices 0,1,2.
     • Thus, ⑤🟣-Building_F🟣 cannot be correctly obtained after the first draw, and ③🟢-Vehicle_D🟢 is even drawn twice due to this error.
   • In summary, items later in the pool have a lower probability of being drawn, or they can participate in the drawing process fewer times, leading to items earlier in the pool being more likely and easier to be drawn.
   • This bug has been fixed in Ares 0.1.

References

Ares introduces a mechanism where the secret lab bonus is randomly selected only when the building is first captured by a MultiplayPassive=no country (or assigned for pre-placed structures), and exclusively from bonuses not currently buildable by the lab's owner. This logic is extended with additional per-building flags. Refer to Ares documentation.

See Also

• The Prerequisite System
• TechLevel#Limitations_of_this_system
• SecretLab.PossibleBoons (Ares Only)
• SecretLab.GenerateOnCapture (Ares Only)