ArmA 1 Forum, ArmA 1 Home, ArmA 1 Config, ArmA 1 Tools, ArmA 1 File Formats, ArmA 1 Missions, ArmA 1 3D Modeling, ArmA 1 Terrain, ArmA 1 Texturing, ArmA 1 Scripting

ArmA 1 aka Armed Assault (ArmA)

Description

The model configuration file (model cfg for short) is the interface between a (P3D) model and the program. The model.cfg would only be necessary if you intend to preview animations and such in O2 using your model.

It is a look-up table which is processed during the binarization process, to tell the program what the various sections of the model are, which skeleton it uses and how it is animated.

This system is more flexible than the one previously used, because all the information is stored for the model and not for the object class in the main configuration file. This means that several object classes can use the same model and don't have to define the animations for this model seperately.

A goal of the system is to seperate the configuration of models into a designer and an artist part.

This is done by the introduction of a class AnimationSources in the main configuration file (the designer part) and the continuing use of the class Animations in the model cfg (the artist part).

Most models will be able to inherit definitions from basic definitions on higher levels in the data hierarchy. An example hierarchy is described and illustrated below.

p:\ofp2\vehicles\model.cfg - Defines a class Default.
p:\ofp2\vehicles\land\wheeled\model.cfg - Defines a class Car.
p:\ofp2\vehicles\land\wheeled\landrover\model.cfg - Defines a class LandRover.

p:\ofp2\vehicles\land\wheeled\landrover\lr6x6_3 - In the model is a property config=LandRover (this feature is not implemented and may never be).
p:\ofp2\vehicles\land\wheeled\landrover\lr6x6_mg240 - Has a LR6x6_MG240.cfg, which inherits from class LandRover and adds definitions for a turret.

At this stage the file is parsed during the binarization of a model and animations can be played in the program with user actions. Eventually they can be previewed using the Buldozer viewer.

The model cfg follows a set of naming conventions. There can be several model cfg files, named by default model.cfg, named after the folder name or named after a specific model. In the case that both a model.cfg and <foldername>.cfg are present, only the latter is parsed. The <modelname>.cfg is parsed alongside of the other model cfg files and therefore the model can be seen as an additional level in the hierarchy.

When we have an example folder called humr with a model called hmmwv.p3d, we can use the following names: model.cfg or humr.cfg and next to that a hmmwv.cfg.

In the future a model may support a named property called config, which tells the model which class in the model cfg to use. There is some doubt whether this feature will be implemented though.

There are model cfg files that do not relate directly to a specific model, but are used for the generic base class definitions, such as class Default.

The functionality of the animations has been extended, allowing to do in scripting what was done before using RTM animations. In addition, animation controllers were introduced, which allow for the control of different animations at the same time. This opens up possibilities like having several turrets on a tank.

The model cfg and main configuration file (where classes cfgModels, cfgSkeletons and Animations were previously defined) operate together to smooth the change from the old to the new system. When a model cfg and the main configuration file both define the same model, the model cfg takes precedence.

This segment defines all properties of each model. The class names correspond to the model name. Here you define which sections the model has, which skeleton it uses and its animations.

//Declare base classes
class CarAnimations
{
	class IndicatorSpeed;
};
class CfgModels
{
	class Car; //Declare base class
	class Vodnik: Car
	{
		sectionsInherit = "Car"; //Inherit all sections from class Car
					 //Add new section
		sections[] =
		{
			"section1"
		};
		skeletonName = "Vodnik"; //Use the Vodnik skeleton

		class Animations: CarAnimations //Inherit from generic animations
		{
			class IndicatorSpeed: IndicatorSpeed //Redefine the maximum value
			{                                    //for the speed indicator
				maxValue = 40;
			};
		};
	};
};

This segment defines the skeleton for the model and the bones that it uses.

class CfgSkeletons
{
	class Car; //Define base class

	class Vodnik: Car
	{
		skeletonInherit = "Car"; //Inherit all bones from class Car
		skeletonBones[] =        //Add two new bones. The movement
		{                        //of bone2 is linked to bone1
			"bone1", ""
			"bone2", "bone1"
		};
	};
};

This segment is part of class cfgModels and defines all animations used by the model.

class Animations
{
	class FrontWheelR
	{
		type = "rotationX"; //The type of animation
		source = "wheel";   //The controller that provides input
		selection = "pravy predni"; //The name of the skeleton bone used
		axis = "";                  //The name of the axis in the model
		memory = true; //Is the axis defined in the memory level of the
                      //model or not?
		sourceAddress = "loop"; //Does the animation loop or not?
		minValue = 0; //The minimum value of the motion range
                     //i.e. The controller input when animation phase is 0
		maxValue = 1; //The maximum value of the motion range
                     //i.e. The controller input when animation phase is 1
		angle0 = 0;   //The starting angle of this animation, where the
                     //animation phase is 0
		angle1 = "rad -360"; //The ending angle of this animation,
	};                      //where the animation phase is 1
};

These are the controllers that provide the input for the animation phase of the animations. These controllers are defined in the animation class using the source parameter. It's also possible to define custom controllers in the main configuration file, using class AnimationSources.

This table outlines the Animation Types you can use for an animation class.

This table outlines the properties (or entries) that each defined animation class expects to be present based on the animation type that is specified.

Eg. If you specify a an animation type of 'rotationX' you must specify the animation properties 'angle0' and 'angle1'.

This is not part of the model cfg, but part of the main configuration file. This class allows you to define new user controllers or modify selected properties of existing controllers.

Defining custom controllers makes it possible to use one custom controller for several different animations. If an animation does not define the source parameter, the program looks for a custom controller defined in this class with the same name.

It is also possible to override an existing controller using this class, but be extremely careful in this case. The custom controller will hide the original one, leaving the latter inaccessible. Overriding is done using the :: notation in the source parameter as can be seen in the third example.

class AnimationSources
{
	class MachineGun
	{
		source = "reload"; //The controller used for the definition of
                          //this controller
		weapon = MachineGun25W; //In the specific case of using the reload
	};                         //controller, the weapon class name
};
class AnimationSources
{
	//Used by animations called Door1, which don't define the source
	//parameter or by animations that define source Door1;
	class Door1
	{
		source = "user"; //The controller is defined as a user animation
		animPeriod = 1;  //The animation period used for this controller
		initPhase=1;     //Initial phase when object is created
	};
};
class AnimationSources
{
	class wheel
	{
		source = "::wheel"; //Overriding the existing wheel controller
	};
};

You can find a howto for the CfgModels (a working attack helicopter) as well as a howto on cfgModels & cfgSkeletons with additional description and examples.