Hardcoded

The term "hardcoded" describes functions that are coded directly into the Engine and cannot be changed/expanded by INI-editing. Examples for this are the number of unique MCVs in the game, the number of Houses and the multiplayer side colours menu.

Hardcoding

What is hardcoding?

Hard code is code held in the binary executable. Basically it's the things that are out of your hands when it comes to C&C modding. Reasons why some stuff has its behaviour handled purely by the binary code are likely varied and are probably due to time constraints or a lack of necessity for Westwood to actually ever vary some behaviour.

Why do I need to know this stuff?

There are two benefits from knowing the hardcoded stuff:

1. Saves time and energy in your mind.
2. Stops you irritating more experienced modders by asking about features that are impossible.

Features that are hard coded

1. Superweapons: basically, superweapons can ONLY be replaced by altering the art assets and warheads that they use and the scope for modifying their behaviour (how they do their damage) is generally limited. All though it is possible to add more superweapons to the list, the Type value controls what behaviour that super weapon will use. This would allow you to make multiple versions of the same superweapon so you could charge and fire more than one at a time were it not for the fact that every superweapon needs a unique Action to give it a cursor and targeting. Via some clever ini editing, some members of the editing community have succeeded in creating superweapon like behaviour for some new weapons, but their targeting is handled differently from true superweapons.
2. Sides: Depending on the C&C title, there are either two or three playable sides with two additional sides for neutral units and structures. For the playable sides they represent the main factions in the game and are often sub divided into countries (though internally they are called houses for the most part). In RA2/YR, the number of countries is also limited by code in the executable that identifies what art assets are assigned for loading screens. The playable sides are always 'GDI', 'Nod' and where applicable 'ThirdSide'.
3. Multiplayer Color Selection Menu: The colours that are displayed are fixed, even though you can change what they result in in rules.ini.
4. Adding a new type of unit missile: if you are planning to add a new missile that will act as the 'V3 Rocket Launcher' or the 'Dreadnought' or the 'Boomer sub' missiles, you will fail. If you tried to add one, the rocket will launch until it reached a certain altitude and will do one of the 2 actions:
   • will reverse its destinated direction and travel to nowhere.
   • will reverse its destination and head straight back to the 'Launching vehicle'. Similar behaviour can be created however; please see Spawned Missiles for further information.
5. The 100 Units Bug. It is more of a bug than a hardcoded issue and is to do with the xxxtypes section, which lists of all the units in the game. The list looks like this:

   [InfantryTypes]
   1=E1
   2=ENGINEER
   3=SENGINEER
   4= ...etc.

   If any player buildable units are numbered to exceed 100 (after considering vacant numbers) then the list causes some kind of overflow error for the AI and it will constantly build the last unit on the list as though it were the only unit available to it.

   See Also:

   • How Object Arrays Work

6. Infantry CANNOT repair vehicles: Any true infantry as listed in the [InfantryTypes] list cannot repair a unit from the [VehicleTypes] list. That is it cannot use a weapon that does negative damage against them, though it can do against infantry. Similarly a vehicle cannot heal infantry. You can generate a similar effect using a particle or by using negative Verses values on a Warhead but the targeting behaviour is different to a true repair unit; please see Infantry Mechanic for further information.
7. Number of Campaigns in RA2/YR: In RA2 there are the Allied, Soviet and Tutorial campaign, a total of 3, in YR there are the Allied and Soviet campaign, a total of 2. You can re-enable the tutorial campiagn in YR, so that you can add a third campaign however, but it involves modifying the executable using a resource hacker and creating some alternate art assets. This means that you cannot add any extra campaigns beyond three in these games. Strangely however TS/FS do not suffer from the same problem. They have a list box that lists all campaigns from battle.ini.
8. Cursors: Cursor animations are held in the file mouse.shp (mouse.sha in YR) and certain frames are hardcoded to each action. Some actions however (particularly in RA2/YR where they are left over from TS) all share the same frame so even altering the shp file will not give unique cursors for these actions.
9. Disk Name for RA2/YR: The names for the data/install disks are hard coded in both the games and their installers. In RA2, they must either be named RA1 or RA2, yet strangely enough YR accepts RA3 and YR1 as valid disk names.

Contributors

• Blade for extensive re-write to a more formal language
• DeeZel for original text
• Tratos for bringing up some ideas
• Kravvitz for some editing, bringing up and explaining some stuff.