Hi lovely people,
After collecting and absorbing the gleaned information over the Internet, I’ve formed up a systematic understanding for myself of the module adding process. And I want to share it with you in hope of helping you out possibly.
Below it’s a chart I made to give you a general overview of all the concepts involved and their relationships in this process.
Let’s start with the most general concept: Build a code file to something that a computer can understand. The top frame illustrates this whole process.
You have your Source code written in plain text and you would want to convert to something that a computer can make use of, which are often referred to as **Target **in the context of programming. The **Target **can be an executable with exe extension, or a library with .lib or .dll extension. Lib and dll extension respectively corresponds to the static library and the dynamic library. You can specify what kind of target you want to have as output by giving some instructions to the program that does the conversion.
Now we usually talk about “compile” your code or program. However, this is a simplified way of addressing this process that is pretty handy for conversations between experienced programmers but may cause some misunderstandings for new comers.
The process of turning **Source code **files to **Target **(exe, lib, dll) in fact involves two separate processes, **Compiling **and Linking. For more info on compiling and linking please refer to this.
For what is a library and the difference between static and dynamic library please check this. The process of **C****ompiling **and **Linking **together can be referred to as Building.
Now that we have a general idea of **Building **some Source code to Target. We can move on to the specific case of UE Modules.
A Module in UE is essentially a collection of header files and cpp files, the number depending on how you write your module, together with a single build.cs file. These .h and .cpp are serving as **Source Code **while the .build.cs file specifies how the **Building **process should build **Source Code **into Target. You will also find some .target.cs files inside your UE project folder. These .target.cs files are accompanying the UE project so inside a UE project folder you will find a set of .target.cs files while .build.cs files are per module, which means you will find a build.cs file for each module inside that module’s folder but you will only have one set of target.cs files sitting inside your UE project folder.
Let’s me show you:
Test is a ue project named test. Click into the source folder and you will find two .target.cs files. Both of them specify a kind of target you can build your project (also modules inside) into. Inside the Source folder there is a Test folder. Despite having the same name as your project, it is nothing but a module like all other modules you can create and add into the source. By this, I mean you can rename Test to Module_A and add another folder in Source named Module_B. Provided that you also rename the files inside Test folder to match Module_A, everything will holds. Module_A is no different from Module_B in terms of how your project sees them.
Inside the Test folder, there is the build.cs file for Test module as well as the Test.h and Test.cpp for implementing the Test Module. TestGameModeBase.cpp and TestGameModeBase.h are also implemented as part of your Test Module.
For the reference on .Build.cs file and .Target.cs file, please refer to http://dmitry-yanovsky.com/2015/08/u…e-demystified/ and https://docs.unrealengine.com/en-US/…les/index.html
In the middle frame in the above chart, you can see that modules are collected inside a visual studio solution, which is manifested as Test.sln in the above folder structure. This solution file is actually generated by the .uproject file.
As illustrated in the bottom frame in the chart, when you right click your uproject file and choose “generate visual studio solution” Unreal Build Tool (UBT) will be invoked and it will look inside the source folder for the modules, the .target.cs files as well as the build.cs files for each module to generate a solution file that includes the modules files and uses the information collected from .build.cs and .target.cs files to set up the build configuration settings for the generated solution file.
After that, you can build this solution file as illustrated in the middle frame. Your modules will be compiled according to the build configuration and output as exe or library accordingly. For the build configurations in the solution file, please refer to these sources: https://docs.unrealengine.com/en-US/…ons/index.html and https://docs.unrealengine.com/en-US/…cts/index.html
Now if you are specifying Editor in your .target.cs file, you will get your modules compiled as DLL. Then how do you load this DLL when you open up your project in UE Editor? This is where editing the content of uproject file comes into play.
.uproject file is JSON file in which you can write down what modules you want to load for this project. It will have one module added already by default, which is the module that has the same name as your project. You can think of this module as your “game” module but in reality, it is as much a module as any custom module.
So let’s do a recap. The whole flow works like this: You add a module folder in your Source folder and add some .h .cpp for it. Then create a .build.cs file for it. Modify the .target.cs file according it so that the code for this module actually gets compiled when you build it in VS. Now your Source Code is all set.
Then “Generate Visual Studio Solution” from .uproject, which will update the current solution to reflect your changes. After this, build your solution to build the modules inside and you will get your Target output.
Modify .uproject file to load the modules you want.