{"name":"Class Inheritance","title":"Class Inheritance","type":"topic","url":"https://community.bistudio.com/wiki/Class_Inheritance","revid":370018,"updated":"2024-10-27T10:46:30Z","aliases":["Class Inheritence"],"markdown":"Inheriting classes within the config is a concept that can easily go wrong.\nThe purpose of this document is to clarify the cause of some common errors and contains instructions on how to resolve these mistakes.\n\n### Terms\n\n- 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.\n- 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.\n- 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.\n\nThis includes both the base game addons as well as user-made addons.\n\n- **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).\n- CfgPatches is a necessary prerequisite for **all** child configs so that its addon name and required addons (if any) are known.\n- 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.\n\n### Basic Config Concepts\n\nThe config is a hierarchical structure based on classes that provide almost all information necessary for the game.\nObjects, their behavior, user interface elements, and even which functions to run on game start are defined through the config.\n\nClasses can contain either child classes (see below) or properties.\nProperties work similarly to script variables, they have a name and are assigned a value.\nHowever, 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.\n\n#### Parent and Child Classes\n\n> [!NOTE]\n> BIS_fnc_returnChildren and BIS_fnc_getCfgSubClasses can be used to easily find hierarchical child subclasses.\n\nDue to the hierarchical nature of the config, classes can have parent, child, and sibling classes.\nWhile the relationships between classes seem as though they should be rather straightforward, these terms can be used in the case of hierarchy and inheritance.\nWe 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.\n\n```cpp\nclass Isaac\n{\n    class Esau\n    {\n        gender = \"male\";\n        firstborn = 1;\n        // ...\n    };\n\n    class Jacob\n    {\n        gender = \"male\";\n        firstborn = 0;\n        // ...\n    };\n};\n```\n\nIn this example, the classes \"Esau\" and \"Jacob\" are child classes of \"Isaac\".\nThis makes \"Isaac\" the *hierarchical* parent class and \"Esau\" and \"Jacob\" sibling classes.\n\nIn 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.\n\n```cpp\nclass CfgWeapons\n{\n    class arifle_MX_F\n    {\n        // ...\n    };\n\n    class arifle_Katiba_F\n    {\n        // ...\n    };\n};\n```\n\n#### Basic Inheritance\n\n> [!NOTE]\n> BIS_fnc_returnParents can be used to easily find the parent base classes from which a class inherits.\n\nA class can inherit properties from another class by defining it as a parent base class.\nAll 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.\nThis 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.\n\nTaking the example from above we can create a common \"ChildMaleBase\" parent base class.\n\n```cpp\nclass Isaac\n{\n    class ChildMaleBase\n    {\n        gender = \"male\";\n    };\n\n    class Esau : ChildMaleBase\n    {\n        firstborn = 1;\n        // ...\n    };\n\n    class Jacob : ChildMaleBase\n    {\n        firstborn = 0;\n        // ...\n    };\n};\n```\n\nIn this example, both \"Esau\" and \"Jacob\" will inherit the gender property from the new parent base class \"ChildMaleBase\".\n\nAlternatively, we can use \"Esau\" as a base class for \"Jacob\" and overwrite the \"firstborn\" property:\n\n```cpp\nclass Isaac\n{\n    class Esau\n    {\n        gender = \"Male\";\n        firstborn = 1;\n        // ...\n    };\n\n    class Jacob : Esau\n    {\n        firstborn = 0;\n        // ...\n    };\n\n    class Mary : Esau\n    {\n        gender = \"Female\";\n        // ...\n    };\n};\n```\n\nIn 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\".\n\nEither method is stored, as written, in the master config, and either one achieves the same result for any other classes that access \"Isaac\".\n\n#### Inheritance of Child Classes\n\n> [!IMPORTANT]\n> 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.\n\nBecause classes are also inherited like properties, it is possible to inherit from child classes that are defined previously in the same config.\n\n```cpp\nclass Rebecca\n{\n    class Esau\n    {\n        gender = \"Male\";\n        firstborn = 1;\n        // ...\n    };\n};\n\nclass Isaac : Rebecca\n{\n    class Jacob : Esau\n    {\n        firstborn = 0;\n        // ...\n    };\n};\n```\n\nBecause \"Isaac\" inherits the \"Esau\" class from \"Rebecca\", \"Jacob\" can inherit from \"Esau\".\nThe result is the same as the above example in Basic Inheritance, aside from the introduction of the new \"Rebecca\" base class.\n\n#### Array+=\n\nIt is possible to add items to an array inherited from the direct parent. See Array+= to learn more.\n\n### External Base Classes\n\n> [!IMPORTANT]\n> The concept of external base classes only applies to addon configs. For mission configs, the import (Config) keyword fulfills a similar purpose.\n\nExternal base classes are essentially base classes that are first defined *outside* of your config, either by the base game or another addon.\nIt is a simple concept to understand but not so simple to implement correctly.\n\nWhen using an external base class the first thing you have to do is declare it in what is termed a \"template\" or \"skeleton\".\nThese do NOT affect those classes, they merely tell the compiler how they are constructed.\nIf 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.\nAs a result, it is important to get the inheritance (if any) right!\n\n```cpp\nclass externalBaseClass;            // declare an external base class \"skeleton\"\nclass myClass : externalBaseClass    // define that your class inherits from it\n{\n    // ...                            // start using it\n};\n```\n\nAn example of both inheritance and the use of external base classes could be the addition of new weapon textures via \"hiddenSelections\".\n\n```cpp\nclass CfgWeapons\n{\n    class arifle_MX_F;                        // declare an external base class \"skeleton\"\n    class arifle_MX_Black_F : arifle_MX_F    // define that your class inherits from the external base class\n    {\n        hiddenSelections[] = { \"camo1\", \"camo2\" };\n        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\" };\n        // ...\n    };\n\n    class arifle_MX_khk_F : arifle_MX_Black_F\n    {\n        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\" };\n        // ...\n    };\n};\n```\n\n\"CfgWeapons\" serves as the hierarchical parent class, while \"arifle_MX_F\", \"arifle_MX_Black_F\", and \"arifle_MX_khk_F\" serve as sibling classes.\nIn 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.\nWhen 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.\n\nIt is not necessary to declare the base class' inheritance tree (if any) *if* you have the correct inherited class' addon in the \"requiredAddons\" array.\n\n#### External Base Child Classes\n\nIn 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.\nIn order to open the base class, however, you must declare what it inherits from as well.\n\n> [!IMPORTANT]\n> 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.\n\n```cpp\nclass externalRootClass;                        // declare an external base class \"skeleton\"\nclass externalBaseClass : externalRootClass    // define that the external parent base class inherits from the external base class\n{\n    class externalChildClass;                    // define the external child base class \"skeleton\"\n};\n\nclass myClass : externalBaseClass                // define that your class inherits from the external parent base class\n{\n    class myChildClass : externalChildClass    // define that your child class inherits from the external child base class\n    {\n        // ... add or make changes\n    };\n\n    // ...\n};\n```\n\n#### Implied Child Classes\n\nOnce 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.\n\n```cpp\nclass A\n{\n    class B\n    {\n        // whatever\n    };\n};\n\nclass C : A\n{\n    class D\n    {\n        // whatever\n    };\n};\n\nclass E : C\n{\n    class D : D    // fairly standard\n    {\n        // change things\n    };\n\n    class B : B    // fairly strange!\n    {\n        // change things\n    };\n};\n```\n\nThe 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\"!\n\nNote that \"A\", \"B\", \"C\", and \"D\" could be more simply shown as a skeleton tree defined as follows:\n\n```cpp\nclass A\n{\n    class B;\n};\n\nclass C : A\n{\n    class D;\n};\n```\n\n### Addon Loading Order\n\nWhen 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.\n\n> [!IMPORTANT]\n> Addons of externally defined base classes should always be defined in the load order to ensure your config is applied correctly.\n\nDefining which addons are required by your config is easily done through the CfgPatches class:\n\n```cpp\nclass CfgPatches\n{\n    class MyAddon\n    {\n        // ...\n        requiredAddons[] = { \"ExternalAddonA\", \"ExternalAddonB\", ... };    // List of required addons' CfgPatches class names\n        // ...\n    };\n};\n```\n\nDefining 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.\nWithout defining the required addons and load order, there is no guarantee that your config gets applied correctly.\n\n> [!NOTE]\n> `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.\n\n### Empty\n\nThe `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.\n\nAs an example, we will return to the Basic Inheritance example of the \"Isaac\" hierarchical parent class and its child classes.\n\n```cpp\n// Addon One\nclass Isaac\n{\n    class Esau\n    {\n        gender = \"Male\";\n        firstborn = 1;\n        // ...\n    };\n\n    class Jacob : Esau\n    {\n        firstborn = 0;\n        // ...\n    };\n};\n```\n\nIn 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\".\n\n> [!WARNING]\n> 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)`\n>\n> **Updating base classes should be avoided as it breaks compatibility between mods!**\n\n```cpp\n// Addon Two\nclass Isaac\n{\n    class Jacob {};    // stops inheritance of properties defined in Esau\n};\n```\n\nIt is worth noting that in the example above, \"Isaac\" uses a similar structure to the empty syntax.\nAnything defined using the empty syntax that does not use inheritance will be defined the same as a \"skeleton\".\nBecause \"Isaac\" does not inherit from any other classes, using this structure functions the same as a \"skeleton\".\nIf 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.\n\nReturning to the Inheritance of Child Classes example, we can see how the use of the empty syntax would differ.\n\n```cpp\n// Addon One\nclass Rebecca\n{\n    class Esau\n    {\n        gender = \"Male\";\n        firstborn = 1;\n        // ...\n    };\n};\n\nclass Isaac : Rebecca\n{\n\n    class Jacob : Esau\n    {\n        firstborn = 0;\n        // ...\n    };\n};\n```\n\n```cpp\n// Addon Two\nclass Rebecca;            // declare an external base class \"skeleton\"\nclass Isaac : Rebecca    // define that the external parent class inherits from the external base class\n{\n    class Jacob {};        // stops inheritance of properties defined in Esau\n};\n```\n\n### Delete\n\nWithin configs, the `delete Classname;` keyword is available.\nIt can be used to delete already existing classes.\n\n> [!IMPORTANT]\n> Classes from which other classes derive cannot be deleted unless the child classes are deleted first.\n\n```cpp\nclass Intel\n{\n    class AttributeCategories\n    {\n        class Date\n        {\n            class Attributes\n            {\n                delete Fog;    // removes Fog attribute from Eden Editor\n            };\n        };\n    };\n};\n```\n\n```cpp\nclass Intel\n{\n    class Attributes\n    {\n        class Fog;\n        class TimeMultiplier : Fog\n        {\n            displayName = \"Time Multiplier\";\n            tooltip = \"Set the time multiplier\";\n            // ...\n        };\n\n        delete Fog;    // will not work since a child of Fog still exists.\n    };\n};\n```","sections":[{"heading":null,"level":1,"markdown":"Inheriting classes within the config is a concept that can easily go wrong.\nThe purpose of this document is to clarify the cause of some common errors and contains instructions on how to resolve these mistakes."},{"heading":"Terms","level":3,"markdown":"- 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.\n- 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.\n- 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.\n\nThis includes both the base game addons as well as user-made addons.\n\n- **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).\n- CfgPatches is a necessary prerequisite for **all** child configs so that its addon name and required addons (if any) are known.\n- 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."},{"heading":"Basic Config Concepts","level":3,"markdown":"The config is a hierarchical structure based on classes that provide almost all information necessary for the game.\nObjects, their behavior, user interface elements, and even which functions to run on game start are defined through the config.\n\nClasses can contain either child classes (see below) or properties.\nProperties work similarly to script variables, they have a name and are assigned a value.\nHowever, 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."},{"heading":"Parent and Child Classes","level":4,"markdown":"> [!NOTE]\n> BIS_fnc_returnChildren and BIS_fnc_getCfgSubClasses can be used to easily find hierarchical child subclasses.\n\nDue to the hierarchical nature of the config, classes can have parent, child, and sibling classes.\nWhile the relationships between classes seem as though they should be rather straightforward, these terms can be used in the case of hierarchy and inheritance.\nWe 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.\n\n```cpp\nclass Isaac\n{\n    class Esau\n    {\n        gender = \"male\";\n        firstborn = 1;\n        // ...\n    };\n\n    class Jacob\n    {\n        gender = \"male\";\n        firstborn = 0;\n        // ...\n    };\n};\n```\n\nIn this example, the classes \"Esau\" and \"Jacob\" are child classes of \"Isaac\".\nThis makes \"Isaac\" the *hierarchical* parent class and \"Esau\" and \"Jacob\" sibling classes.\n\nIn 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.\n\n```cpp\nclass CfgWeapons\n{\n    class arifle_MX_F\n    {\n        // ...\n    };\n\n    class arifle_Katiba_F\n    {\n        // ...\n    };\n};\n```"},{"heading":"Basic Inheritance","level":4,"markdown":"> [!NOTE]\n> BIS_fnc_returnParents can be used to easily find the parent base classes from which a class inherits.\n\nA class can inherit properties from another class by defining it as a parent base class.\nAll 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.\nThis 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.\n\nTaking the example from above we can create a common \"ChildMaleBase\" parent base class.\n\n```cpp\nclass Isaac\n{\n    class ChildMaleBase\n    {\n        gender = \"male\";\n    };\n\n    class Esau : ChildMaleBase\n    {\n        firstborn = 1;\n        // ...\n    };\n\n    class Jacob : ChildMaleBase\n    {\n        firstborn = 0;\n        // ...\n    };\n};\n```\n\nIn this example, both \"Esau\" and \"Jacob\" will inherit the gender property from the new parent base class \"ChildMaleBase\".\n\nAlternatively, we can use \"Esau\" as a base class for \"Jacob\" and overwrite the \"firstborn\" property:\n\n```cpp\nclass Isaac\n{\n    class Esau\n    {\n        gender = \"Male\";\n        firstborn = 1;\n        // ...\n    };\n\n    class Jacob : Esau\n    {\n        firstborn = 0;\n        // ...\n    };\n\n    class Mary : Esau\n    {\n        gender = \"Female\";\n        // ...\n    };\n};\n```\n\nIn 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\".\n\nEither method is stored, as written, in the master config, and either one achieves the same result for any other classes that access \"Isaac\"."},{"heading":"Inheritance of Child Classes","level":4,"markdown":"> [!IMPORTANT]\n> 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.\n\nBecause classes are also inherited like properties, it is possible to inherit from child classes that are defined previously in the same config.\n\n```cpp\nclass Rebecca\n{\n    class Esau\n    {\n        gender = \"Male\";\n        firstborn = 1;\n        // ...\n    };\n};\n\nclass Isaac : Rebecca\n{\n    class Jacob : Esau\n    {\n        firstborn = 0;\n        // ...\n    };\n};\n```\n\nBecause \"Isaac\" inherits the \"Esau\" class from \"Rebecca\", \"Jacob\" can inherit from \"Esau\".\nThe result is the same as the above example in Basic Inheritance, aside from the introduction of the new \"Rebecca\" base class."},{"heading":"Array+=","level":4,"markdown":"It is possible to add items to an array inherited from the direct parent. See Array+= to learn more."},{"heading":"External Base Classes","level":3,"markdown":"> [!IMPORTANT]\n> The concept of external base classes only applies to addon configs. For mission configs, the import (Config) keyword fulfills a similar purpose.\n\nExternal base classes are essentially base classes that are first defined *outside* of your config, either by the base game or another addon.\nIt is a simple concept to understand but not so simple to implement correctly.\n\nWhen using an external base class the first thing you have to do is declare it in what is termed a \"template\" or \"skeleton\".\nThese do NOT affect those classes, they merely tell the compiler how they are constructed.\nIf 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.\nAs a result, it is important to get the inheritance (if any) right!\n\n```cpp\nclass externalBaseClass;            // declare an external base class \"skeleton\"\nclass myClass : externalBaseClass    // define that your class inherits from it\n{\n    // ...                            // start using it\n};\n```\n\nAn example of both inheritance and the use of external base classes could be the addition of new weapon textures via \"hiddenSelections\".\n\n```cpp\nclass CfgWeapons\n{\n    class arifle_MX_F;                        // declare an external base class \"skeleton\"\n    class arifle_MX_Black_F : arifle_MX_F    // define that your class inherits from the external base class\n    {\n        hiddenSelections[] = { \"camo1\", \"camo2\" };\n        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\" };\n        // ...\n    };\n\n    class arifle_MX_khk_F : arifle_MX_Black_F\n    {\n        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\" };\n        // ...\n    };\n};\n```\n\n\"CfgWeapons\" serves as the hierarchical parent class, while \"arifle_MX_F\", \"arifle_MX_Black_F\", and \"arifle_MX_khk_F\" serve as sibling classes.\nIn 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.\nWhen 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.\n\nIt is not necessary to declare the base class' inheritance tree (if any) *if* you have the correct inherited class' addon in the \"requiredAddons\" array."},{"heading":"External Base Child Classes","level":4,"markdown":"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.\nIn order to open the base class, however, you must declare what it inherits from as well.\n\n> [!IMPORTANT]\n> 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.\n\n```cpp\nclass externalRootClass;                        // declare an external base class \"skeleton\"\nclass externalBaseClass : externalRootClass    // define that the external parent base class inherits from the external base class\n{\n    class externalChildClass;                    // define the external child base class \"skeleton\"\n};\n\nclass myClass : externalBaseClass                // define that your class inherits from the external parent base class\n{\n    class myChildClass : externalChildClass    // define that your child class inherits from the external child base class\n    {\n        // ... add or make changes\n    };\n\n    // ...\n};\n```"},{"heading":"Implied Child Classes","level":4,"markdown":"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.\n\n```cpp\nclass A\n{\n    class B\n    {\n        // whatever\n    };\n};\n\nclass C : A\n{\n    class D\n    {\n        // whatever\n    };\n};\n\nclass E : C\n{\n    class D : D    // fairly standard\n    {\n        // change things\n    };\n\n    class B : B    // fairly strange!\n    {\n        // change things\n    };\n};\n```\n\nThe 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\"!\n\nNote that \"A\", \"B\", \"C\", and \"D\" could be more simply shown as a skeleton tree defined as follows:\n\n```cpp\nclass A\n{\n    class B;\n};\n\nclass C : A\n{\n    class D;\n};\n```"},{"heading":"Addon Loading Order","level":3,"markdown":"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.\n\n> [!IMPORTANT]\n> Addons of externally defined base classes should always be defined in the load order to ensure your config is applied correctly.\n\nDefining which addons are required by your config is easily done through the CfgPatches class:\n\n```cpp\nclass CfgPatches\n{\n    class MyAddon\n    {\n        // ...\n        requiredAddons[] = { \"ExternalAddonA\", \"ExternalAddonB\", ... };    // List of required addons' CfgPatches class names\n        // ...\n    };\n};\n```\n\nDefining 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.\nWithout defining the required addons and load order, there is no guarantee that your config gets applied correctly.\n\n> [!NOTE]\n> `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."},{"heading":"Empty","level":3,"markdown":"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.\n\nAs an example, we will return to the Basic Inheritance example of the \"Isaac\" hierarchical parent class and its child classes.\n\n```cpp\n// Addon One\nclass Isaac\n{\n    class Esau\n    {\n        gender = \"Male\";\n        firstborn = 1;\n        // ...\n    };\n\n    class Jacob : Esau\n    {\n        firstborn = 0;\n        // ...\n    };\n};\n```\n\nIn 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\".\n\n> [!WARNING]\n> 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)`\n>\n> **Updating base classes should be avoided as it breaks compatibility between mods!**\n\n```cpp\n// Addon Two\nclass Isaac\n{\n    class Jacob {};    // stops inheritance of properties defined in Esau\n};\n```\n\nIt is worth noting that in the example above, \"Isaac\" uses a similar structure to the empty syntax.\nAnything defined using the empty syntax that does not use inheritance will be defined the same as a \"skeleton\".\nBecause \"Isaac\" does not inherit from any other classes, using this structure functions the same as a \"skeleton\".\nIf 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.\n\nReturning to the Inheritance of Child Classes example, we can see how the use of the empty syntax would differ.\n\n```cpp\n// Addon One\nclass Rebecca\n{\n    class Esau\n    {\n        gender = \"Male\";\n        firstborn = 1;\n        // ...\n    };\n};\n\nclass Isaac : Rebecca\n{\n\n    class Jacob : Esau\n    {\n        firstborn = 0;\n        // ...\n    };\n};\n```\n\n```cpp\n// Addon Two\nclass Rebecca;            // declare an external base class \"skeleton\"\nclass Isaac : Rebecca    // define that the external parent class inherits from the external base class\n{\n    class Jacob {};        // stops inheritance of properties defined in Esau\n};\n```"},{"heading":"Delete","level":3,"markdown":"Within configs, the `delete Classname;` keyword is available.\nIt can be used to delete already existing classes.\n\n> [!IMPORTANT]\n> Classes from which other classes derive cannot be deleted unless the child classes are deleted first.\n\n```cpp\nclass Intel\n{\n    class AttributeCategories\n    {\n        class Date\n        {\n            class Attributes\n            {\n                delete Fog;    // removes Fog attribute from Eden Editor\n            };\n        };\n    };\n};\n```\n\n```cpp\nclass Intel\n{\n    class Attributes\n    {\n        class Fog;\n        class TimeMultiplier : Fog\n        {\n            displayName = \"Time Multiplier\";\n            tooltip = \"Set the time multiplier\";\n            // ...\n        };\n\n        delete Fog;    // will not work since a child of Fog still exists.\n    };\n};\n```"}],"categories":["ArmA: Armed Assault: Addon Configuration","ArmA: Armed Assault: Editing","Arma 2: Editing","Arma 3: Editing","Arma 3: Tutorials","Operation Flashpoint: Editing","Take On Helicopters: Editing"],"groups":["Configuration"]}