Package Details: openxcom-extended 1:7.5.14-1

Git Clone URL: https://aur.archlinux.org/openxcom-extended.git (read-only, click to copy)
Package Base: openxcom-extended
Description: An extended version of the open-source reimplementation of X-COM (OXCE)
Upstream URL: https://openxcom.org/forum/index.php/topic,5251.0.html
Licenses: GPL3
Conflicts: openxcom
Provides: openxcom, openxcom-git
Submitter: WorMzy
Maintainer: WorMzy
Last Packager: WorMzy
Votes: 4
Popularity: 0.004503
First Submitted: 2019-07-01 20:12 (UTC)
Last Updated: 2022-05-04 19:36 (UTC)

Latest Comments

WorMzy commented on 2022-05-04 18:58 (UTC) (edited on 2022-05-04 19:41 (UTC) by WorMzy)

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

Shiroi_Bara commented on 2022-05-04 18:20 (UTC) (edited on 2022-05-04 18:23 (UTC) by Shiroi_Bara)

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.

WorMzy commented on 2020-12-01 14:17 (UTC)

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

Emru commented on 2020-12-01 13:43 (UTC)

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

WorMzy commented on 2020-12-01 13:37 (UTC)

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

Emru commented on 2020-11-30 20:51 (UTC) (edited on 2020-11-30 20:52 (UTC) by Emru)

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.

WorMzy commented on 2020-11-02 19:03 (UTC)

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

locchan commented on 2020-11-02 18:59 (UTC)

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.

WorMzy commented on 2020-06-24 16:39 (UTC)

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.

linuxham commented on 2020-06-21 03:27 (UTC) (edited on 2020-06-25 20:10 (UTC) by linuxham)

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

WorMzy commented on 2020-06-20 11:22 (UTC) (edited on 2020-06-20 11:23 (UTC) by WorMzy)

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.

linuxham commented on 2020-06-20 00:25 (UTC)

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

gonciarz commented on 2019-07-16 20:49 (UTC) (edited on 2019-07-16 20:52 (UTC) by gonciarz)

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

WorMzy commented on 2019-07-15 11:35 (UTC)

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.

gonciarz commented on 2019-07-15 09:02 (UTC)

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?

WorMzy commented on 2019-07-15 08:29 (UTC)

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.

gonciarz commented on 2019-07-15 06:50 (UTC)

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?

WorMzy commented on 2019-07-07 17:15 (UTC)

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

gonciarz commented on 2019-07-07 10:40 (UTC)

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?

gonciarz commented on 2019-07-07 09:51 (UTC)

Great :)

WorMzy commented on 2019-07-02 09:53 (UTC)

Done. :)

gonciarz commented on 2019-07-01 21:34 (UTC)

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.