Class Inheritance: Difference between revisions

From Bohemia Interactive Community
Jump to navigation Jump to search
(added delete keyword)
 
(49 intermediate revisions by 7 users not shown)
Line 1: Line 1:
{{SideTOC}}
{{TOC|side}}
Inheriting classes within the config is a concept that can easily go wrong.
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.
The purpose of this document is to clarify the cause of some common errors and contains instructions on how to resolve these mistakes.
Line 6: Line 6:
== Terms ==
== 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]].
* A '''config''' refers to a config.cpp or config.bin file that is loaded during the game start. It 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.
* 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 base game's root classes.
* '''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.
* The '''master''' config is built from the merging of ''all'' configs to the bin\config.bin, and it is what is seen through the Splendid Config Viewer.
* '''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|addon loading order]]).
This includes both the base game addons as well as user-made addons.
* '''Child configs''' are the configs that are merged into the master config.bin during game load. The order in which they are added is defined by the requiredAddons array within each CfgPatches (see {{Link|#Addon loading order}} below).
* CfgPatches is a necessary prerequisite for '''all''' child configs so that its addon name and required addons (if any) are known.
* Missions and campaigns are not configs, as the pbo they are in may or may not contain a config. This makes them mission pbos or mission addons respectively.


== Basic Config Concepts ==


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


The config is a hierarchical structure based on classes that provides almost all information necessary for the game.
Classes can contain either child classes (see below) or properties.
Objects, their behaviour, user interface elements and even which functions to run on game start are defined through the config.
Properties work similarly to script variables, they have a name and are assigned a value.
However, unlike script variables, properties can only have number values, string values, or (one or multidimensional) arrays that are made up of number or string values.


Classes can contain either child classes (see below) or contain properties. Properties work similar to script variables, they have a name and a value.
=== Parent and Child Classes ===
However unlike script variables properties can only have either number or string values, or (one- or multidimensional) arrays of number or string values.
{{Feature|informative|[[BIS_fnc_returnChildren]] and [[BIS_fnc_getCfgSubClasses]] can be used to easily find hierarchical child subclasses.}}


=== Parent and child classes ===
Due to the hierarchical nature of the config, classes can have parent, child, and sibling classes.
 
While the relationships between classes seem as though they should be rather straightforward, these terms can be used in the case of hierarchy and inheritance.
Due to the hierarchical nature of the config, classes can have '''parent''', '''child''' and '''sibling''' classes:
We will cover these terms in the scope of inheritance further in {{Link|#Basic Inheritance}}, but in most cases, a child class refers to a ''hierarchical'' subclass, and a parent class refers to the base class from which a class inherits.


<syntaxhighlight lang="cpp">
<syntaxhighlight lang="cpp">
Line 33: Line 39:
// ...
// ...
};
};
class Jacob
class Jacob
{
{
Line 42: Line 49:
</syntaxhighlight>
</syntaxhighlight>


In this example, the classes "Esau" and "Jacob" are child classes of "Isaac".
This makes "Isaac" the ''hierarchical'' parent class and "Esau" and "Jacob" sibling classes.
In a more practical example, "arifle_MX_F" and "arifle_Katiba_F" are both child classes of CfgWeapons, and as a result, they too are sibling classes.
<syntaxhighlight lang="cpp">
class CfgWeapons
{
class arifle_MX_F
{
// ...
};
class arifle_Katiba_F
{
// ...
};
};
</syntaxhighlight>


In this example, the parent class of Esau is Isaac, Esau and Jacob are child classes of Isaac, and Jacob is a sibling class of Esau.
=== Basic Inheritance ===
{{Feature|informative|[[BIS_fnc_returnParents]] can be used to easily find the parent base classes from which a class inherits.}}


=== Inheritance ===
A class can inherit properties from another class by defining it as a parent base class.
All properties of the parent base class from which you inherit will also exist within your class, and unless you overwrite them, they will have the same values as the parent base class.
This is extremely 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.


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:
Taking the example from above we can create a common "ChildMaleBase" parent base class.


<syntaxhighlight lang="cpp">
<syntaxhighlight lang="cpp">
Line 60: Line 87:
gender = "male";
gender = "male";
};
};
class Esau: ChildMaleBase
 
class Esau : ChildMaleBase
{
{
firstborn = 1;
firstborn = 1;
// ...
// ...
};
};
class Jacob: ChildMaleBase
 
class Jacob : ChildMaleBase
{
{
firstborn = 0;
firstborn = 0;
Line 73: Line 102:
</syntaxhighlight>
</syntaxhighlight>


In this example, both "Esau" and "Jacob" will inherit the gender property from the new parent base class "ChildMaleBase".


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


<syntaxhighlight lang="cpp">
<syntaxhighlight lang="cpp">
Line 81: Line 112:
class Esau
class Esau
{
{
gender = "male";
gender = "Male";
firstborn = 1;
// ...
};
 
class Jacob : Esau
{
firstborn = 0;
// ...
};
 
class Mary : Esau
{
gender = "Female";
// ...
};
};
</syntaxhighlight>
 
In the above example, while "Mary" overwrites the gender property, the "Mary" class would still inherit the firstborn value of 1 from its new parent base class "Esau".
 
 
Either method is stored, as written, in the master config, and either one achieves the same result for any other classes that access "Isaac".
 
=== Inheritance of Child Classes ===
 
{{Feature|important|You will need to use {{Link|#External Base Classes}} syntax if the base class and base child class are not originally defined in the same config as the classes that are inheriting from them.}}
 
 
Because classes are also inherited like properties, it is possible to inherit from child classes that are defined previously in the same config.
 
<syntaxhighlight lang="cpp">
class Rebecca
{
class Esau
{
gender = "Male";
firstborn = 1;
firstborn = 1;
// ...
// ...
};
};
class Jacob: Esau
};
 
class Isaac : Rebecca
{
class Jacob : Esau
{
{
firstborn = 0;
firstborn = 0;
Line 93: Line 164:
</syntaxhighlight>
</syntaxhighlight>


Both will have the same result in the master config, but note that in the latter example ''Jacob'' is dependant on ''Esau'' which is logically not correct - one can exist without the other.
Because "Isaac" inherits the "Esau" class from "Rebecca", "Jacob" can inherit from "Esau".
Especially when having more than one sibling class, you should consider creating a base class for good practice.
The result is the same as the above example in Basic Inheritance, aside from the introduction of the new "Rebecca" base class.


=== Array+= ===
It is possible to add items to an array inherited from the direct parent. See [[Array+=]] to learn more.


== External base classes ==
== External Base Classes ==


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.
{{Feature|important|The concept of external base classes only applies to addon configs. For mission configs, the [[import (Config)]] keyword fulfills a similar purpose.}}
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.
External base classes are essentially base classes that are first defined ''outside'' of your config, either by the base game or another addon.
It is a simple concept to understand but not so simple to implement correctly.


When using an external base class the first thing you have to do is declaring it.
 
This tells the game engine that there is a sibling class within the master config that your class is somehow based on.
When using an external base class the first thing you have to do is declare it in what is termed a "template" or "skeleton".
It is only important to declare the base class of your class, there is no need to declare the base class of the base class and so on:
These do NOT affect those classes, they merely tell the compiler how they are constructed.
If the classes you declare are not yet discovered by the engine, it will build empty classes waiting to be filled later, based on what inheritance you have written.
As a result, it is important to get the inheritance (if any) right!


<syntaxhighlight lang="cpp">
<syntaxhighlight lang="cpp">
class externalBaseClass; // declare external base class
class externalBaseClass; // declare an external base class "skeleton"
class myClass: externalBaseClass // define that you inherit from it
class myClass : externalBaseClass // define that your class inherits from it
{
{
// ... // start using it
// ... // start using it
Line 117: Line 192:




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 the base class of the base class as well:
An example of both inheritance and the use of external base classes could be the addition of new weapon textures via "hiddenSelections".
 
<syntaxhighlight lang="cpp">
class CfgWeapons
{
class arifle_MX_F; // declare an external base class "skeleton"
class arifle_MX_Black_F : arifle_MX_F // define that your class inherits from the external base class
{
hiddenSelections[] = { "camo1", "camo2" };
hiddenSelectionsTextures[] = { "\A3\Weapons_F_EPB\Rifles\MX_Black\Data\XMX_Base_Black_co.paa", "\A3\Weapons_F_EPB\Rifles\MX_Black\Data\XMX_short_Black_co.paa" };
// ...
};
 
class arifle_MX_khk_F : arifle_MX_Black_F
{
hiddenSelectionsTextures[] = { "\A3\Weapons_F_Exp\Rifles\MX\Data\XMX_Base_khk_co.paa", "\A3\Weapons_F_Exp\Rifles\MX\Data\XMX_Short_khk_co.paa" };
// ...
};
};
</syntaxhighlight>
 
"CfgWeapons" serves as the hierarchical parent class, while "arifle_MX_F", "arifle_MX_Black_F", and "arifle_MX_khk_F" serve as sibling classes.
In this instance, the "arifle_MX_Black_F" is inheriting all of its values from the "arifle_MX_F" external base class skeleton, but it changes the value for the "hiddenSelections" and "hiddenSelectionsTextures" arrays.
When defining "arifle_MX_khk_F" later, instead of changing the "hiddenSelections" array value again, it inherits the changed value from its sibling class, "arifle_MX_Black_F", and changes the necessary values in the "hiddenSelectionsTextures" array for the new textures to appear.
 
 
It is not necessary to declare the base class' inheritance tree (if any) ''if'' you have the correct inherited class' addon in the "requiredAddons" array.
 
=== External Base Child Classes ===
 
In the event that you want to access a child class of a base class, you must declare the child class as a part of the base class.
In order to open the base class, however, you must declare what it inherits from as well.
 
{{Feature|important|Opening the external base class to declare the external child class without defining what the base class inherits from will create the {{Link|#Empty}} syntax. As a result, your base class will not inherit any values that it may have previously, and any class that inherits from it may break.}}


<syntaxhighlight lang="cpp">
<syntaxhighlight lang="cpp">
class externalBaseClass;
class externalRootClass; // declare an external base class "skeleton"
class externalCoolClass: externalBaseClass
class externalBaseClass : externalRootClass // define that the external parent base class inherits from the external base class
{
{
class externalChildClass;
class externalChildClass; // define the external child base class "skeleton"
};
};
class myClass: externalCoolClass
 
class myClass : externalBaseClass // define that your class inherits from the external parent base class
{
{
class externalChildClass: externalChildClass
class myChildClass : externalChildClass // define that your child class inherits from the external child base class
{
{
// ...
// ... add or make changes
};
};
// ...
// ...
};
};
</syntaxhighlight>
</syntaxhighlight>


=== Implied Child Classes ===


This might seem complicated at first but you only have to follow these two rules:
Once an external child class is defined somewhere in the inheritance tree, you will not need to redefine it later, as it is implied by the game engine that that child class is the class you are looking for.
* If your (child) class is based on an external class, declare the external class first
* If you open the brackets of an external class, declare the base class of that class as well


<syntaxhighlight lang="cpp">
class A
{
class B
{
// whatever
};
};


== Addon loading order ==
class C : A
{
class D
{
// whatever
};
};


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.
class E : C
{
class D : D // fairly standard
{
// change things
};
 
class B : B // fairly strange!
{
// change things
};
};
</syntaxhighlight>
 
The reason ''why'' you can access, and use, "B" (which is not a direct child of "E") is due to inheritance. "B" does indeed become a child of "E"!


{{Important|The loading order always needs to be defined!}}


Defining which addons are required by your config is easily done through the ''CfgPatches'':
Note that "A", "B", "C", and "D" could be more simply shown as a skeleton tree defined as follows:
<syntaxhighlight lang="cpp">
class A
{
class B;
};
 
class C : A
{
class D;
};
</syntaxhighlight>
 
 
== Addon Loading Order ==
 
When you are using external base classes it is extremely 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.
 
{{Feature|important|Addons of externally defined base classes should always be defined in the load order to ensure your config is applied correctly.}}
 
Defining which addons are required by your config is easily done through the [[CfgPatches]] class:
 
<syntaxhighlight lang="cpp">
<syntaxhighlight lang="cpp">
class CfgPatches
class CfgPatches
Line 154: Line 311:
{
{
// ...
// ...
requiredAddons[] = { "ExternalAddonA", "ExternalAddonB", ... };
requiredAddons[] = { "ExternalAddonA", "ExternalAddonB", ... }; // List of required addons' CfgPatches class names
// ...
};
};
</syntaxhighlight>
 
Defining the required addons ensures that whatever changes you made, or whatever classes you defined based on external classes, are defined on top of the external addons' config.
Without defining the required addons and load order, there is no guarantee that your config gets applied correctly.
 
{{Feature|informative|{{hl|A3_Data_F_Decade_Loadorder}} is the last vanilla CfgPatches entry in {{arma3}} as of 2.14, so you can use this to overwrite some vanilla configs.}}
 
 
== Empty ==
 
The <syntaxhighlight lang="cpp" inline>class Empty{};</syntaxhighlight> syntax tells the engine that this class should not inherit from other classes. As a result, only non-inherited properties and classes in the class persist.
 
 
As an example, we will return to the {{Link|#Basic Inheritance}} example of the "Isaac" hierarchical parent class and its child classes.
 
<syntaxhighlight lang="cpp">
// Addon One
class Isaac
{
class Esau
{
gender = "Male";
firstborn = 1;
// ...
};
 
class Jacob : Esau
{
firstborn = 0;
// ...
};
};
</syntaxhighlight>
 
 
In a separate addon, loaded later in the {{Link|#Addon Loading Order}}, we can utilize the empty syntax to keep "Jacob" from inheriting the "gender" property. This does not remove the "firstborn" property value of "0" from "Jacob".
 
{{Feature|warning|
Note that the following example will update the base class and will break inheritance. The game will log a warning similar to {{hl|11:34:39 Updating base class RscShortcutButton->RscButton, by a3\editor_f\config.bin/RscDisplayEditObject/Controls/B_OK/ (original bin\config.bin)}}<br/><br/>
'''Updating base classes should be avoided as it breaks compatibility between mods!'''
}}
<syntaxhighlight lang="cpp">
// Addon Two
class Isaac
{
class Jacob {}; // stops inheritance of properties defined in Esau
};
</syntaxhighlight>
 
 
It is worth noting that in the example above, "Isaac" uses a similar structure to the empty syntax.
Anything defined using the empty syntax that does not use inheritance will be defined the same as a "skeleton".
Because "Isaac" does not inherit from any other classes, using this structure functions the same as a "skeleton".
If it was the case that "Isaac" inherited from another class, you would need to use the syntax seen above in {{Link|#External Base Classes}} to preserve the inheritance chain.
 
 
Returning to the {{Link|#Inheritance of Child Classes}} example, we can see how the use of the empty syntax would differ.
 
<syntaxhighlight lang="cpp">
// Addon One
class Rebecca
{
class Esau
{
gender = "Male";
firstborn = 1;
// ...
};
};
 
class Isaac : Rebecca
{
 
class Jacob : Esau
{
firstborn = 0;
// ...
// ...
};
};
};
};
</syntaxhighlight>
</syntaxhighlight>
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.


== Keyword : delete ==
<syntaxhighlight lang="cpp">
Within configs the {{Inline code|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.'''
// Addon Two
class Rebecca; // declare an external base class "skeleton"
class Isaac : Rebecca // define that the external parent class inherits from the external base class
{
class Jacob {}; // stops inheritance of properties defined in Esau
};
</syntaxhighlight>
 
== Delete ==
 
Within configs, the <syntaxhighlight lang="cpp" inline>delete Classname;</syntaxhighlight> keyword is available.
It can be used to delete already existing classes.
{{Feature|important|Classes from which other classes derive cannot be deleted unless the child classes are deleted first.}}


<syntaxhighlight lang="cpp">
<syntaxhighlight lang="cpp">
class Intel
class Intel
{
{
    class AttributeCategories
class AttributeCategories
    {
{
        class Date
class Date
        {
{
            class Attributes
class Attributes
            {
{
                    delete Fog;//Removes Fog attribute from Eden Editor
delete Fog; // removes Fog attribute from Eden Editor
            };
};
        };
};
    };
};
};
};
</syntaxhighlight>
</syntaxhighlight>


<syntaxhighlight lang="cpp">
<syntaxhighlight lang="cpp">
class Intel  
class Intel
{
{
class Attributes
class Attributes
{
{
        class Fog;
class Fog;
class TimeMultiplier: Fog
class TimeMultiplier : Fog
{
{
displayName = "Time Multiplier";
displayName = "Time Multiplier";
tooltip = "Set the time multiplier";
tooltip = "Set the time multiplier";
//...
// ...
};
};
        delete Fog;//Will not work since a children of Fog still exists.
 
delete Fog; // will not work since a child of Fog still exists.
};
};
};
};
</syntaxhighlight>
</syntaxhighlight>
[[Category:ArmA: Addon Configuration]]
 
[[Category:ArmA: Editing]]
 
[[Category:Arma 2: Editing]]
{{GameCategory|ofp|Editing}}
[[Category:Arma 3: Editing]]
{{GameCategory|arma1|Addon Configuration}}
[[Category:Arma 3: Tutorials]]
{{GameCategory|arma1|Editing}}
{{GameCategory|arma2|Editing}}
{{GameCategory|arma3|Editing}}
{{GameCategory|arma3|Tutorials}}
{{GameCategory|tkoh|Editing}}

Latest revision as of 11:46, 27 October 2024

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 refers to a config.cpp or config.bin file that is loaded during the game start. It 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 base game's root classes.
  • The master config is built from the merging of all configs to the bin\config.bin, and it is what is seen through the Splendid Config Viewer.

This includes both the base game addons as well as user-made addons.

  • Child configs are the configs that are merged into the master config.bin during game load. The order in which they are added is defined by the requiredAddons array within each CfgPatches (see Addon loading order below).
  • CfgPatches is a necessary prerequisite for all child configs so that its addon name and required addons (if any) are known.
  • Missions and campaigns are not configs, as the pbo they are in may or may not contain a config. This makes them mission pbos or mission addons respectively.

Basic Config Concepts

The config is a hierarchical structure based on classes that provide almost all information necessary for the game. Objects, their behavior, 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 properties. Properties work similarly to script variables, they have a name and are assigned a value. However, unlike script variables, properties can only have number values, string values, or (one or multidimensional) arrays that are made up of number or string values.

Parent and Child Classes

BIS_fnc_returnChildren and BIS_fnc_getCfgSubClasses can be used to easily find hierarchical child subclasses.

Due to the hierarchical nature of the config, classes can have parent, child, and sibling classes. While the relationships between classes seem as though they should be rather straightforward, these terms can be used in the case of hierarchy and inheritance. We will cover these terms in the scope of inheritance further in Basic Inheritance, but in most cases, a child class refers to a hierarchical subclass, and a parent class refers to the base class from which a class inherits.

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

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

In this example, the classes "Esau" and "Jacob" are child classes of "Isaac". This makes "Isaac" the hierarchical parent class and "Esau" and "Jacob" sibling classes.


In a more practical example, "arifle_MX_F" and "arifle_Katiba_F" are both child classes of CfgWeapons, and as a result, they too are sibling classes.

class CfgWeapons
{
	class arifle_MX_F
	{
		// ...
	};

	class arifle_Katiba_F
	{
		// ...
	};
};

Basic Inheritance

BIS_fnc_returnParents can be used to easily find the parent base classes from which a class inherits.

A class can inherit properties from another class by defining it as a parent base class. All properties of the parent base class from which you inherit will also exist within your class, and unless you overwrite them, they will have the same values as the parent base class. This is extremely 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 create a common "ChildMaleBase" parent base class.

class Isaac
{
	class ChildMaleBase
	{
		gender = "male";
	};

	class Esau : ChildMaleBase
	{
		firstborn = 1;
		// ...
	};

	class Jacob : ChildMaleBase
	{
		firstborn = 0;
		// ...
	};
};

In this example, both "Esau" and "Jacob" will inherit the gender property from the new parent base class "ChildMaleBase".


Alternatively, 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";
		// ...
	};
};

In the above example, while "Mary" overwrites the gender property, the "Mary" class would still inherit the firstborn value of 1 from its new parent base class "Esau".


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

Inheritance of Child Classes

You will need to use External Base Classes syntax if the base class and base child class are not originally defined in the same config as the classes that are inheriting from them.


Because classes are also inherited like properties, it is possible to inherit from child classes that are defined previously in the same config.

class Rebecca
{
	class Esau
	{
		gender = "Male";
		firstborn = 1;
		// ...
	};
};

class Isaac : Rebecca
{
	class Jacob : Esau
	{
		firstborn = 0;
		// ...
	};
};

Because "Isaac" inherits the "Esau" class from "Rebecca", "Jacob" can inherit from "Esau". The result is the same as the above example in Basic Inheritance, aside from the introduction of the new "Rebecca" base class.

Array+=

It is possible to add items to an array inherited from the direct parent. See Array+= to learn more.

External Base Classes

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

External base classes are essentially base classes that are first defined outside of your config, either by the base game or another addon. It is a simple concept to understand but not so simple 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. If the classes you declare are not yet discovered by the engine, it will build empty classes waiting to be filled later, based on what inheritance you have written. As a result, it is important to get the inheritance (if any) right!

class externalBaseClass;			// declare an external base class "skeleton"
class myClass : externalBaseClass	// define that your class inherits from it
{
	// ...							// start using it
};


An example of both inheritance and the use of external base classes could be the addition of new weapon textures via "hiddenSelections".

class CfgWeapons
{
	class arifle_MX_F;						// declare an external base class "skeleton"
	class arifle_MX_Black_F : arifle_MX_F	// define that your class inherits from the external base class
	{
		hiddenSelections[] = { "camo1", "camo2" };
		hiddenSelectionsTextures[] = { "\A3\Weapons_F_EPB\Rifles\MX_Black\Data\XMX_Base_Black_co.paa", "\A3\Weapons_F_EPB\Rifles\MX_Black\Data\XMX_short_Black_co.paa" };
		// ...
	};

	class arifle_MX_khk_F : arifle_MX_Black_F
	{
		hiddenSelectionsTextures[] = { "\A3\Weapons_F_Exp\Rifles\MX\Data\XMX_Base_khk_co.paa", "\A3\Weapons_F_Exp\Rifles\MX\Data\XMX_Short_khk_co.paa" };
		// ...
	};
};

"CfgWeapons" serves as the hierarchical parent class, while "arifle_MX_F", "arifle_MX_Black_F", and "arifle_MX_khk_F" serve as sibling classes. In this instance, the "arifle_MX_Black_F" is inheriting all of its values from the "arifle_MX_F" external base class skeleton, but it changes the value for the "hiddenSelections" and "hiddenSelectionsTextures" arrays. When defining "arifle_MX_khk_F" later, instead of changing the "hiddenSelections" array value again, it inherits the changed value from its sibling class, "arifle_MX_Black_F", and changes the necessary values in the "hiddenSelectionsTextures" array for the new textures to appear.


It is not necessary to declare the base class' inheritance tree (if any) if you have the correct inherited class' addon in the "requiredAddons" array.

External Base Child Classes

In the event that you want to access a child class of a base class, you must declare the child class as a part of the base class. In order to open the base class, however, you must declare what it inherits from as well.

Opening the external base class to declare the external child class without defining what the base class inherits from will create the Empty syntax. As a result, your base class will not inherit any values that it may have previously, and any class that inherits from it may break.
class externalRootClass;						// declare an external base class "skeleton"
class externalBaseClass : externalRootClass	// define that the external parent base class inherits from the external base class
{
	class externalChildClass;					// define the external child base class "skeleton"
};

class myClass : externalBaseClass				// define that your class inherits from the external parent base class
{
	class myChildClass : externalChildClass	// define that your child class inherits from the external child base class
	{
		// ... add or make changes
	};

	// ...
};

Implied Child Classes

Once an external child class is defined somewhere in the inheritance tree, you will not need to redefine it later, as it is implied by the game engine that that child class is the class you are looking for.

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. "B" does indeed become a child of "E"!


Note that "A", "B", "C", and "D" could be more simply shown as a skeleton tree defined as follows:

class A
{
	class B;
};

class C : A
{
	class D;
};


Addon Loading Order

When you are using external base classes it is extremely 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.

Addons of externally defined base classes should always be defined in the load order to ensure your config is applied correctly.

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

class CfgPatches
{
	class MyAddon
	{
		// ...
		requiredAddons[] = { "ExternalAddonA", "ExternalAddonB", ... };	// List of required addons' CfgPatches class names
		// ...
	};
};

Defining the required addons ensures that whatever changes you made, or whatever classes you defined based on external classes, are defined on top of the external addons' config. Without defining the required addons and load order, there is no guarantee that your config gets applied correctly.

A3_Data_F_Decade_Loadorder is the last vanilla CfgPatches entry in Arma 3 as of 2.14, so you can use this to overwrite some vanilla configs.


Empty

The class Empty{}; syntax tells the engine that this class should not inherit from other classes. As a result, only non-inherited properties and classes in the class persist.


As an example, we will return to the Basic Inheritance example of the "Isaac" hierarchical parent class and its child classes.

// Addon One
class Isaac
{
	class Esau
	{
		gender = "Male";
		firstborn = 1;
		// ...
	};

	class Jacob : Esau
	{
		firstborn = 0;
		// ...
	};
};


In a separate addon, loaded later in the Addon Loading Order, we can utilize the empty syntax to keep "Jacob" from inheriting the "gender" property. This does not remove the "firstborn" property value of "0" from "Jacob".

Note that the following example will update the base class and will break inheritance. The game will log a warning similar to 11:34:39 Updating base class RscShortcutButton->RscButton, by a3\editor_f\config.bin/RscDisplayEditObject/Controls/B_OK/ (original bin\config.bin)

Updating base classes should be avoided as it breaks compatibility between mods!
// Addon Two
class Isaac
{
	class Jacob {};	// stops inheritance of properties defined in Esau
};


It is worth noting that in the example above, "Isaac" uses a similar structure to the empty syntax. Anything defined using the empty syntax that does not use inheritance will be defined the same as a "skeleton". Because "Isaac" does not inherit from any other classes, using this structure functions the same as a "skeleton". If it was the case that "Isaac" inherited from another class, you would need to use the syntax seen above in External Base Classes to preserve the inheritance chain.


Returning to the Inheritance of Child Classes example, we can see how the use of the empty syntax would differ.

// Addon One
class Rebecca
{
	class Esau
	{
		gender = "Male";
		firstborn = 1;
		// ...
	};
};

class Isaac : Rebecca
{

	class Jacob : Esau
	{
		firstborn = 0;
		// ...
	};
};
// Addon Two
class Rebecca;			// declare an external base class "skeleton"
class Isaac : Rebecca	// define that the external parent class inherits from the external base class
{
	class Jacob {};		// stops inheritance of properties defined in Esau
};

Delete

Within configs, the delete Classname; keyword is available. It can be used to delete already existing classes.

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.
	};
};