Package Details: openxcom-extended 6.7.2-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: 2
Popularity: 0.000593
First Submitted: 2019-07-01 20:12
Last Updated: 2020-10-24 12:50

Latest Comments

1 2 Next › Last »

WorMzy commented on 2020-06-24 16:39

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

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

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

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

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

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

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

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

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

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