You are viewing a specific page revision. To view the current version of this page, click here.
Logging means keeping an ordered record of events, function calls, variable values at a certain time during runtime, etc. This is usually saved in the form of text in a log file. It is an invaluable tool for a software developer, especially when debugging, as it can provide detailed information on what the code is doing at any given moment. Good use cases include ensuring certain blocks of code are being executed, inspecting data values passed between functions, and reporting potential issues.
There are a few different ways to access the logs when working with UE4:
- If your Play-In-Editor session has ended, you can find the full log of that session in YourProjectName\Saved\Logs folder. The logs from previous sessions will be there as well, in case you ever need to access them. If you do not know where your project is located, you can open your project library in the Epic Games launcher, right-click on the project in question, and then select Show in Folder option.
- You can see the log output in real time while playing in Editor in the Output Log tab. If it is not open by default, you can find it under Window->Developer Tools->Output Log. In addition to real-time logging, this tab will keep all log information from all play sessions that happened during the current Unreal Editor session.
- If you have an executable, you can create a shortcut with -Log at the end of its name to open the log as you launch the executable.
- You can open the console when your game is running by pressing the tilde (~) key and access the log by typing in the console command showlog and pressing the Enter key. Note that if you do this during a Play-In-Editor session, clicking x to close the log will close your Unreal Editor session.
Log Verbosity Levels
In certain cases, it is useful to see a less or more detailed log output. Log verbosity levels allow for easy control of the level of detail present in a given log. If a particular log statement is more verbose than the compile-time verbosity, it will not be compiled into the game code. Afterwards, the level of the whole log is set to default verbosity, which can be changed in the Engine.ini file. Runtime verbosity can be changed through the command line. Given a certain verbosity level of the log, only log messages with matching or lower verbosity level will be printed to it. Messages with a higher verbosity level will be ignored.
The following table lists all available verbosity levels, from lowest verbosity to highest:
Verbosity Level | Printed in Console? | Printed in Editor's Log? | Notes
--------------- | ------------------- | ------------------------ | -----------------------------------------------
Fatal | yes | -- | crashes the session even if logging is disabled
Error | yes | yes | log statement text is red
Warning | yes | yes | log statement text is yellow
Display | yes | yes | log statement text is light gray
Log | no | yes | log statement text is light gray
Verbose | no | no | --
VeryVerbose | no | no | --
Each log statement declares which log category it belongs to as well as its verbosity level.
Here is an example of a simple log message:
UE_LOG(LogTemp, Warning, TEXT("Your message"));
is a macro that outputs the log message into the log file. The first input parameter it takes is the name of the logging category. There are many of these categories already built into the engine. If interested, you can see them all in the CoreGlobals.h header file. You can also create your own custom logging categories. The process for doing so is described in the next section.
<syntaxhighlight inline=1>LogTemp</syntaxhighlight> is a temporary category intended to be used during active development only.
The second parameter the
macro takes is the verbosity level of the message. The final parameter in the example above is the text message itself; however, one could add more parameters if the string uses some printf format specifiers. See below for some formatting examples.
Formatting Examples Quick Reference
Logging an FString
UE_LOG(LogTemp, Warning, TEXT("The Actor's name is %s"), *YourActor->GetName());
Logging a Bool
UE_LOG(LogTemp, Warning, TEXT("The boolean value is %s"), ( bYourBool ? TEXT("true") : TEXT("false") ));
Logging an Integer
UE_LOG(LogTemp, Warning, TEXT("The integer value is: %d"), YourInteger);
Logging a Float
UE_LOG(LogTemp, Warning, TEXT("The float value is: %f"), YourFloat);
Logging an FVector
UE_LOG(LogTemp, Warning, TEXT("The vector value is: %s"), *YourVector.ToString());
Logging with Multiple Specifiers
UE_LOG(LogTemp, Warning, TEXT("Current values are: vector %s, float %f, and integer %d"), *YourVector.ToString(), YourFloat, YourInteger);
Custom Log Categories
DECLARE_LOG_CATEGORY_EXTERN(LogCustom, Log, All);
Printing Messages to Screen
Strictly speaking, printing a message to the screen during runtime does not count as logging since the message does not get saved in a file. However, it is often more convenient than using a log message when developing and/or debugging as it allows you to see the message in the game window without needing to have a separate window open for the log. Anything from variable values in real time to function call order can be easily seen this way.
Here's an example of a simple string message:
GEngine->AddOnScreenDebugMessage(-1, 5.f, FColor::White, TEXT("This message will appear on the screen!"));
The first parameter is the key. If key is set to -1, each time this line of code executes, a new message will be added to the screen. For example, if one added this to the
function, the screen would soon flood with a stream of these messages. If the key is a positive integer (the key's type is uint64), each new message replaces the previous message with the same integer as its key. For example, if the above function was called on
with its key modified to 1, only one message would be seen on the screen in game as each new call would simply replace it.
The second parameter is time (in seconds) that the message will be displayed for. It is of type float.
The third parameter is an
that determines the color of the text. It is best to use colors that will be easy to read against the background of the game world. It is easiest to use predefined constants for colors, such as
. See the bottom of this official documentation page for the full list of available color constants.
The fourth parameter is the message itself. Note that the whole of the string must take up only one parameter, therefore, printing using printf parameters requires the use of
GEngine->AddOnScreenDebugMessage(-1, 5.f, FColor::Red, FString::Printf(TEXT("Some variable values: x = %f, y = %f"), x, y));
has two more optional parameters. The fifth parameter is a boolean value that determines whether new messages appear on the top (if true) or the bottom (if false). Note that this only applies in the case of the key value set to -1. The sixth parameter is a 2D vector that determines the scale of the text. This is useful if the messages printed to the screen are too small to be read easily or if they are too big and take up too much screen space.
Visual Studio may underline <syntaxhighlight inline=1>GEngine</syntaxhighlight> and claim that it is undefined. However, you do not need to explicitly include Engine.h or EngineGlobals.h to use it in any of your classes. It should compile and work fine despite the red underline.