UE4 configuration file Detailed

A general overview of the configuration

In UE4, the configuration file (config) is actually an. ini file. Can be used to set the value of the property to initialize at load time, and the configuration information is implemented in the format of the key-value pair. Unreal 4 official documents only simple rules of use, in order to know more about the need to see the source code, so here I share their learning results to everyone. A complete configuration file format is shown in 1-1.

Figure 1-1 Configuration file format

The configuration files we see are generally only available in the following four paths.

1. \engine\config and its sub-directories

2. \engine\saved\config and its subdirectories (generated after engine run)

3. Projects\[projectname]\config and its sub-directories

4. Projects\[projectname]\saved\config and its subdirectories (generated after the game project is run)

As marked above, the configuration information for path 2 and path 4 is generated later.

Two concept notes

For the sake of clarity, here is a brief description of some basic principles and concepts.

2.1 Concepts

Section: Like 1-1, there are many modules in each profile, and the title of each module is a section.

Flush: In the code, the class Fconfigcacheini has a method called flush (). Its surface meaning is flushing, rushing, in the code to indicate the memory information (that is, the cached configuration information) accurately written into the file.

Gconfig: A configuration cache variable for the global space. Define the following fconfigcacheini* gconfig =NULL; store different information in different situations, 2-1, figure 2-2. There will be a more detailed explanation of the contents of the Gconfig.

Figure 2-1 Gconfig stored information when running the Pure engine editor

2.2 Fundamentals

2.2.1 Configuration file structure

In order to have an overall understanding of the configuration file, we have to understand the structure of the configuration file.

1. Configure classification

Compat(compatibility)

Deviceprofiles(Device overview file)

Editor(editors)

Editorgameagnostic(editor game Unknown configuration information)

Editorkeybindings(Editor key binding)

Editorusersettings(editor user settings)

engine (engines)

Game (games)

Input(inputs)

Lightmass (lighting construction related)

Scalability( extensibility )

Editorlayout (Editor layout)

Sourcecontrolsettings (source control settings, only exist in the engine and Project save directory)

Templatedefs (template definition, only exists in the engine and Project save directory)

The above basically describes the type of all configuration files, different types of configuration settings are placed in different files.

2. File Hierarchy

When the configuration file is read from Base.ini, the values in the files in the file structure are overwritten with the previous values. Engine text

The files in the folder are applied to all projects, and the files for the specific project should be in the files in the project directory. Finally, all specific project and platform-specific differences are saved to the [projectdirectory]/saved/config/[platform]/

[In the Category].ini file. The following is an example file hierarchy for the engine class of the configuration file.

①engine/config/base.ini the file is generally empty

②engine/config/baseengine.ini

③engine/config/[platform]/[platform]engine.ini

④[projectdirectory]/config/defaultengine.ini

⑤[projectdirectory]/config/[platform]/[platform]engine.ini

⑥[projectdirectory]/saved/config/[platform]/engine.ini

Explain the above: when we read the configuration information, we read the path as above, because the content of the later levels is progressively more targeted to the project, so the higher the hierarchy, the higher the priority of the configuration information. Also note that many of the configuration file names are fixed (except for the brackets), so these profiles cannot be deleted and modified arbitrarily. The next principle 2.2.1 will make a further elaboration here.

2.2.1 Configuration file Directory analysis

In the general overview, we simply describe the directory of the configuration file, which we want to take out for further analysis.

The configuration files we see are generally only available in the following four paths.

1. \engine\config and its sub-directories

2. \engine\saved\config and its subdirectories (generated after engine run)

3. Projects\[projectname]\config and its sub-directories

4. Projects\[projectname]\saved\config and its subdirectories (generated after the game project is run)

The following first give 4 directory of the file content, make an intuitive understanding, and please remember these 4 paths and their corresponding number, the following will be mentioned many times.

Figure 2-2 Engine Directory comparison diagram of the configuration file (paths 1 and 2)

Figure 2-3 The comparison diagram of the configuration files in the project directory (paths 3 and 4)

So what is the relationship between the four directories and what does it do?

First of all, we need to know that the configuration file in Path 1 path 3 is not generated when the engine is running, so the files and information in it need you to manually add, of course, the engine path 1 configuration files are already written, generally do not need to change ( but when you create a blank project, the engine will be for you in the path automatic generation of Defaultengine.ini and Defaultgame.ini in 3 can also generate Defaulteditor.ini, if you use the provided template, you will also generate Defaulteditor.ini and Defaultinput.ini configuration file ).

Based on the comparison chart I gave above, we can look at the engine and the project separately. When you just open an editor with a pure engine, there is no relationship with the project. The engine generates the configuration information in path 2 based on its own code logic and the configuration information in Path 1. Similarly, when we run the project, we generate the configuration information for Route 4 based on the code logic and the configuration information for Path 3, but it is a little different. Since we have just looked at the file hierarchy of the principle 2.2.1, it should be understood that the build of the project (under Path 4) also has an indirect relationship with the engine configuration file in Path 1 (no relationship to Path 2).

In addition, we compare the above is actually path 3 and path 4\windows, and path 4 under the structure is generally the following, There is also a Cleansourceconfigs folder in addition to the Platform folder.

Figure 2-4 Projects\[projectname]\saved\config directory structure diagram

The information we generate is distributed in these two folders, the Cleansource folder is actually the sum of the configuration information of path 1 and path 3 (that is, the configuration information before the file hierarchy ⑥), and the other with the game itself, Platform-related differential configuration information is eventually stored in the Windows (corresponding platform) directory.

To summarize, both the engine and the project, the configuration information under config is added manually, and the save/config is generated after the engine or project is run.

Note : If you delete the Defaultengine.ini under the project, it will cause the project not to run, prompting the following error. (This means that the configuration under the engine directory must have [URL] gamename=projectname).

Figure 2-5 Error of missing Defaultengine.ini

Three Use process

3.1 Automatic configuration

In UE4, we use the features provided by the engine to easily save and read configuration information by simply configuring it. The basic flow is as follows:

Figure 3-1 Automatic implementation of the property configuration flowchart

1. In order to indicate which variable should be read from which configuration file, the Uclass of the class containing the variables

The config identifier should be assigned to the macro.

Note: You must provide a category for the Config identifier (such as game). This determines the configuration file from which the class's variables are read and saved to which configuration file. All possible classifications are defined in class Configcacheini (actually, gconfig objects). A categorized list of all profiles is described in the second part.

2. To specify a variable to read and save to a configuration file, you must also provide the config identifier for the property Uproperty () macro. As shown

The config identifier for the property does not provide any classification. The Examplevariable property can now be read from any of the game profiles in the configuration file structure (described in the second section), as long as the information is specified by the following syntax (this modulename refers to package packages, The ExampleClass is the corresponding class name. ）

3. This step is not stated in the official documentation. The fact is that the value of the Tag Config property differs from the value of the constructor when it is initialized. If you only follow the two steps above, you will find that the corresponding configuration file does not have the variable you want. Because when the engine executes saveconfig, it iterates through all the properties of the tag config and determines whether the current object's Config property is the same as the value of the same property of the same type of CDO, and if there is no modification to the same certificate, there is no need to store it in the configuration file.

So here we have two ways to modify the value of a property, one is to modify the value of the Config property in a method, and then call it at the beginning of the game. The other is to set this config property to a blueprint that can be read and written and modified in the blueprint configuration. Finally, after these modifications are performed, it is important to call Saveconfig to save the configuration information and write the information to the configuration file.

Note : CDO is classdefaultobject. This involves UE4 the internal structure of each object, temporarily understanding that the system will construct an object of that class by default at run time, and that the object only executes the constructor.

3.2 Manual Encoding Configuration

In addition to the automatic configuration method described above, we can also save configuration information to any file by encoding. Here we have to use the Saveconfig function, and the Saveconfig () function can be called on a class that uses the configuration class modifier. In general, variables saved by Saveconfig () are located in the format [(package). ClassName)] named in the section header. For example, the [/script/engine.engine] section in Defaultengine.ini points to the engine class stored inside the engine package.

Figure 3-3 Engine package under the engines directory

Here is an example of how to use manual encoding to save information to a specified location in Gamemode.

1. First we define a method to save the configuration information of a type to gconfig. Over here

The polygon logic is to determine if the current value is the default value to be configured? Is it already present with Gconfig? is the default and does not perform gconfig->setbool operations in Gconfig, save the bool variable to gconfig.

2. Then execute this method in the Gamemode initialization phase and call Saveconfig save.

Ggameusersettingsini is the global fstring, the path of the gameusersetting configuration file is saved, so here we can save the Gamemode configuration information in the gameusersetting. Other configuration file paths can be found in Core.cpp.

Four Configuration file Storage Flow

Figure 4-3 Configuration information General storage flowchart

Note : Saveconfig is a uobject method that can be called on any subclass of the tag config.

Five Principle and characteristic analysis

5.1 Meaning of the configuration file

In the first touch of the configuration file, my biggest question is that the configuration file is generally used to read, why to generate so many configuration files and information?

This can be understood here,

The first time the game project is run, the engine will first read the engine catalog \config, the configuration information inside the game directory \config, and the configuration file path ( the configuration path when running the game is [projectdirectory]/saved/ config/[platform]/) stored inside the gconfig. The other configuration information is then written to Gconfig (a simple description) at the time each module executes its saveconfig () and finally to the generated configuration file by Gconfig. ( Note: The file generated here refers to the projects\[projectname]\saved\config and its subdirectories, the second section is explained )

And the second run, because the configuration file has been generated before. The engine will first read all the data inside the configuration file into the Gconfig (including the first run generated), and then if you find that the configuration file information is missing or changed, in the execution of Saveconfig () is again written to gconfig inside, Also write to path 4 (see section 2.2.1) in the configuration file.

Through above, we can know. In fact, it doesn't make sense to modify the configuration information that we generated later, because every time we run the game we want to store the configuration information as we would like it in the code or project. This part of the generated configuration information can be read and exploited after the game is run. However, we can modify the information in Path 3 (see section 2.2.1, project default configuration), and this information is in effect as soon as we want to modify it. If you have written all the information in the path 3 below, you will find that the configuration information in Path 4 has no content.

5.2 How configuration files are stored

Gconfig has appeared many times before, we need to know what gconfig is. In fact, Gconfig is a configuration information cache, which will keep all configuration information in the runtime.

The following is the class that gconfig belongs to and the inheritance diagram.

Figure 5-1 Gconfig inheritance diagram

As we can see from the above figure, Gconfig can be described as a three-layer map (the lowest level is Multimap), which in turn stores the configuration path, configures section, and configures properties and values. The detailed structure can be further understood by us.

Figure 5-2 Gconfig content Structure analysis diagram

There is a need to explain this type of fconfigfile. As you can see from the two graphs above, a configuration file Fconfigfile class consists of 5 members, and this 5 member can explain many of the previous rules and phenomena

1.FName record the type of this configuration file

2.SourceIniHierarchy as we explained in Chapter 2.2, section 1, this member variable describes the hierarchy of the file, and our final difference information is stored below \ Windows According to this structure.

3.SourceConfigFile represents the configuration content that was loaded from the local start (actually loading the configuration information in Path 1 and path 4 as described in the second section 2.2.2)

4.dirty file is modified, when writing a file, if this value is false will not rewrite the configuration file

5.NoSave file is not saved

5.3 Configuration files and inheritance

Both the Config Uclass and the Uproperty identifiers inherit the quilt class. This means that subclasses can read or save all the variables specified in the parent class as config, and they will be in the same profile category. The variable is placed under the section with the name of the child class. For example, the configuration file information for the Childexampleclass that inherits ExampleClass looks like the following line of code, and will be saved in the same config configuration file.

The subclass cannot negate the config flag that inherits from the parent class, but the subclass can change the. ini file by re-declaring the CONFIG keyword and specifying a different file name.

5.4 Configuration based on each instance of the object

Unreal Engine 4 can save the configuration information of an object to any desired configuration file. If the perobjectconfig identifier is used for Uclass macros, the configuration information for this class is stored on a per-object instance basis, where each object instance is part of the. ini file, named after the object, in the following format [ObjectName ClassName]. This keyword is passed to the subclass.

This example can refer to the Udeviceprofile class, which has a predecessor macro of Uclass (Config=deviceprofiles, Perobjectconfig, blueprintable). Indicates that a configuration file with the name Deviceprofile.ini is generated, and the information inside is as follows.

[XboxOne Deviceprofile]

Key=value

[IPhone5S Deviceprofile]

Key=value

The code details inside is actually the execution of the Saveconfig, will determine whether the current object is marked with Perobjectconfig, yes, for this object to mark a separate configuration information (such as section = L "iphone5s Deviceprofile "), otherwise it will be uniformly labeled within this class (such as section = L"/script/

Udpmessaging.udpmessagingsettings ").

Six Other

1. The configuration file generation is much earlier than the content writing, if it is the first run, at the beginning of the project run through the Generatedestinifile to generate an empty configuration file.

2. fpaths contains various directory paths for game engineering, such as Enginedir,gamesaveddir,gamecontentdir, which is important for the storage path of configuration information.

UE4 configuration file Detailed