RA2/YR: How to NOT Break the YR Campaigns in Your Mod
by CannisRabidus and Blade. Published: 3/8/03. Last update: 2/12/05.

Introduction

For completness, this tutorial attempts to explain why mods break the campaigns, as well as offering possible fixes to the problem. If some of the details of the explanations also serve to make your eyes glaze over, we apologize.

Defining the Problem

Simply put, adding new [BuildingTypes] to your mod in rulesmd.ini is what breaks the Yuri's Revenge campaigns.

When Yuri's Revenge is loaded, it reads the [BuildingTypes] list and builds an array from it. Many of the stock campaign maps add new [BuildingTypes] in the mission maps themselves, and such added buildings are appended to that array. The Yuri's Revenge singleplayer missions are dependent on triggers which identify "building-by-number", as defined in that array.

If your mod adds new buildings in rulesmd.ini, you've extended the [BuildingTypes] list, and lengthened the array. Therefore, you also have shifted the campaign-added buildings further down the array, which gives them different array values.

The most notorious example is the first Allied campaign. Each of those tech power plants are actually unique [BuildingTypes] which all use the tech power plant image. Those new buildings are added in the campaign map itself. Then, triggers look for "building-by-number", as defined in the [BuildingTypes] array, to know if you own them or not. If you add new buildings to rulesmd.ini, then the mission's new buildings get added to the end of that longer rules array... which prevents those particular map triggers from working. The mission thinks you haven't captured any of the buildings, even if you captured all of them.

This problem could have been avoided entirely if Westwood to had added placeholder buildings to the end of the rulesmd.ini list, which could be used by the campaign maps... but they didn't.

Solutions

Possible Solution #1: Add the campaign buildings to the master rulesmd.ini list.

Adding the campaign-added buildings to the rulesmd.ini list presumably would establish placeholders in the array, and then you could add your mod's new buildings after them. This works for the first mission, but doesn't work for the missions that follow... this is because the missions sometimes re-use building names, and sometimes don't. A campaign is a saved game, and the [BuildingTypes] array, and any changes made to it, is maintained throughout the saved game. Each mission that adds new buildings, continues to add to the array. So, as the campaign progresses (as each new mission map is loaded), the [BuildingTypes] array continues to grow. For these reasons, this is not a solution in of itself... more work is needed.

Possible Solution #2: Modify the campaign maps themselves.

The mission maps can be edited in text, to change the building names as they appear throughout the maps, to correspond to those names added to the rulesmd.ini list as suggested in the previous paragraph. This also requires fixing each and every trigger event, trigger action, and script action that looks not only for "building-by-number", but for building name. This a daunting task, as is testing every trigger you changed. Some triggers in the later missions don't appear to be mission-critical, and it's difficult to be entirely certain that all these triggers actually work. It's reasonable to assume that several of these triggers may be broken. Therefore it must be cautioned that it's possible that fixing those triggers could introduce new bugs which never showed up before.

(The Project adds campaign building placeholders in rulesmd.ini, along with a complete sweep of the campaign maps, as described in solutions #1 and #2.)

Possible Solution #3: What, me worry?

The easiest solution is to just ignore the problem, and admit that your mod breaks the stock campaigns. After all, many believe that no one plays missions except when they first buy the game. Of course, you would also have to accept that others would believe that to be a fairly naive and tunnel-visioned opinion.

Possible Solution #4: Replace what's broken with something that's not.

Alternatively, you can replace the stock campaigns with your own. This not only avoids the problem, and simultaneously gives the player new campaigns to play. While a wonderful solution in theory, making new quality campaigns is difficult and extremely time-consuming, and will almost undoubtedly delay the release of your mod indefinitely.

Possible Solution #5: Don't break it in the first place.

You can limit your mod's new buildings to the multiplayer game, by defining your new buildings in each of the multiplayer override files instead of in rulesmd.ini. This is accomplished by adding a [BuildingTypes] list, containing only the new buildings, in the MP override files, along with all the building code (new building code in rulesmd.ini is discarded by the game if the building is not on the [BuildingTypes] list there). Of course this means that any weapons such buildings may have will have to be defined in the MP override files as well, unless the weapons are "owned" by a unit that does exist in rulesmd.ini. Art code for these buildings, and their animations (if any), are added in the customary way.

(CannisRules limits new buildings to the multiplayer game, as described in solution #5).