Arch Linux User Repository

@juancarlospaco this is easily done on your own system, not in a PKGBUILD, given that building packages runs as root:

sudo groupadd unrealengine-users
sudo usermod -aG unrealengine-users (your-username)
sudo chown -R root:unrealengine-users /opt/unreal-engine
sudo chmod -R 775 /opt/unreal-engine

Permission issues like this are already mentioned on the UE Arch wiki page: https://wiki.archlinux.org/title/Unreal_Engine_4#Installing_from_the_AUR

This is a user system problem; I already did what I could without needing users to do the above by giving the 777 permissions. If it still gives you trouble, you'll have to use the example to solve it or change the install location to somewhere you have user permissions by default (as I cannot do this for you).

Will update to 5.0 when it is released.

4.24.1 report: lag every 3 seconds on kde/nvidia1070 still there.

@Slasher006: GOOD NEWS! any patch?

The freezing problem with 4.24 might have got a solution:

https://forums.unrealengine.com/development-discussion/engine-source-github/1617597-ue4editor-constantly-crashes-and-freezes-using-linux/page2

"

Cross posting from discussion on #linux on discord.

The version of SDL that is precompiled and bundeld with linux is definitely not using libudev. If libudev was being used then SDL would not end up polling all /lib/input/event* devices every 3 seconds. I pulled down SDL and built a stand alone example, and I happen to have libudev installed, and I get no hitching on the same hardware. Wondering if there is some reason libudev is not being used in the SDL built for linux by Epic?

I made sure that I did not init SDL_JOYSTICK | SDL_GAMEPAD | SDL_SENSORS in LinuxPlatformApplicationMisc.cpp and commented out the checks in LinuxApplication.cpp and no more hitching, at all.

I know for a fact libudev is not being used because in my profiling I can see the function MaybeAddDevice being called, and when SDL_USE_LIBUDEV is true that code will never execute.

Simply rebuilding SDL using build.sh in the ThirdParty/SDL2 directory fixes all my htiches. When grepping the output of that script libudev is marked as found, and the better code path is now taken. Looking at the scripts in that folder, it is not apparent that libudev-dev is being installed by the package manager in the install_ubuntu.sh, and install-centos.sh scripts.

TLDR; Either use libudev with SDL or do not init SDL_Joystick and you can have a hitch free UE4 too.

" EDIT: I get errors with zlib after rebuilding SDL. :-O (i feel useless now)

@zerophase, omg, sorry, just forgot to change it back, fixed!

@shatur you wrote the package to install to /mnt.

Updated to 4.24.1. Here is my changes:

• I moved downloading of Unreal Engine to prepare section. This allows me to explicitly check access to the repository (and notify user about it!) and specify --depth=1 to reduce the amount of downloaded data from repo to 200 MiB.
• I removed cmake from makedepends because it is not used for building.
• But I added cmake, qmake and used IDE's in editor settings as makedepends.
• I removed all obsolete patches (that not needed) and updated all information, now PKGBUILD looks clean.
• PKGBUILD now works with the latest (4.24.1) version.
• I renamed .desktop file to com.unrealengine.UE4Editor to follow desktop entry specifications and renamed icon to lower case for desktop icon themes compatibility.
• I splitted make -j1 into the build of each component from the "all" target in order to be able to build with multiply threads and avoid the error with parallel compilation of several targets. Because each target can be build in parallel separately.

After 4.24 Unreal Engine disallow to use system clang :( Even if I try "-ForceUseSystemCompiler" as noticed in 4.24 changes it says that "No BuildPlatform found for Linux". Perhaps this can be fixed, but so far there is no solution, so I suggest using the proposed clang for now.

I decided to leave other systems components as is. This greatly reduces the amount of data, but I can’t be sure that everything will work correctly. Therefore, I did not change it.

@shatur, okay! I will push the 4.24.1 after some checks without system clang temporary. @acerix also checked my PKGBUILD and he is okay with it.

@shatur

It needed only if you generate CMake project. What if I add it as optional dependencies with qmake that used in the same way?

Yeah, just drop cmake in optdepends with qmake.

I'll be able to look into the system clang after the holidays.

Cmake should probably be in optdepends, as it is needed for different ides.

It needed only if you generate CMake project. What if I add it as optional dependencies with qmake that used in the same way?

There should be a patch applied that uses the system clang, and stops downloading of the toolchain.

After 4.24 Unreal Engine do not allow to use system Clang :( If I apply a patch that disables downloading Clang toolchain, Unreal Engine will not use the system Clang and fail to build. Maybe there is the way how to path it, but for now I do not know how to fix it.

Most of those patches probably need to be updated for changes in the engine so they still apply successfully. They're mostly for supporting the system clang, and recompiling the Unreal Version selector so you don't have to manually intervene during install time.

I checked all the old patches, they are applied successfully, but they are no longer needed. Except the patch to use the system Clang, which also patches successfully, but then the builder does not see the system Clang. I don’t know how to fix it yet.

Have you run the engine through various paths to check for any crashes from removing Windows specific files? There are a few checks built into the engine.

Of course! At the moment, I managed to reduce the size of the downloaded files from 11 to 5.5 GiB (via .gitdepsignore, excluding from the download files Windows, Mac, IOS and other OSs, the compilation of which is not supported under Linux.

@shatur

• Cmake should probably be in optdepends, as it is needed for different ides.
• There should be a patch applied that uses the system clang, and stops downloading of the toolchain.
• Most of those patches probably need to be updated for changes in the engine so they still apply successfully. They're mostly for supporting the system clang, and recompiling the Unreal Version selector so you don't have to manually intervene during install time.
• Have you run the engine through various paths to check for any crashes from removing Windows specific files? There are a few checks built into the engine.

@vesterlay, please, read the wiki.