Packaging#

Commands use Windows PowerShell. $UE, $Project, $Target and $Release stand for the engine root, the full path of the .uproject, the Game target name and the release directory.

Common steps#

1. Build the Shipping Game:

   & "$UE/Engine/Build/BatchFiles/Build.bat" $Target Win64 Shipping "-Project=$Project" -WaitMutex -NoHotReload -NoUBA

2. Use Platforms → Windows → Package Project with Shipping, or run BuildCookRun:

   & "$UE/Engine/Build/BatchFiles/RunUAT.bat" -nocompileuat -WaitForUATMutex BuildCookRun "-project=$Project" -NoP4 -platform=Win64 -clientconfig=Shipping -cook -stage -pak -package -archive "-archivedirectory=$Release" -nobuild -unattended -utf8output

3. Check the package: UnrealPak.exe <the .pak in the release> -List lists the package contents; then start the game from the release directory, enter a level that uses scripts and call a representative function. A clean exit alone does not prove the scripts loaded.

Package with source#

Use this to get the game delivered first, or when players may view and modify scripts: the runtime reads .as files and compiles them, so startup includes script compile time. Source can be extracted from the Pak.

Follow steps 1, 2 and 3 of the common steps.

Without a precompiled cache, the project Script/ folder is packed into the Pak.

Package with bytecode#

Do not ship the main AS source, and cut startup preprocessing and compiling. Functions still run as bytecode in the VM, and the program data in the cache can be analyzed, so it is not encryption or reverse-engineering protection.

1. Delete the old cache files from your project's Script/ folder: Binds.Cache, Binds.Cache.Headers and PrecompiledScript*.Cache.
2. Build the Shipping Game as in step 1 of the common steps.
3. Generate matching precompiled data with the Shipping exe; data generated by the editor cannot be used. The process exits by itself once it has written its output:

   & "<Shipping.exe from the build output>" -as-generate-precompiled-data -as-write-bind-db -unattended -nocrashreports -NullRHI -NoMessaging -NoASDebugServer -NoSound -NoSplash

4. Copy the three files it actually wrote back into your project's Script/ byte for byte, without mixing in files from another run; stop if you cannot find all three:

   Binds.Cache
   Binds.Cache.Headers
   PrecompiledScript.Cache

The output is in <project>/Saved/Cooked/Windows/<project name>/Script/.

5. Build, package and check again as in steps 1, 2 and 3 of the common steps; when checking, confirm that the package has the three cache files and no project .as files.

• Files a package without source needs: the three cache files above; when all three exist and are non-empty, a Shipping build by default packs only these three files into the Pak and no longer includes the project .as.
• Old caches are rejected: when the cache and exe do not match, a package without source reports ASR-PRECOMPILED-NO-SOURCE: No compatible precompiled script cache and no script source files are available., and you must regenerate and republish a matching cache. Loaded angelscript precompiled data was for a different build configuration. Discarding all precompiled data. means the cache was generated with another configuration.

Half-AOT packaging#

Convert the AS functions that can be generated into C++ and compile them into the game, which reduces virtual machine overhead; the bytecode entry points are still kept at runtime. The cost is longer C++ compile times and a larger exe. See the Hazelight documentation.

1. Delete the old cache files from your project's Script/ folder: Binds.Cache, Binds.Cache.Headers and PrecompiledScript*.Cache, and the old AS_JITTED_CODE in the project module.
2. Build the Shipping Game and package once, as in steps 1 and 2 of the common steps.
3. Generate matching precompiled data by running the Shipping exe in the package folder; data generated by the editor cannot be used. The process exits by itself when it has finished writing:

   & "<Shipping.exe from the build output>" -as-generate-precompiled-data -as-write-bind-db -unattended -nocrashreports -NullRHI -NoMessaging -NoASDebugServer -NoSound -NoSplash

Keep the whole AS_JITTED_CODE/ folder written in the package root, and the three files Binds.Cache, Binds.Cache.Headers and PrecompiledScript.Cache.

4. Copy AS_JITTED_CODE/ unchanged into the game's C++ module, for example Source/MyGame/AS_JITTED_CODE/. Do not change the file extensions, and do not include the generated cpp files by hand.
5. In that module's Build.cs, add AngelscriptCode and the native module dependencies the scripts use. This example is for a project that uses both GAS and Enhanced Input:

   PrivateDependencyModuleNames.AddRange(new[] { "AngelscriptCode", "EnhancedInput", "GameplayAbilities", "GameplayTasks", "AngelscriptGAS", "AngelscriptEnhancedInput" });

6. Regenerate the project files after changing Build.cs.
7. Put the three cache files saved in step 3 back into your project's Script/ folder; this must happen before packaging. Then build, package and check again as in steps 1, 2 and 3 of the common steps; when checking, confirm that the package has the three cache files and no project .as files, and that representative gameplay works at runtime.

• The cache and the exe must match: rebuilding only to add this generated C++ does not require generating the cache again; after you change scripts, the engine, plugins or other C++, start again from step 2.
• Put the cache back before packaging: putting it back after packaging does not update the Pak that was already generated.

The packaging workflow can be further streamlined; this is planned alongside future features.