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 bin\config.bin is the father of all other configs. It forms the first state of the master config.bin and consists of the root classes.
• The master config is the in-game one and built from the merging of all configs to the bin\config.bin. This includes both the base game addons as well as user addons. It can be viewed through the Splendid Config

Viewer.

• child configs are merged into the master config.bin during game load. The order in which they get added is defined by the requiredAddons array within each CfgPatches (see addon loading order).

• • CfgPatches is a necessary prerequisite for all child configs so that it's addon name is known and required addons (if any)

• be aware that missions and campaigns are not configs. The pbo they are in, may or may not contain a config. Thus making them mission pbos or mission addons respectively.

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 classes 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;
		// ...
	};
	class Mary : Esau
	{
		gender = "Female"; // firstborn too
	};
};

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 
//
class myClass: externalBaseClass	// define that you inherit from it
{
	// ...							// start using it
};

It is not necessary to declare the base class'es inheritance tree (if any) IF you have the correct requiredaddons[]=.

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 externalBaseClass;
};
///////////
class myClass: externalRootClass
{
	class externalChildClass: externalChildClass // import ALL the values from the original
	{
		// ... add, or make, changes
	};
	// ...
};

implied child classes

class A
{
	class B
	{
		/* ...whatever */
	};
};

class C : A
{
	class D
	{
		// whatever
	};
};

class E : C
{
	class D : D // fairly standard
	{
		// change things
	};
	class B : B // fairly strange!
	{
		// change things
	};
};

• the reason *why* you can access, and use, B (which is not a direct child of E) is due to inheritance, it does indeed become a child of E!
• Note that A B C D could easily be simply a skeleton tree defined as follows:

//////template
class A
{
	class B;
};

class C : A
{
	class D;
};
//// end template

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.

empty

An often misunderstood is the empty{} syntax.

class thingy{}; this removes everything, including embedded classes within the scope of the parent class it is found in.

• it cannot be used for any class that has inheritance, because that is simply seen as a skeleton tree.
• it is NOT the same thing as class thingy;

delete

Within configs the delete classname keyword is available. It can be used to delete already existing classes. However, classes from which other classes derive 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 child of Fog still exists.
	};
};