Arch Linux User Repository

I currently recommend building 5.6.1 over any version of 5.7 as this branch holds a notoriously broken Vulkan RHI implementation, leading to unexpected VK_ERROR_DEVICE_LOST crashes due to a race condition. Just modify pkgver on your end with the aformentioned version and you should be good to go.

A discussion here goes into detail about the issue, but no proper fix is currently planned by Epic.

A merge request has also been proposed here, but the fix itself was in the end apparently not very effective.

The Vulkan crashes were recently fixed in 5.8, check here.

You can still try on your own if you still insist on using 5.7.x, especially if you're motivated to fix this issue on your side. If so, don't hesitate to send a comment with your patch, I could add you as a contributor to this package if you are interested.

Reducing crashes can be done by doing the following two steps:

• Add these lines in DefaultEngine.ini (either in your project or the editor's installation dir, /opt/unreal-engine/Engine/Config/DefaultEngine.ini by default)

[/Script/Engine.RendererSettings]
r.Vulkan.WaitForIdleOnSubmit=1
r.Vulkan.EnablePipelineLRUCache=1

• Add these two lines as well in the editor's ConsoleVariables.ini file (/opt/unreal-engine/Engine/Config/ConsoleVariables.ini by default):

Slate.EnableToolTips=0
Slate.bAllowNotifications=0

Do note that using Wayland for Unreal Engine is currently not recommended as half of the UI interactions are broken. This is due to a recent upgrade to SDL3 which defaults the use of Wayland protocols over X11 when launching on a Wayland-based session.

You can work around this (or at least improve your experience) while still being on Wayland by opening a separate Xorg windowed server:

export DISPLAY=:1

Xwayland ${DISPLAY} -decorate -geometry 1920x1080 &
kwin_x11 &
unreal-engine 

You can, of course, replace kwin_x11 with your desktop environment window manager (GNOME is mutter for example).

@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).

Interesting, I didn't know that. I wasn't really familiar with hardlinks, only symlinks.

I'll use that, then; I'll update it in a moment

cp -l creates hardlinks so no data duplication occurs. rming the file's duplicate inode does not remove the file, only that inode.

I was already aware that using cp was a "better" alternative here for packaging than mv in this circumstance, but I can't permit it to be what's used for everyone by default because the engine is massive as-is and doing this would quickly cause people with "just enough" storage space to compile the engine to suddenly not have enough just because the packaging function doubles the engine size before makepkg is done. Unfortunately, there needs to be a better solution.

Also, thanks for pointing out the issue with the launching mechanism; that's what I get for being half-asleep when I wrote that... Lol

Depending on how you feel about replacing the mvs with cp and rm since mv does not merge, if you replace the entire for loop from L207 to L218 with...

# Copy LocalBuilds to pkg...
cp -flr "${srcdir}"/"${pkgname}"/LocalBuilds/Engine/Linux/* "${pkgdir}"/"${_install_dir}"/
if [ -f "${srcdir}"/"${pkgname}"/LocalBuilds/Engine/Linux/Engine/Binaries/Linux/UnrealEditor ]; then
  # Can never be too careful with recursive rm...
  rm -r "${srcdir}"/"${pkgname}"/LocalBuilds
fi

# Copy the rest of it to pkg... Should we be overwriting LocalBuilds?
cp -flr "${srcdir}"/"${pkgname}"/* "${pkgdir}"/"${_install_dir}"/
if [ -f "${srcdir}"/"${pkgname}"/Engine/Binaries/Linux/UnrealEditor ]; then
  rm -r "${srcdir}"/"${pkgname}"/*
fi

...it produces a working install. Someone else will need to test it as my system is mine, yours is yours.

I have also tweaked L254 & L255 because they were seding the .desktop file instead of the unreal-engine-5.sh script. The user's .desktop should now work as expected instead of opening itself in an editor. Additionally on L255 the substitution needs to be more specific as there is a second UnrealEditor binary in .../Engine/Saved/... which would break the script's search of the base install directory.

# Replaced .desktop file with launch script
sed -i "s/ChecksumPlaceholder/${DesktopFileChecksum}/" "${pkgdir}/usr/bin/unreal-engine-5.sh"
# Searching install_dir finds multiple binaries (in Saved) so limit the scope
sed -i "s|InstalledLocationPlaceholder|/${_install_dir}/Engine/Binaries|" "${pkgdir}/usr/bin/unreal-engine-5.sh"

Any updates about a fix?, I am using only git and makepkg -si.

Still need to prune ${dir}'s excessive expansion, but not from ${dir} itself:

for dir in "${srcdir}"/"${pkgname}"/*; do
  if [ -d "${dir}" ]; then
    # Prune leading path.
    dest=$(basename $dir)
    if [ "${dest}" == "LocalBuilds" ]; then
      if [ -d "${dir}"/Engine/Linux/ ]; then
        mv "${dir}"/Engine/Linux/* "${pkgdir}/${_install_dir}/"
      fi
    else
      mkdir -p "${pkgdir}/${_install_dir}/${dest}"
      mv "${dir}"/* "${pkgdir}/${_install_dir}/${dest}/"
    fi
  fi
done

Could also rename dir to source to remove any ambiguity.

I'm running it at the moment but it takes a few hours...

@shawarden You're right about me missing a bash blob there; I often personally make the mistake of assuming bash understands what I mean when I write lines like that and would explain why it's not doing what I expected

Going by that, I'm guessing ${dir} is interpreted as an entire path rather than a single folder name, which would explain why it appends the path to ${srcdir} and causes this weird home/user directory nonsense

That said, do you think this would be more in line with what's intended?

(I would test this myself but I need a new storage drive and I won't be able to install the drive to do this until later this week)

  for dir in "${srcdir}"/"${pkgname}"/*; do
    if [ -d "${dir}" ]; then
      if [ "${dir}" == "LocalBuilds" ]; then
        if [ -d "${srcdir}/${pkgname}"/LocalBuilds/Engine/Linux/ ]; then
          mv "${srcdir}/${pkgname}"/LocalBuilds/Engine/Linux/* "${pkgdir}/${_install_dir}/"
        fi
      else
        mkdir -p "${pkgdir}/${_install_dir}/${dir}"
        mv "${dir}"/* "${pkgdir}/${_install_dir}/${dir}"
      fi
    fi
  done

By git repo I was referring to Epic's https://github.com/EpicGames/UnrealEngine.git, in case there was any confusion.

Using AUR's repo and makepkg as juancarlospaco did:

❯ mkdir -p ~/Unreal/INSTALL
❯ cd ~/Unreal/INSTALL
❯ git clone https://aur.archlinux.org/unreal-engine.git
...
❯ cd unreal-engine
❯ makepkg
...
❯ tar -tf unreal-engine-5.1.0-23-x86_64.pkg.tar.zst | head -20
.BUILDINFO
.MTREE
.PKGINFO
etc/
etc/pacman.d/
etc/pacman.d/hooks/
etc/pacman.d/hooks/unreal-engine-5-pacman-cache.hook
opt/
opt/unreal-engine/
opt/unreal-engine/Engine/
opt/unreal-engine/Engine/Binaries/
opt/unreal-engine/Engine/Binaries/Android/
opt/unreal-engine/home/
opt/unreal-engine/home/USER/
opt/unreal-engine/home/USER/Unreal/
opt/unreal-engine/home/USER/Unreal/INSTALL/
opt/unreal-engine/home/USER/Unreal/INSTALL/unreal-engine/
opt/unreal-engine/home/USER/Unreal/INSTALL/unreal-engine/src/
opt/unreal-engine/home/USER/Unreal/INSTALL/unreal-engine/src/unreal-engine/
opt/unreal-engine/home/USER/Unreal/INSTALL/unreal-engine/src/unreal-engine/Default.uprojectdirs
❯ makepkg -si
...
❯ ls /opt/unreal-engine
Engine  home
❯ find /opt/unreal-engine \( -wholename "*Binaries*" -a -name UnrealEditor \)
/opt/unreal-engine/home/USER/Unreal/INSTALL/unreal-engine/src/unreal-engine/Engine/Binaries/Linux/UnrealEditor
/opt/unreal-engine/home/USER/Unreal/INSTALL/unreal-engine/src/unreal-engine/Engine/Saved/Engine/Binaries/Linux/UnrealEditor
/opt/unreal-engine/home/USER/Unreal/INSTALL/unreal-engine/src/unreal-engine/LocalBuilds/Engine/Linux/Engine/Binaries/Linux/UnrealEditor

Either L207's for loop has a typo or the package source ${dir} shouldn't be part of the final install path in L213's else statement since it still expands to the full path.

❯ for dir in /etc/pacman.d/; do echo $dir; done
/etc/pacman.d/
❯ for dir in /etc/pacman.d/*; do echo $dir; done
/etc/pacman.d/chaotic-mirrorlist
/etc/pacman.d/gnupg
/etc/pacman.d/hooks
/etc/pacman.d/hooks.bin
/etc/pacman.d/mirrorlist
/etc/pacman.d/mirrorlist.pacnew

Unless there's whitespace (or IFS tokens) in it, L207's for dir in /path/to/folder; do only has 1 iteration where dir is /path/to/folder.

Assume L207's for loop is written as intended, since ${dir} can only be ${srcdir}/${pkgname} and never LocalBuilds, the ${srcdir}/${pkgname} path is then being appended to ${_install_dir} which leads to the final install path being:

${pkgdir}/opt/${pkgname}/${srcdir}/${pkgname}

or

/opt/unreal-engine/PATH/TO/WHERE/SOMEONE/RAN/GIT/CLONE/unreal-engine/src/unreal-engine

If you instead want to cycle through the contents of ${srcdir}/${pkgname} you will need to add a /* on the end: for dir in ${srcdir}/${pkgname}/*; do

None of the iterations can have dir being LocalBuilds since it is the full path though so... maybe L209's if [ "${dir}" == "LocalBuilds" ]; then should be if [[ "${dir}" == *"LocalBuilds" ]]; then?

Either way dir is still expanding to /PATH/TO/WHERE/SOMEONE/RAN/GIT/CLONE/unreal-engine/src/unreal-engine which is where the files are, but not where they should be going.

$HOME is just a path name to your home folder

If you enter echo $HOME in your terminal, that's what you get; additionally, I never even call $HOME anywhere in the script at all. Search for it in the script, and you won't find it. That said, I've said this to people before to stop using AUR helpers like yay with this package, for consistency, but people don't listen.

I know that you keep saying it keeps including your home folder path but, at this point, the only advice I can give you is to stop building the package in your home folder and build it somewhere else (though I doubt at this point this nonsensical issue will stop) and to stop using yay to build this.

I'm going to pin what I keep saying about AUR helpers to this page at this point; yes, they're useful, but they can also be detrimental in some obtuse cases like this and I can't possibly diagnose obscene problems like these if no one's on the same page.