Class Inheritance - Revision history

R3vo: /* Empty */

2024-10-27T10:46:30Z

Empty

← Older revision		Revision as of 12:46, 27 October 2024
Line 352:		Line 352:
	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".		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">		<syntaxhighlight lang="cpp">
	// Addon Two		// Addon Two
Line 400:		Line 404:
	};		};
	</syntaxhighlight>		</syntaxhighlight>


	== Delete ==		== Delete ==

Ansin11: /* Basic Config Concepts */ Added Array+=

2024-02-21T15:16:40Z

Basic Config Concepts: Added Array+=

← Older revision		Revision as of 17:16, 21 February 2024
Line 167:		Line 167:
	The result is the same as the above example in Basic Inheritance, aside from the introduction of the new "Rebecca" base class.		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 ==

Lou Montana: Add category

2023-12-06T09:48:06Z

Add category

← Older revision		Revision as of 11:48, 6 December 2023
Line 16:		Line 16:
	== Basic Config Concepts ==		== Basic Config Concepts ==

	The config is a hierarchical structure based on classes that provide almost all information necessary for the game.		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.		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.		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.		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.		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.
Line 26:		Line 26:
	{{Feature\|informative\|[[BIS_fnc_returnChildren]] and [[BIS_fnc_getCfgSubClasses]] can be used to easily find hierarchical child subclasses.}}		{{Feature\|informative\|[[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.		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.		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 {{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.		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.

Line 49:		Line 49:
	</syntaxhighlight>		</syntaxhighlight>

	In this example, the classes "Esau" and "Jacob" are child classes of "Isaac".		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.		This makes "Isaac" the ''hierarchical'' parent class and "Esau" and "Jacob" sibling classes.

Line 153:		Line 153:
	};		};
	};		};
	class Isaac: Rebecca
			class Isaac : Rebecca
	{		{

	class Jacob : Esau		class Jacob : Esau
	{		{
Line 164:		Line 164:
	</syntaxhighlight>		</syntaxhighlight>

			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.

	~~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.~~

	== External Base Classes ==		== External Base Classes ==
Line 202:		Line 202:
	// ...		// ...
	};		};

	class arifle_MX_khk_F : arifle_MX_Black_F		class arifle_MX_khk_F : arifle_MX_Black_F
	{		{
Line 237:		Line 238:
	// ... add or make changes		// ... add or make changes
	};		};

	// ...		// ...
	};		};
Line 268:		Line 270:
	// change things		// change things
	};		};

	class B : B // fairly strange!		class B : B // fairly strange!
	{		{
Line 290:		Line 293:
	};		};
	</syntaxhighlight>		</syntaxhighlight>


	== Addon Loading Order ==		== Addon Loading Order ==
Line 315:		Line 319:

	{{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.}}		{{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 ==		== Empty ==
Line 349:		Line 354:
	class Isaac		class Isaac
	{		{
	class Jacob{}; // stops inheritance of properties defined in Esau		class Jacob {}; // stops inheritance of properties defined in Esau
	};		};
	</syntaxhighlight>		</syntaxhighlight>


	It is worth noting that in the example above, "Isaac" uses a similar structure to the empty syntax.		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".		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".		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.		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.

Line 373:		Line 378:
	};		};
	};		};

	class Isaac : Rebecca		class Isaac : Rebecca
	{		{
Line 389:		Line 395:
	class Isaac : Rebecca // define that the external parent class inherits from the external base class		class Isaac : Rebecca // define that the external parent class inherits from the external base class
	{		{
	class Jacob{}; // stops inheritance of properties defined in Esau		class Jacob {}; // stops inheritance of properties defined in Esau
	};		};
	</syntaxhighlight>		</syntaxhighlight>


	== Delete ==		== Delete ==

	Within configs, the <syntaxhighlight lang="cpp" inline>delete Classname;</syntaxhighlight> keyword is available.		Within configs, the <syntaxhighlight lang="cpp" inline>delete Classname;</syntaxhighlight> keyword is available.
	It can be used to delete already existing classes.		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.}}		{{Feature\|important\|Classes from which other classes derive cannot be deleted unless the child classes are deleted first.}}
Line 427:		Line 434:
	// ...		// ...
	};		};

	delete Fog; // will not work since a child of Fog still exists.		delete Fog; // will not work since a child of Fog still exists.
	};		};
Line 433:		Line 441:


			{{GameCategory\|ofp\|Editing}}
	{{GameCategory\|arma1\|Addon Configuration}}		{{GameCategory\|arma1\|Addon Configuration}}
	{{GameCategory\|arma1\|Editing}}		{{GameCategory\|arma1\|Editing}}

Lou Montana: Text replacement - "import" to "import (Config)"

2023-10-30T16:54:34Z

Text replacement - "import" to "import (Config)"

← Older revision		Revision as of 18:54, 30 October 2023
Line 170:		Line 170:
	== External Base Classes ==		== External Base Classes ==

	{{Feature\|important\|The concept of external base classes only applies to addon configs. For mission configs, the [[import]] keyword fulfills a similar purpose.}}		{{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 essentially base classes that are first defined ''outside'' of your config, either by the base game or another addon.		External base classes are essentially base classes that are first defined ''outside'' of your config, either by the base game or another addon.

AVespade: /* Addon Loading Order */ Updated latest load order as of Arma 3 version 2.14

2023-09-19T05:42:59Z

Addon Loading Order: Updated latest load order as of Arma 3 version 2.14

← Older revision		Revision as of 07:42, 19 September 2023
Line 314:		Line 314:
	Without defining the required addons and load order, there is no guarantee that your config gets applied correctly.		Without defining the required addons and load order, there is no guarantee that your config gets applied correctly.

	~~{{Wiki\|TODO\|Update this with A3_Data_F_Decade_Loadorder once 2.14 is live.}}~~		{{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.}}
	{{Feature\|informative\|{{hl\|~~A3_Data_F_AoW_Loadorder~~}} is the last vanilla CfgPatches entry in {{arma3}} as of 2.12, so you can use this to overwrite some vanilla configs.}}

	== Empty ==		== Empty ==

R3vo: /* Addon Loading Order */ TODO

2023-08-20T12:31:08Z

Addon Loading Order: TODO

← Older revision		Revision as of 14:31, 20 August 2023
Line 314:		Line 314:
	Without defining the required addons and load order, there is no guarantee that your config gets applied correctly.		Without defining the required addons and load order, there is no guarantee that your config gets applied correctly.

			{{Wiki\|TODO\|Update this with A3_Data_F_Decade_Loadorder once 2.14 is live.}}
	{{Feature\|informative\|{{hl\|A3_Data_F_AoW_Loadorder}} is the last vanilla CfgPatches entry in {{arma3}} as of 2.12, so you can use this to overwrite some vanilla configs.}}		{{Feature\|informative\|{{hl\|A3_Data_F_AoW_Loadorder}} is the last vanilla CfgPatches entry in {{arma3}} as of 2.12, so you can use this to overwrite some vanilla configs.}}

AVespade: /* Addon Loading Order */ Linked to CfgPatches page

2023-06-01T20:48:53Z

Addon Loading Order: Linked to CfgPatches page

← Older revision		Revision as of 22:48, 1 June 2023
Line 297:		Line 297:
	{{Feature\|important\|Addons of externally defined base classes should always be defined in the load order to ensure your config is applied correctly.}}		{{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:		Defining which addons are required by your config is easily done through the [[CfgPatches]] class:

	<syntaxhighlight lang="cpp">		<syntaxhighlight lang="cpp">
Line 305:		Line 305:
	{		{
	// ...		// ...
	requiredAddons[] = { "ExternalAddonA", "ExternalAddonB", ... };		requiredAddons[] = { "ExternalAddonA", "ExternalAddonB", ... }; // List of required addons' CfgPatches class names
	// ...		// ...
	};		};

AVespade: Specifications to distinguish between inheritance and hierarchical parent and child classes

2023-06-01T20:37:38Z

Specifications to distinguish between inheritance and hierarchical parent and child classes

Show changes

AVespade: /* External Base Child Classes / formatting as well as slight tweaks to reflect the new / Empty */ documentation

2023-05-28T05:55:12Z

External Base Child Classes: formatting as well as slight tweaks to reflect the new Empty: documentation

← Older revision		Revision as of 07:55, 28 May 2023
Line 213:		Line 213:
	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 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.		In order to open the base class, however, you must declare what it inherits from as well.
	Opening the base class to declare the child class without defining what the base class inherits from will ~~declare~~ the base class ~~as if~~ it ~~is the first time~~ it ~~is being defined~~.
			{{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">

AVespade: /* External Base Child Classes */ further wiki formatting

2023-05-25T22:51:39Z

External Base Child Classes: further wiki formatting

← Older revision		Revision as of 00:51, 26 May 2023
Line 217:		Line 217:
	<syntaxhighlight lang="cpp">		<syntaxhighlight lang="cpp">
	class externalRootClass; // declare an external base class "skeleton"		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 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 externalChildClass; // define the external child base class "skeleton"
Line 224:		Line 224:
	class myClass : externalBaseClass // define that your class inherits from the external parent base class		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		class myChildClass : externalChildClass // define that your child class inherits from the external child base class
	{		{
	// ... add or make changes		// ... add or make changes