Quick answer: Shipping strips logging on purpose: UE_LOG compiles to nothing, Print String nodes do nothing and there is no log file. Set bUseLoggingInShipping = true in your game's Target.cs (add bOverrideBuildEnvironment = true on a launcher engine), or test with a Development build. Print String stays disabled either way.
Everything logs fine in the editor and in Development builds, then the Shipping build you send to testers is silent: no log file in Saved/Logs, no on-screen messages, nothing to go on when it misbehaves. That is by design, and it is configurable.
- Why Shipping is silent
- Fix 1: enable logging in Shipping
- Optional: keep checks and ensures in Shipping
- Fix 2: test with Development, ship with Shipping
- Replace Print String for player-facing builds
- What to log in a release
- Getting the log without asking for it
- Related problems
- Frequently asked questions
Why Shipping is silent
The Shipping configuration exists to produce the smallest, fastest build with no development tooling. By default it defines NO_LOGGING, so every UE_LOG call is removed at compile time and the engine does not open a log file. Other things that disappear in Shipping:
- Print String / Print Text Blueprint nodes: they only run in Development and Debug builds.
- On-screen debug messages from
GEngine->AddOnScreenDebugMessage. - The console and most console commands.
check()andensure(): compiled out unless you enable checks in Shipping.
Fix 1: enable logging in Shipping
In Source/MyGame.Target.cs:
public class MyGameTarget : TargetRules
{
public MyGameTarget(TargetInfo Target) : base(Target)
{
Type = TargetType.Game;
DefaultBuildSettings = BuildSettingsVersion.Latest;
IncludeOrderVersion = EngineIncludeOrderVersion.Latest;
ExtraModuleNames.Add("MyGame");
if (Configuration == UnrealTargetConfiguration.Shipping)
{
bUseLoggingInShipping = true;
// Needed with a launcher (installed) engine, because this changes
// global definitions that the shared build environment fixes.
bOverrideBuildEnvironment = true;
}
}
}
Without bOverrideBuildEnvironment, a launcher engine stops with an error about targets with a modified build environment. A source-built engine can instead use BuildEnvironment = TargetBuildEnvironment.Unique;. Blueprint-only projects have no Target.cs; add a C++ class to the project first.
Rebuild and repackage. The log is written to %LOCALAPPDATA%\MyGame\Saved\Logs\MyGame.log on the player's machine. Launching with -log also opens a live console window.
Optional: keep checks and ensures in Shipping
If you want check() and ensure() to fire in builds that go to testers, add bUseChecksInShipping = true; in the same block. It costs a little performance and turns silent bad states into crashes, which is what you want from a test build and probably not from your final release.
Fix 2: test with Development, ship with Shipping
For internal QA, package the Development configuration: logging, Print String, the console and stat commands all work. Use Shipping for release candidates and the actual release. Keep in mind that Shipping is the build players run, so performance and timing issues can differ; always do a final pass on a Shipping build.
Replace Print String for player-facing builds
Print String is a debugging tool, not UI. If players or testers need to see a message in a Shipping build, use a UMG widget. If you need a record of what happened, use UE_LOG with logging enabled as above, and give your systems their own log categories so the file is readable:
// MyGame.h
DECLARE_LOG_CATEGORY_EXTERN(LogMyGameSave, Log, All);
// MyGame.cpp
DEFINE_LOG_CATEGORY(LogMyGameSave);
// usage
UE_LOG(LogMyGameSave, Warning, TEXT("Save slot %d failed to load: %s"), Slot, *Reason);
What to log in a release
A log file on a player's machine is useful only if they send it to you, and it can contain whatever you wrote to it. Keep Shipping logs to warnings and errors for your own categories (set verbosity per category in DefaultEngine.ini under [Core.Log]), and do not log personal data such as emails or account tokens.
Getting the log without asking for it
Even with logging on, a Shipping log only helps if the player finds %LOCALAPPDATA% and attaches the file. Bugnet's Unreal SDK files fatal errors and ensures from inside the game with recent log output, a screenshot and the hardware attached, and your UMG menu can call ReportBug() for problems that do not crash. With logging enabled in Shipping, those reports carry your own log categories too.
Related problems
- Where Are Unreal Engine Crash Logs? Finding and Reading Them
- How to Read an Unreal Engine Crash Log
- Unreal Engine's Crash Report Client Explained: Setup, Files and Where Reports Go
- How to Fix “Ensure condition failed” in Unreal Engine
Frequently asked questions
Why does UE_LOG not work in a Shipping build?
Shipping builds define NO_LOGGING by default, so UE_LOG calls are compiled out and no log file is written. Set bUseLoggingInShipping = true in the game’s Target.cs to keep them.
Does Print String work in Shipping?
No. Print String and Print Text only run in Development and Debug builds. Use a UMG widget for player-facing messages and UE_LOG for records.
Where is the log file for a packaged Unreal game?
On Windows, in %LOCALAPPDATA%\ProjectName\Saved\Logs on the player’s machine, if logging is enabled for that build configuration.
Why do I get a build environment error after setting bUseLoggingInShipping?
On a launcher-installed engine, also set bOverrideBuildEnvironment = true in the same Target.cs. Source-built engines can use a unique build environment instead.
Development for testers, Shipping with logging for release candidates, and never Print String for anything a player sees.