Arch Linux User Repository

Can confirm. No need to delete options.cfg though, just disable opengl: sed -i 's/useOpenGL:.*/useOpenGL: false/' ~/.config/openxcom/options.cfg

I'd hazard a guess that this is due to the replacement of sdl with sdl12-compat. Need to check.

EDIT: Yep, downgrading/replacing sdl12-compat-1.2.52-2 with sdl-1:1.2.15+r406+gf1caf909-1 fixes the crashes. I'll open a bug report at https://github.com/libsdl-org/sdl12-compat/issues

The recent arch update break in game Display options (under Video section) now. Most of them produce crash. Info from log file:

[04-05-2022_21-11-01]   [FATAL] A fatal error has occurred: Use SDL_GL_SwapBuffers() on OpenGL surfaces
[04-05-2022_21-11-01]   [FATAL] openxcom(OpenXcom::CrossPlatform::stackTrace(void*)+0x3b) [0x563c0f35595b]
[04-05-2022_21-11-01]   [FATAL] openxcom(OpenXcom::CrossPlatform::crashDump(void*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)+0x4c6) [0x563c0f356f06]
[04-05-2022_21-11-01]   [FATAL] openxcom(exceptionLogger()+0x4d) [0x563c0f14789d]
[04-05-2022_21-11-01]   [FATAL] /usr/lib/libstdc++.so.6(+0xa5c4c) [0x7f6bc2db1c4c]
[04-05-2022_21-11-01]   [FATAL] /usr/lib/libstdc++.so.6(+0xa5cb9) [0x7f6bc2db1cb9]
[04-05-2022_21-11-01]   [FATAL] /usr/lib/libstdc++.so.6(+0xa5f5e) [0x7f6bc2db1f5e]
[04-05-2022_21-11-01]   [FATAL] openxcom(+0x273d10) [0x563c0f0d4d10]
[04-05-2022_21-11-01]   [FATAL] openxcom(OpenXcom::Game::run()+0x65a) [0x563c0f37a70a]
[04-05-2022_21-11-01]   [FATAL] openxcom(main+0x15e) [0x563c0f12551e]
[04-05-2022_21-11-01]   [FATAL] /usr/lib/libc.so.6(+0x2d310) [0x7f6bc2a2c310]
[04-05-2022_21-11-01]   [FATAL] /usr/lib/libc.so.6(__libc_start_main+0x81) [0x7f6bc2a2c3c1]
[04-05-2022_21-11-01]   [FATAL] openxcom(_start+0x25) [0x563c0f12aa05]
[04-05-2022_21-11-05]   [FATAL] OpenXcom has crashed: Use SDL_GL_SwapBuffers() on OpenGL surfaces

I don't know is this game related or just some changes in arch. If anyone encounter it and wonder how to fix - you need to delete options.cfg file in /home/user_name/.local/share/openxcom directory. This will reset game setting to default include turn off all mods and etc. But I hope we will get fix or update soon.

Sorry, I'll only include patches to resolve build failures, and even then the patches should ideally be backported from upstream (unless it's an Arch-specific build failure).

I was thinking about patch in AUR only, in PKGBUILD.

This isn't the correct place to send patches to the upstream code.

Create a merge request or open an issue to discuss the change at https://github.com/MeridianOXC/OpenXcom.git

Hey, I made a small patch for OXCE code, that will allow to load mods installed in /usr/share/openxcom/mods.

diff --unified --recursive --text package.orig/openxcom-extended/src/Engine/Options.cpp package.new/openxcom-extended/src/Engine/Options.cpp
--- package.orig/openxcom-extended/src/Engine/Options.cpp   2020-11-30 20:54:57.010530630 +0100
+++ package.new/openxcom-extended/src/Engine/Options.cpp    2020-11-30 20:56:20.580606153 +0100
@@ -657,6 +657,8 @@
        Log(LOG_INFO) << "Scanning standard mods in '" << getDataFolder() << "'...";
        FileMap::scanModDir(getDataFolder(), "standard", true);
    }
+   Log(LOG_INFO) << "Scanning system mods in '" << getDataFolder() << "'...";
+   FileMap::scanModDir(getDataFolder(), "mods", false);
    Log(LOG_INFO) << "Scanning user mods in '" << getUserFolder() << "'...";
    FileMap::scanModDir(getUserFolder(), "mods", false);
 #ifdef __MOBILE__
Only in package.new/openxcom-extended/src/Engine: Options.cpp.orig

What do you think? With it I can take over and update existing mods in AUR.

https://wiki.archlinux.org/index.php/Arch_User_Repository#Prerequisites

The package lacks "pkgconf" as a dependency, cmake cannot start compiling. This might also be the case with other xcom packages, but I didn't check.

If this is due to a packaging bug, I'm happy to fix it, but as previously mentioned -- nothing has changed in terms of packaging.

When I try the XFiles mod in OpenXcom Exteded 6.5.5, it produces these errors

[20-06-2020_22-53-37] [INFO] Loading rulesets... [20-06-2020_22-53-44] [ERROR] Error processing 'STR_AQUA_PLASTIC_SUIT_H_UC_UNDERWATER' in armors: Item STR_AQUA_PLASTIC_SUIT_UC_UNDERWATER not found Error processing 'STR_AQUA_PLASTIC_SUIT_UC_UNDERWATER' in armors: Item STR_AQUA_PLASTIC_SUIT_UC_UNDERWATER not found Error processing 'STR_ASTRAL_ARMOR_UC' in armors: Item STR_ASTRAL_ARMOR_UC not found Error processing 'STR_ASTRAL_WEREWOLF_ARMOR' in armors: Item STR_ASTRAL_WEREWOLF_CORPSE not found

The only packaging difference between 6.5.3 and 6.5.4 is the latter has eight extra files:

$ bsdtar tf ~/builds/openxcom-extended/openxcom-extended-6.5.3-1-x86_64.pkg.tar.zst > oe-6.5.3
$ bsdtar tf ~/builds/openxcom-extended/openxcom-extended-6.5.4-1-x86_64.pkg.tar.zst > oe-6.5.4
$ diff oe-6.5.{3,4}
317a318,320
> usr/share/openxcom/standard/XcomUtil_Fighter_Transports_TFTD/
> usr/share/openxcom/standard/XcomUtil_Fighter_Transports_TFTD/XcomUtil_Fighter_Transports_TFTD.rul
> usr/share/openxcom/standard/XcomUtil_Fighter_Transports_TFTD/metadata.yml
374a378,380
> usr/share/openxcom/standard/XcomUtil_Triton_Weapon_Slot/
> usr/share/openxcom/standard/XcomUtil_Triton_Weapon_Slot/XcomUtil_Triton_Weapon_Slot.rul
> usr/share/openxcom/standard/XcomUtil_Triton_Weapon_Slot/metadata.yml
544a551,556
> usr/share/openxcom/standard/xcom2/MAPS/
> usr/share/openxcom/standard/xcom2/MAPS/BARRACUD.MAP
> usr/share/openxcom/standard/xcom2/MAPS/MANTA.MAP
> usr/share/openxcom/standard/xcom2/ROUTES/
> usr/share/openxcom/standard/xcom2/ROUTES/BARRACUD.RMP
> usr/share/openxcom/standard/xcom2/ROUTES/MANTA.RMP

If there is any mod bustage, it's caused by code changes and should probably be reported upstream.

I have installed OpenXcom Extended, and gotten it to launch, and tried the X-Files Mod, which failed to run. It complained of missing armor rules. X-Files runs in 6.5.3, but not in your 6.5.4.1.

Ed

Hi WorMzy, I understand that the OpenXcom is dead now because guys do not release on github. But on the other hand I don't like disorder and manual steps. I just want to have all packages (openxcom/git, openxcom-extended/git) Still from my point of view the cleanest solution would be to apply a patch to openxcom that would change the 'data' path to 'UFO'. Actually I dig a bit and prepared one. Please accept it.

I'm not familiar how collaboration looks like on aur git, but I usually create a pull request. I've tested the game and it loads properly. Please take a look here: https://bitbucket.org/gonciarz/openxcom-archlinux/pull-requests/1/path-fix/diff

I believe that after merging that change to aur repo, we may change path in openxcom-data-steam. What do you think?

Regards

That's the problem -- openxcom is up to date, everything else pulls a developmental version. ;)

I'm opposed to switching the openxcom-data-steam package to build for -git/-extended packages by default (it's not called openxcom-git-data-steam after all, and it's easy enough to switch), but I don't mind appending to the note in the PKGBUILD to make it clear that a git flagged build is necessary for OXCE too. I'm not sure it will make any difference though -- the package has only attracted one vote and a handful of comments in the 4+ years it's been available, I doubt it's heavily used.

Thanks, I may follow your suggestions but if openxcom is not up to date then maybe you may switch defaults in openxcom-data-steam (_openxcom_ver=git) to support more popular version. What do you think?

If it depends on OXCE, then it should depend on that package (I'll add a provides=(openxcom-extended) to the -git package, so either of the extended packages will fulfil the requirements).

The openxcom package is packaging v1.0 of openxcom from 5 years ago, this version predates TFTD support which is why it has a different data directory. Until upstream tag a new release, I suggest you package for and depend on openxcom-git (which is the equivalent of the nightly releases recommended by upstream.

I just want to cooperate.

SupSuper (OpenXcom) advised that we may put the data to: /usr/share/openxcom/standard

Please take a look at my first mod: https://aur.archlinux.org/packages/openxcom-mod-twots and vote it if you like it :)

My only concern is that this package depends on oxce version of xcom (standalone or git).

I've noticed that there are mods that I need to apply to data/UFO data/TFTD directory, but git and non-git version of OpenXcom keeps either in /usr/share/openxcom/UFO or /usr/share/openxcom/data directory. I believe that we in order to avoid conflicts we should unify those directories and prepare a proper patch for e.g. non-git version. Then openxcom-data-steam package will also work for both versions. What do you think?

You don't need to seek approval from me -- if upstream adds "system" mod directory support, then you can add whatever mods you like to the AUR. Just don't make packages that install files to $HOME or you'll incur the wrath of the TUs. ;)

WorMzy I was wondering. Maybe we may resurrect UFO/XCOM a bit. mod.io contains some interesting mods. Some of them requires OXCE but we already have a support for it in Arch thanks to you ;). Maybe their corresponding Arch packages could be created. Below I listed the most popular once I have in mind:

463: https://openxcom.mod.io/the-x-com-files 223: https://openxcom.mod.io/40k 49: https://openxcom.mod.io/area-51 115: https://openxcom.mod.io/x-piratez 46: https://openxcom.mod.io/the-world-of-terrifying-silence 163: https://openxcom.mod.io/final-mod-pack

Normally you put mod files to .local/share/openxcom/mods directory. I thought that if we put a mod to /usr/share/openxcom/mods then it will be recognised by the game, however it's not. The game searches for mods in user/mods directory only. From OpenXcom documentation:

user mods, savegames, screenshots config game configuration data UFO and TFTD data files, standard mods, common resources

Thus I opened a feature request to add support for it. Then that should be propagated to OXCE. https://openxcom.org/bugs/openxcom/issues/1455

What do you think about it?

Great :)

Done. :)

Hi, I would suggest to put "(OXCE)" acronym to a package description so people can easily find it and identify that this is the right package.