Arch Linux User Repository

This uses the "stable" release tars. Unlike the git version this can be installed alongside normal OpenTTD for those that play both.

The optional gfx/sfx packages won't install to the correct location. The game will prompt to d/l the gfx on first run and the opensfx can be downloaded in game via the "Check Online Content" button.

If after a system update (especially the icu package) the game fails to launch make sure you've tried to rebuild the package before reporting issues.

@invverse: Ah, I think I see what's happened.

The main repo openttd, which this is based on, requires fluidsynth, but at some point fluidsynth which used to require sdl2 now requires sdl3.

You might want to report the error on the main repository, too :)

Since 0.65.1 this fails to build in a clean chroot and prints the following error: SDL2 or Allegro is required for this platform. Adding sdl12-compat to the dependencies fixes this and builds successfully.

Thanks for fixing @Stichless :)

Launch issues should be fixed now.

Seemed to be related to the recent changes to /etc/makepkg.conf enabling the lto option. Disabling the option fixes the build, but there's probably a better way than disabling it considering it's meant to optimize the build, but I'm not sure, so for now it's working and that's all that matters(?).

Same issue as @Fuzzy. Tried to look through the available debug options, openttd-jgrpp -d 9 does give a bit more insight into what exactly seems to go wrong. I still don't quite get it but might be worth it to list the findings:

On initial start it prompts to download OpenGFX, which hangs somewhere after 50%. Killing the program and restarting, causes a black screen which can't be closed properly. Checking the console output it seems to struggle opening ogfxe_extra.grf in OpenGFX. Tried to switch out the downloaded one, with the one that ships with the steam version to no avail - same problem. It seems to try to jump to negative line definitions and loop infinitely there:

dbg: [grf:2] [opengfx-7.1.tar/opengfx-7.1/ogfxe_extra.grf:25653] SkipIf: Jumping to label 0x10 at line -1350376573, test was true
dbg: [grf:7] [opengfx-7.1.tar/opengfx-7.1/ogfxe_extra.grf:-1350376572] DecodeSpecialSprite: Handling action 0x0D in stage 4
dbg: [grf:7] [opengfx-7.1.tar/opengfx-7.1/ogfxe_extra.grf:-1350376571] DecodeSpecialSprite: Handling action 0x09 in stage 4
dbg: [grf:7] [opengfx-7.1.tar/opengfx-7.1/ogfxe_extra.grf:-1350376571] SkipIf: Test condtype 3, param 0x7F, condval 0x00000001
dbg: [grf:2] [opengfx-7.1.tar/opengfx-7.1/ogfxe_extra.grf:-1350376571] SkipIf: Jumping to label 0x10 at line -476479005, test was true
dbg: [grf:7] [opengfx-7.1.tar/opengfx-7.1/ogfxe_extra.grf:-476479004] DecodeSpecialSprite: Handling action 0x05 in stage 4
... [continues in the negative 4764 area]

Couldn't find an issue on the Github repo so the problems seems to be with the Arch build?

I'm encountering the same issue as @Fuzzy and also had to roll back to 0.57.1 to get it to launch.

Something went wrong with 0.58 - it hangs on start without window refresh (i.e. it shows window frame but there are nothing inside, just a piece of my desktop image). There are no any output in console (should I activate debug somehow?...) I rolled back to 0.57.1 - it works fine (I tried 0.58 and 0.58.1 - neither works)

Whilst I'm not sure why it would suddenly cause issues for anyone, maybe it's a specific quirk of your setup, I've omitted CMAKE_BUILD_TYPE entirely.

Looking through OpenTTD's code there is currently a section that if no CMAKE_BUILD_TYPE it'll set "sensible defaults".

I guess if anyone can't build -O3/Release they can remove it manually...

It is odd that general builds of OpenTTD (upstream Arch, Fedora, and even the build workflows for openttd-jgrpp use Release though). There's probably a good reason (as opposed to -O3 goes brrr), but I don't see it stated anywhere.

It seems setting CMAKE_BUILD_TYPE=None as opposed to Release in the PKGBUILD fixed the issue for me. Which is very strange, but oh well; that is what the CMake guide advises to do anyway. I would suggest applying it anyway, just for good practice.

@gustavo6046 Still builds fine for me. You might want to try providing more information.