Z's Blog

UE uses C++ as a compiled language, which means it becomes binary after compilation, and players can only update the game by reinstalling it. However, in game development, there’s often an urgent need for requirement adjustments and bug fixes, and frequently prompting players to update the app is unacceptable. Generally, game projects use Lua as the scripting language to transform the immutable C++ code at runtime into updatable Lua code.

Although UE does not officially support Lua, Tencent has open-sourced UnLua, which is being used in my current project. Over the past few days, I’ve organized some materials on UnLua (mainly the official documentation, issues, and presentation PPT) and combined it with my own experience from testing UnLua while writing a small demo, resulting in this programming guide for UE combined with UnLua. This article summarizes some basic methods and pitfalls for using UnLua to write business logic and will be updated continuously.

Additionally, Lua files can be packaged into Pak using my previously open-sourced tool: hxhb/HotPatcher. I’ve also modified a version based on UnLua, adding some extra optimizations. The source code integrates the Luasocket/Luapanda/lpeg/Sproto/Luacrypt libraries, and you can use LuaPanda for debugging. The GitHub address is: hxhb/debugable-unlua.

Due to the impact of COVID-19, I’ve been confined at home throughout the Spring Festival, and I haven’t returned to work yet. I can only read books and organize my notes, hoping the pandemic ends soon and that my friends stay healthy.
The main content of this article is to analyze the differences in syntax between the C++ used in UE development and standard C++. UEC++ is essentially a superset of C++, supporting and utilizing all features of C++, but it has built its own syntax on top of the standard features. Many compilation issues during development can only be quickly and accurately identified at different stages by understanding the boundaries between the two. For those who learned C++ before using UE, this isn’t a problem, but for students who first encounter UE and then gradually learn C++, this can be quite a significant issue.

Standard C++ is based on the language standard ISO/IEC 14882 (C++98/03/11/14/17, etc.), while UEC++ is Epic’s extended usage built on standard C++. This article will not cover topics like GC or reflection or various libraries in UE, focusing instead on the core syntax level.

By default, after packaging a game with UE and installing the Apk on a phone, launching the game will create the game’s data directory under /storage/emulated/0/UE4Game/ (which is at the root of the internal storage). According to Google’s rules, it is best for each app’s data files to be placed in their own private directory. Therefore, I want to put all the game’s data packaged by UE into the directory /storage/emulated/0/Android/data/PACKAGE_NAME (regardless of whether it’s log, ini, or crash information).
This seemingly simple requirement has several different approaches involving UE4’s path management, JNI, Android Manifest, and analysis of UBT code.

Important Notice: The author does not have any platforms or channels for recording paid courses and does not endorse any third-party commercial activities. Please keep your eyes open and beware of scams.
The open-source agreement for this software: Allows the free use of features in commercial projects, but does not permit any third party to charge for this plugin in any form, including but not limited to recording paid courses, or redistributing the plugin and code.

HotPatcher is a tool for managing hot update versions and resource packaging, used to track changes in the original resources of project versions to generate patches. It supports one-click cooking and packaging multi-platform patches, with editors available for Windows and MacOS. Writing a process to download patches from a server forms a complete game hot update solution. HotPatcher has been used in many UE projects and will continue to update to support new engine versions; feel free to submit issues.

The patch mechanism of HotPatcher is different from that in UnrealFrontEnd: There are some issues with UE’s patch management processes; based on the original project version, it is difficult to generate identical patches on different computers, and it is impossible to create a patch based on the version of another patch. Additionally, the content included in the patch cannot be previewed intuitively. Furthermore, it is not easy to bundle external files into pak (such as lua files, db files, and other non-assets, which are often not in the Content directory), nor can you manage project and patch versions easily.

This plugin is designed to resolve these issues, using the project’s original resources as the version basis, allowing easy management of the project itself without needing to focus on other files generated by UE. It conveniently supports actions like cook/generate pak/extract resource information from the base package/version diff/patch splitting, etc. It offers a rich array of configuration options and commandlet support, making it easy to achieve an automated hot update packaging process.

Currently supported engine versions are UE4.21-UE5, with support for the IoStore mechanism! Many friends have sent private messages asking about plugin-related issues, so I created a group to discuss UE hot updates and HotPatcher plugin issues (QQ group 958363331). Everyone is welcome to join and share UE-related technologies.

To conveniently collect and manage common issues and solutions related to hot updates and HotPatcher, I have created a new article to document and organize: UE4 Hot Update: Questions & Answers. If you encounter problems, please check this FAQ page first. Regarding the feedback from many users that the configuration parameters in the plugin do not match previous recorded videos, it is because the plugin has undergone many updates and iterations. For detailed changes in each version, please refer to the Update Log.

Recently, a new project has been initiated, summarizing some issues from previous projects and listing design specifications and code standards for UE development projects (the term “code standards” seems too strict; coding habits are quite subjective, and “coding conventions” would be a better term, but strict execution is necessary for promotion within the team). This article will be continuously updated and organized, and feedback and discussions are welcome.

Last week, I uploaded a plugin I had previously written, ExortNavigation, to the Unreal Marketplace. I familiarized myself with the submission process for UE code plugins and would like to document it here.

The latest version supports UE5, see the UE5.0 branch on github: ue4-export-nav-data/tree/UE5.0.

Recast Navigation is an open-source game navigation/pathfinding engine that provides pathfinding calculations for AI in games. Both UE and Unity integrate RecastNavigation to provide navigation and pathfinding calculations for games (of course, in modified versions). The UE modules NavigationSystem and NavMesh contain relevant code implementations. Recently, there was a requirement to export the client’s map information to a server with a non-UE network architecture, for verifying player locations on the server. It occurred to me that the navigation data generated by the client could be exported as a map of the client world, so I tinkered and wrote a UE plugin (open-sourced on Github: ue4-export-nav-data) that implements directly exporting the navigation data generated by UE. If interested, you can directly view the specific code. Based on the exported navigation data, pathfinding calculations based on Recast Navigation can be fully implemented on the server with a non-UE network architecture, seamlessly integrated with UE.

2019.12.04 Update: This plugin has been listed on the Unreal Marketplace, purchase link ExportNavigation. In support of programmer sentiment for open-source, this project’s repository on Github will not be closed, but it is unlikely to be updated. If this plugin is useful to you, feel free to purchase it on the marketplace to support the author.

Oculus Quest is the new generation of all-in-one VR headset released by Oculus, supporting 6DoF, with no need for a PC connection or additional positioning base stations. It also supports Guardian; when the user walks out of the positioning boundary while wearing the headset, real-world visuals will immediately display in the headset to prevent accidental mishaps.

The Oculus Quest features two Pentile OLED screens, with a single-eye resolution of 1440x1600 and a refresh rate of 72Hz, powered by a Qualcomm Snapdragon 835 processor based on the arm architecture, which is the same as the flagship processors from two years ago (such as Xiaomi 6, Samsung S8).

Quest employs the Oculus Insight (inside-out tracking) positioning solution, using four cameras located at the four corners of the headset panel for positional tracking.
The introduction of Oculus Insight during the release event: Oculus Insight VR Positional Tracking System (Sep 2018)

And a video of a user’s test of Quest’s tracking range abroad: Quest Distance Test.

The 64G storage version of Oculus Quest is priced at $399, while the 128G version costs $499, with tax-excluded prices roughly around 3500; compared to HTC’s similar new product (HTC Vive Focus), it is significantly cheaper, and it offers even greater advantages over PC-Based VR since it does not require a high-performance host. I believe that 6DoF all-in-one VR devices must be the trend of the future!

Before the National Day holiday at OC6, Oculus announced two technologies: Oculus Link and finger tracking, both are impressive and promising.

The entire Quest device is about the same size as a 10.5 inch iPad, making it easy to carry in a small bag:

There’s no need to elaborate on the specifications of the Quest device; the main content of this article will focus on the environment setup, development documentation, debugging tools, and additional considerations when using UE to develop Quest projects, which will be updated continuously.

Module is the basic element that constitutes Unreal. Each Module encapsulates and implements a set of functions, which can be used by other Modules. The entire Unreal Engine is driven by the combination of various Modules, and even the game project that we create is a separate Module.

So how does UE create and build these Modules? This is the main purpose of writing this article, to study Unreal’s build system and the various properties they support (Target and Module).

It is recommended to read my previous article before looking at this one: Build flow of the Unreal Engine4 project, which mainly outlines the build process of UE; this article is merely one part of the UE build system.

工欲善其事，必先利其器！Mastering the right tools can elevate development efficiency to a new level.
This article is a compilation of notes I usually keep in notes about the UE toolchain and some configuration and usage tips for tools using UE. Future content in this area will also be included in this article.
Below are some standalone articles I previously wrote about the UE toolchain or relevant extensions:

• Analyzing the Content Distribution Restrictions of EULA in UBT
• Create A Standalone Application in UE4
• Build flow of the Unreal Engine4 project
• Scraping UE4 API and Generating Indexed Dash Documentation