Class Inheritance

Inheriting classes within the config is a concept that can easily go wrong. The purpose of this document is to clarify the cause of some common errors and contains instructions on how to resolve these mistakes.

Terms

• A config is a config.cpp or config.bin file that is loaded during the game start. It is does not refer to a Model Config.
• The master config is the in-game one and only config built from all other configs. This includes both the base game configs as well as addon configs. It can be viewed through the Splendid Config Viewer.
• bin or config.bin is the father of all other configs. It forms the first state of the master config.bin and consists of the base game configs.
• child configs are added on top of the config.bin. The order in which they get added is defined by the requiredAddons array within the CfgPatches (see addon loading order).

In addition to the master config there are also the

• mission config and
• campaign config

that are sperate from the master config.

Basic config concepts

The config is a hierarchical structure based on classes that provides almost all information necessary for the game. Objects, their behaviour, user interface elements and even which functions to run on game start are defined through the config.

Classes can contain either child classes (see below) or contain properties. Properties work similar to script variables, they have a name and a value. However unlike script variables properties can only have either number or string values, or (one- or multidimensional) arrays of number or string values.

Parent and child classes

Due to the hierarchical nature of the config, classes can have parent, child and sibling classes:

class Isaac
{
	class Esau
	{
		gender = "male";
		firstborn = 1;
		// ...
	};
	class Jacob
	{
		gender = "male";
		firstborn = 0;
		// ...
	};
};

In this example, the parent class of both Esau and Jacob are child classes of Isaac. They are siblings.

Inheritance

A class can inherit properties from sibling classes by defining it as a base class. This means that all properties of that base class will also exist within your class and, unless you overwrite them, will have the same values as in the base class. This is extremly useful for quickly writing sibling classes that share properties, or to build a class on top of another class that has the same properties with only minor value changes.

Taking the example from above we can either create a common ChildMaleBase base class:

class Isaac
{
	class ChildMaleBase
	{
		gender = "male";
	};
	class Esau: ChildMaleBase
	{
		firstborn = 1;
		// ...
	};
	class Jacob: ChildMaleBase
	{
		firstborn = 0;
		// ...
	};
};

Or we can use Esau as a base class for Jacob and overwrite the firstborn property:

class Isaac
{
	class Esau
	{
		gender = "male";
		firstborn = 1;
		// ...
	};
	class Jacob: Esau
	{
		firstborn = 0;
		// ...
	};
};

Either method is stored, as written, in the master config, and either one achieves the same result for any other classes that accesses Isaac.

External base classes

⚠

The concept of external base classes only applies to addon configs. For mission configs the import keyword fulfills a similar purpose.

Especially when writing the config for a new vehicle or changing the config of an existing vehicle, you will sooner or later come on contact with external base classes. External base classes are simply base classes that you did not define within your own config but were defined either by the base game or another addon.

It's a simple concept to understand but not as easy to implement correctly.

When using an external base class the first thing you have to do is declare it in what is termed a 'template' or 'skeleton'. These do NOT affect those classes, they merely tell the compiler how they are constructed. Stated wrongly, the game engine ill throw a fit if it discovers what-you-say, is not-the-truth. It does this as it is progressively builds the master config. Secondly, IF the class(es) you declare are not yet 'discovered' by the engine, it will build empty classes waiting to be filled later, based on what you say here. Thus, it is important to get the inheritance (if any) right!.

// the external 'skeleton'
class externalBaseClass;			// declare an external base class that has no inheritance (and is in the scope of the class it's in)
//
class myClass: externalBaseClass	// define that you inherit from it
{
	// ...							// start using it
};

NOTE: if the above 'base' class has inheritance, you must declare it. And so on. All the way back to an non inherited class. Many people make the mistake of believing this is not necessary. This only because, the engine has already located and built the class of interest.

Example two

Now what if you want to access a child class of the base class? At this point, you are accessing the contents of the base class, and thus you need to declare this class s being part of that base class eg a child and it's parent.

//// the 'template'
class externalRootClass
{
	class externalChildClass;
};
///////////
class myClass: externalRootClass
{
	class externalChildClass: externalChildClass // import ALL the  values from the original
	{
		// ... add, or make, changes
	};
	// ...
};

A 'root' class is one that comes from the root of the master config.bin The above is a primitive example of classes embedded in classes(only one deep). A 'skeleton' tree describes exactly where the class you want to access is.

Note that a root class can inherit from another root class, thus, you need to:

class root1;
class root2: root1
{
   etc
};

Addon loading order

When you are using external base classes it is extremly important to define what addons your addon depends on, or in other words, which external base classes need to be already loaded when your config gets loaded.

⚠

The loading order always needs to be defined!

Defining which addons are required by your config is easily done through the CfgPatches:

class CfgPatches
{
	class MyAddon
	{
		// ...
		requiredAddons[] = { "ExternalAddonA", "ExternalAddonB", ... };
		// ...
	};
};

This ensures that whatever changes you made or whatever classes based on some other classes you defined are applied on top of the external addons child config. Without this there is no guarantee that your config gets applied correctly.

ⓘ

A3_Data_F_Oldman_Loadorder is the last vanilla CfgPatches entry in Arma 3 2.00, so you can put this to overwrite some vanilla configs.

delete

Within configs the delete class keyword is available. It can be used to delete already existing classes. However, classes that other classes derive from cannot be deleted unless the child classes are deleted first.

class Intel
{
    class AttributeCategories
    {
        class Date
        {
            class Attributes
            {
                    delete Fog;//Removes Fog attribute from Eden Editor
            };
        };
    };
};

class Intel 
{
	class Attributes
	{
        class Fog;
		class TimeMultiplier: Fog
		{
			displayName = "Time Multiplier";
			tooltip = "Set the time multiplier";
			//...
		};
        delete Fog;//Will not work since a children of Fog still exists.
	};
};