xash3d: init at unstable-2023-06-13 #238392

TheBrainScrambler · 2023-06-18T10:13:11Z

Description of changes

Xash3D is a GoldSrc reimplementation capable of running Half-Life.

Closes #231696.
Also closes #166081 which was targetting the old Xash3D engine. This pull requests targets the FWGS fork. I just named the package xash3d and not xash3d-fwgs since the old Xash3D is deprecated and never made it into nixpkgs anyway.

My only big issue with this is that it needs to modify the assets of Half-Life to properly run on 64bit. I wrote a wrapper for this that will make the required symlinks from the libraries in hlsdk to the assets. I don't know if there is a better way, but that's what the AUR does (https://aur.archlinux.org/packages/xash3d-git and the old https://aur.archlinux.org/packages/xash3d-fwgs-git).

Things done

TheBrainScrambler · 2023-07-21T15:24:39Z

Since this pull request is sitting here for a month already, I took the opportunity to update it. Initially I just wanted to update the version and do some small fixes as I saw there were some problems, but I did a lot more in the end.

I discovered on my own how to remove this stupid hack where I symlink libraries in the half-life data files. That was one big thing bugging me.

I found that there was yet someone else who tried to package xash3d: https://github.com/vs49688/nix-repo/tree/master/pkgs/xash3d-fwgs. With that i discovered that actually xash3d on 64bit can not only run half-life, but a lot of other games. The issue though is that each game needs its own version of the hlsdk and its own wrapper. I did this for 3 games: half-life, blue shit and opposing forces. If anyone wants more games I will do it later on request, but for now I want this to be merged.

I just need help on one point. Right now my packages work, but I've put a lot of things in top-level/all-packages.nix and I feel it doesn't belong there. Moreover for each package I must specify the hlsdk and the wrapper, which ends up in duplications. I don't know how to deduplicate this though. So if anyone has a way, please tell me.

nixos-discourse · 2023-07-22T11:35:47Z

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review/3032/2445

pkgs/games/xash3d/default.nix

pkgs/top-level/all-packages.nix

pkgs/games/xash3d/wrapper.nix

SuperSandro2000 · 2023-07-23T16:09:42Z

pkgs/games/xash3d/wrapper.nix

+    if [ ! -d "$XASH3D_BASEDIR" ]; then
+      echo "$XASH3D_BASEDIR not found"
+      exit 1
+    fi


The potential error should be catched in nix

Um no ? If you try to catch the error in Nix you're catching the error at build time. This is impossible because this here is a runtime error. If the directory $XASH3D_BASEDIR doesn't exist at runtime there's an error, but this is fine at build time. Especially that $XASH3D_BASEDIR can be changed by the user and so it can be anything at runtime.

SuperSandro2000 · 2023-07-23T16:10:29Z

pkgs/games/xash3d/wrapper.nix

+  '';
+in symlinkJoin {
+  name = "xash3d-${name}";
+  paths = [ wrapper ];


We can just use runCommand or similar if we only symlink one thing.

From what I understood runCommand is just for running a command once at build time. But this here is, as the file name suggests, a wrapper script that is run each time the game is run. I think I could also just use writeShellScriptBin directly, but the problem is that it doesn't have any meta attribute. And since the wrapper is what people are going to install in the end, it's important to have a meta with description and all that. Especially that in the longDescription I'm explaining how to run the game, important stuff that you can't just leave out. The only solution I found right now is symlinkJoin, but if you have a better one I'm interested.

TheBrainScrambler · 2023-08-09T18:45:12Z

I took again the opportunity to make some changes:

Finished incorporating all the suggested changes of your review. Github hit some of them so I missed those ... Didn't incorporate them all though, see comments
Added some documentation
Removed exposing the hlsdk of each game. No one cares anyway, it's just a dependency needed by the games.
Added desktop icons for the games. I didn't test them though so can't say if it really works, but I do see the .desktop file in the game folders.

TheBrainScrambler · 2023-08-13T13:52:00Z

I've just learned about the existence of meta.mainProgram so I added that one.

TheBrainScrambler · 2023-08-31T10:11:13Z

Since this PR is staling I'm pinging those people who were trying too to package xash3d, in the hope that you guys don't mind:
@barinov274
@chayleaf
@vs49688

Also @necrophcodr you were interested in FreeHL, so you might be interested in xash3d too ?

TheBrainScrambler · 2023-08-31T10:12:34Z

I know everything runs fine, I've completed all of the 3 games valve, bshift and gearbox, I just need someone who can confirm the desktop items work and some review on the nix files so that this PR gets merged.

vs49688 · 2023-08-31T12:10:03Z

pkgs/games/xash3d/default.nix

+, enableGles1 ? false # gles1 renderer (nanogl)
+, enableGles2 ? false # gles2 renderer (glwes)
+, enableGl4es ? false # gles2 renderer (gl4es)
+, enableGl ? true # opengl renderer


Do we really need all these flags? Have you tested all the cases? I distinctly remember having compile errors when trying to enable only what I needed.

I didn't test them myself, true, I copied those from chayleaf's attempt. But I thought why not keep them if someone needs them one day

pkgs/games/xash3d/wrapper.nix

pkgs/games/xash3d/default.nix

vs49688 · 2023-08-31T12:26:47Z

pkgs/games/xash3d/wrapper.nix

+  description = "${fullname} running using the Xash3D engine, a GoldSrc reimplementation";
+
+  wrapper = writeShellScriptBin "xash3d-${name}" ''
+    export XASH3D_EXTRAS_PAK1=${xash3d-unwrapped}/share/xash3d/valve/extras.pk3


You should set XASH3D_RODIR:

export XASH3D_RODIR="@out@/lib/xash3d"

I suggest substituting this to $out/bin/xash3d at install-time.

But then again, I'm biased ;)

Why setting it ? First of all $XASH3D_RODIR is the directory to the assets, so why should it be @out@/lib/xash3d ? When not specified it defaults to $XASH3D_BASEDIR which is exactly what we want. $XASH3D_BASEDIR is a directory to which Xash3D can write, it's where it puts screenshots for example. That's how the whole structure looks like:

$ tree -L 1 ~/.local/share/xash3d ~/.local/share/xash3d ├── bshift ├── gearbox └── valve

$XASH3D_BASEDIR and $XASH3D_RODIR are both set to ~/.local/share/xash3d.

vs49688 · 2023-08-31T12:29:43Z

@TheBrainScrambler I never attempted to upstream mine for two reasons:

The licensing situation of Xash3d is uncertain.
It depends of custom tarballs of game data I've extracted from Steam and put in a private cache.

That being said, I'm not sure I like the idea of having a per-game xash3d-$game launcher. It makes more sense to have individual derivations of xash3d, each with a different "set" of base games in the Nix store, with user modifications in XASH3D_BASEDIR.

That's what I do in mine, and I create a new derivation with:

  xash3d-fwgs-full = self.xash3d-fwgs.withGames (g: [
    g.valve
    g.bshift
    ...
  ]);

chayleaf

For reference, here's my Xash3D packaging attempt, here's the Vulkan fork, and here's the ray tracing fork

chayleaf · 2023-08-31T22:21:06Z

pkgs/games/xash3d/change-zip-date.patch

+ 				arcfile = src.path_from(self.relative_to)
+
+ 				Logs.debug('%s: %s <- %s as %s', self.__class__.__name__, outfile, infile, arcfile)
+-				zf.write(infile, arcfile)


you can usually change ZipFile initialization to use strict_timestamps=False instead

I don't understand. Plus this patch comes from you here :p

TheBrainScrambler · 2023-09-01T09:51:26Z

@TheBrainScrambler I never attempted to upstream mine for two reasons:
1. The licensing situation of Xash3d is uncertain.

Just set the license to unfree, that's what I did. I also put a comment there pointing to the related issue.

2. It depends of custom tarballs of game data I've extracted from Steam and put in a private cache.
That being said, I'm not sure I like the idea of having a per-game xash3d-$game launcher. It makes more sense to have individual derivations of xash3d, each with a different "set" of base games in the Nix store, with user modifications in XASH3D_BASEDIR.

That's what I do in mine, and I create a new derivation with:
  xash3d-fwgs-full = self.xash3d-fwgs.withGames (g: [
    g.valve
    g.bshift
    ...
  ]);

That's why to package this I avoided 2. Instead, you can build Xash3D without any problems, then you can put your assets in $XDG_DATA_HOME/xash3d and then run it the right game with the right wrapper.

I don't understand why you would want sets of games instead of just allowing to install each game individually. So what you want is for example this:

xash3d-set1 (with just valve)
xash3d-set2 (with valve, bshift, gearbox)
...

Instead of just exposing valve, bshift and gearbox as individual packages, and letting the user choose which ones to install ? What's the point behind that ?

Besides, you need to have one launcher per game. The key is this line in the wrapper:

exec ${xash3d-unwrapped}/bin/xash3d -game ${gamedir} $flags_dll $flags_clientlib "$@"

with the flags:

    if [ ! -f "$XASH3D_BASEDIR/valve/dlls/${dllname}_amd64.so" ]; then
      flags_dll="-dll ${hlsdk}/${gamedir}/dlls/${dllname}_amd64.so"
      flags_clientlib="-clientlib ${hlsdk}/${gamedir}/cl_dlls/client_amd64.so"
    fi

(in retrospect this if is just useless. Will remove it)

See, instead of copying the hlsdks dlls in the user's assets and thus putting garbage in there, instead I specify to xash3d the location of the dlls when I launch it. And since every game has a different hlsdk, you need one launcher per game.
This part is how I avoid your problem 2.

TheBrainScrambler · 2023-09-09T09:16:27Z

So @vs49688 what do you think ?

necrophcodr · 2023-09-09T20:23:14Z

I've tested it and it currently seems to work fine with the OpenGL renderer, however the software renderer crashes with no real stack trace (other than originating from /nix/store/zns2rxbqx6fx9qi8x6kk9dlkdpnyivsj-xash3d-unwrapped-unstable-2023-07-02/lib/xash3d/libref_soft.so which appears to be/be related to the software renderer.
I've not been able to further debug the issue, and I don't see any open issues on the source repository about this, so I'm inclined to believe that this is a bug of the derivation being built, rather than a bug in the source code.
@TheBrainScrambler did you try running this under different settings, such as using the software renderer?
To be clear, the software renderer crashes upon loading any level. It does not crash in the menu itself.

To be honest I didn't test it until now, forgot that one defaults to true ... But I've just did and apart from the fact that it looks ugly it works fine for me. I've tested this with valve and bshift. So this must be an issue on your side I guess ? I've tried for both to load the hazard course, and for valve I loaded the final boss fight too.

I should also document that I didn't test the other renderers, those that default to false. Will do this when I can.

EDIT: added a small comment above those flags that I didn't test. Thus people can still use them if they want, but it's now explicit that I didn't test those.

That's all possible. I did try running it with LD_DEBUG=libs and when it crashed, the following lines were output. If they're entirely related, I do not know, but it would definitely be a good indicator of the issue. If this is caused by this build process or not, I can't say for sure of course.

Additionally, I'd like to point out that if it works for you, then it should surely also work on my end, bar any hardware related issues (which I do not believe this to be).

Anyway, here's the output for posterity:

     42034:     calling init: /nix/store/ngpwaaqf8vr94ql5bmzqz839a1ggkrw6-hlsdk-valve-unstable-2023-07-17/valve/cl_dlls/client_amd64.so
     42034:
     42034:     /nix/store/ngpwaaqf8vr94ql5bmzqz839a1ggkrw6-hlsdk-valve-unstable-2023-07-17/valve/cl_dlls/client_amd64.so: error: symbol lookup error: undefined symbol: InitVGUISupportAPI (fatal)
     42034:     /nix/store/ngpwaaqf8vr94ql5bmzqz839a1ggkrw6-hlsdk-valve-unstable-2023-07-17/valve/cl_dlls/client_amd64.so: error: symbol lookup error: undefined symbol: GetClientAPI (fatal)
     42034:     /nix/store/ngpwaaqf8vr94ql5bmzqz839a1ggkrw6-hlsdk-valve-unstable-2023-07-17/valve/cl_dlls/client_amd64.so: error: symbol lookup error: undefined symbol: F (fatal)
     42034:     /nix/store/ngpwaaqf8vr94ql5bmzqz839a1ggkrw6-hlsdk-valve-unstable-2023-07-17/valve/cl_dlls/client_amd64.so: error: symbol lookup error: undefined symbol: HUD_ChatInputPosition (fatal)
     42034:     /nix/store/ngpwaaqf8vr94ql5bmzqz839a1ggkrw6-hlsdk-valve-unstable-2023-07-17/valve/cl_dlls/client_amd64.so: error: symbol lookup error: undefined symbol: HUD_GetRenderInterface (fatal)
     42034:     /nix/store/ngpwaaqf8vr94ql5bmzqz839a1ggkrw6-hlsdk-valve-unstable-2023-07-17/valve/cl_dlls/client_amd64.so: error: symbol lookup error: undefined symbol: HUD_ClipMoveToEntity (fatal)
     42034:     /nix/store/ngpwaaqf8vr94ql5bmzqz839a1ggkrw6-hlsdk-valve-unstable-2023-07-17/valve/cl_dlls/client_amd64.so: error: symbol lookup error: undefined symbol: IN_ClientTouchEvent (fatal)
     42034:
     42034:     calling fini: /nix/store/ngpwaaqf8vr94ql5bmzqz839a1ggkrw6-hlsdk-valve-unstable-2023-07-17/valve/dlls/hl_amd64.so [0]
     42034:
     42034:
     42034:     calling init: /nix/store/ngpwaaqf8vr94ql5bmzqz839a1ggkrw6-hlsdk-valve-unstable-2023-07-17/valve/dlls/hl_amd64.so
     42034:
     42034:     /nix/store/ngpwaaqf8vr94ql5bmzqz839a1ggkrw6-hlsdk-valve-unstable-2023-07-17/valve/dlls/hl_amd64.so: error: symbol lookup error: undefined symbol: GetNewDLLFunctions (fatal)
     42034:     /nix/store/ngpwaaqf8vr94ql5bmzqz839a1ggkrw6-hlsdk-valve-unstable-2023-07-17/valve/dlls/hl_amd64.so: error: symbol lookup error: undefined symbol: Server_GetBlendingInterface (fatal)
     42034:     /nix/store/ngpwaaqf8vr94ql5bmzqz839a1ggkrw6-hlsdk-valve-unstable-2023-07-17/valve/dlls/hl_amd64.so: error: symbol lookup error: undefined symbol: Server_GetPhysicsInterface (fatal)
     42034:     /nix/store/ngpwaaqf8vr94ql5bmzqz839a1ggkrw6-hlsdk-valve-unstable-2023-07-17/valve/dlls/hl_amd64.so: error: symbol lookup error: undefined symbol: SV_SaveGameComment (fatal)
Ver: Xash3D FWGS 0.20 (build -12874-notset, linux-amd64)
Crash: signal 11 errno 0 with code 1 at 0x78 (nil)
Ver: Xash3D FWGS 0.20 (build -12874-notset, linux-amd64)
Crash: signal 11 errno 0 with code 1 at 0x78 (nil)
Stack backtrace:
Stack backtrace:
 1: 0x7f603040f005 (/nix/store/zns2rxbqx6fx9qi8x6kk9dlkdpnyivsj-xash3d-unwrapped-unstable-2023-07-02/lib/xash3d/libref_soft.so)
 1: 0x7f603040f005 (/nix/store/zns2rxbqx6fx9qi8x6kk9dlkdpnyivsj-xash3d-unwrapped-unstable-2023-07-02/lib/xash3d/libref_soft.so)

necrophcodr · 2023-09-09T21:47:36Z

@TheBrainScrambler I've looked into the issues for a bit, not being very familiar with the codebase I was unable to find the root of the issue. If anyone manages to run it just fine on a clean system with the software renderer, then I'd definitely say keep it as is, otherwise it might be better to default that part to off?

If you're able to test this on a machine that preferably hasn't had any related work done, or is a fresh install, and it works fine there, that's by far good enough of a confirmation that it is related to my setup, although I'm not aware of what exactly it could be when it seems to issue errors relating to the currently-not-built VGUI support.

I should also point out that I do not have write permissions for this repository, so the above is merely my opinion.

TheBrainScrambler · 2023-09-12T17:40:21Z

@necrophcodr I've tried running Xash3D with LD_DEBUG=libs too, and I get the exact same symbol lookup errors that you have with the software renderer, except that I don't get any crash. So there errors are unrelated to your crash.

It's weird because Nix after all revolves about sandboxing and reproducible builds, normally I shouldn't have to get a clean install to test this ... I've built xash3d using nix-build so normally there should be no leak eh ?

I'm going to default the software renderer to false, because there is a merge conflict I have to solve now anyway, and thinking about it I don't want to retest it if there is an update. I first thought about turning it back on by default if someone else can test it and confirm it works, but I don't think it's worth maintaining it in the long run. I don't think anyone will actually care about this. And if someone does he can just enable it with an override.

If someone wants any of the renderers other than opengl enabled by default, let me know, I'm open to that. It shouldn't matter too much though since Hydra won't build this package anyway.

necrophcodr · 2023-09-12T21:36:06Z

@necrophcodr I've tried running Xash3D with LD_DEBUG=libs too, and I get the exact same symbol lookup errors that you have with the software renderer, except that I don't get any crash. So there errors are unrelated to your crash.

It's weird because Nix after all revolves about sandboxing and reproducible builds, normally I shouldn't have to get a clean install to test this ... I've built xash3d using nix-build so normally there should be no leak eh ?

I'm going to default the software renderer to false, because there is a merge conflict I have to solve now anyway, and thinking about it I don't want to retest it if there is an update. I first thought about turning it back on by default if someone else can test it and confirm it works, but I don't think it's worth maintaining it in the long run. I don't think anyone will actually care about this. And if someone does he can just enable it with an override.

If someone wants any of the renderers other than opengl enabled by default, let me know, I'm open to that. It shouldn't matter too much though since Hydra won't build this package anyway.

Personally I much prefer the software renderer, because it's closer to the original experience. But that's my own experience, so I approve of this decision! I've got nothing else to add, it looks decent to me.

TheBrainScrambler · 2023-09-13T16:19:42Z

Personally I much prefer the software renderer, because it's closer to the original experience. But that's my own experience, so I approve of this decision! I've got nothing else to add, it looks decent to me.

If you want it I can re-enable it by default, but for that we need that someone else tests the software renderer to see if it's just you or just me for which it works/doesn't.

necrophcodr · 2023-09-13T20:48:49Z

Personally I much prefer the software renderer, because it's closer to the original experience. But that's my own experience, so I approve of this decision! I've got nothing else to add, it looks decent to me.

If you want it I can re-enable it by default, but for that we need that someone else tests the software renderer to see if it's just you or just me for which it works/doesn't.

Oh no since it works for you and not for me, and the reason so far has not been discerned, I'd much prefer to keep it behind an easy-to-override flag instead. Those that care or want it supported, will be able to enable and test for it. And those that don't, probably won't miss it.

nixos-discourse · 2023-10-21T16:53:01Z

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-already-reviewed/2617/1180

EBADBEEF · 2023-11-18T01:03:00Z

Since this program showed up on hacker news today I went looking in nixpkgs! Can you explain why the SDK is needed to build? I wasn't really able to understand it. Is that only for 64 bit or non-x86 builds? I don't have any of the other games to test it with at the moment. I would suggest splitting it into a 32-bit and 64-bit package (kinda like wine).

I was able to get a 32 bit build running against the latest git:

nix-shell -E 'let pkgs=(import <nixpkgs> {}).pkgsi686Linux; in with pkgs; stdenv.mkDerivation { name="xash3d-fwgs"; buildInputs = [ python3 pkg-config wafHook SDL2 libopus freetype fontconfig cmake ]; } '
$ wafConfigurePhase
$ wafBuildPhase
$ ./waf install --destdir="$PWD/destdir"

A couple issues I ran into:

for 32 bit build, I needed to copy (prebuilt?!) vgui.so from 3rdparty/vgui_support/vgui-dev/lib
libopus needs to be >= 1.4 (not yet in nixos 23.05), but this is not important

I tested your package on nixos 23.05. I had to change wafInstallFlags to installFlags but it still installed into the wrong place! (out/nix/store/.... instead of out/bin/), so I had to tweak it a bit:

# wafConfigureFlags ... "--prefix=/"
installFlags = [ "--destdir=${placeholder "out"}" ];

*EDIT: I think you might also want to add dontAddPrefix for wafHook to not automatically set the prefix. That way I can get it to install to relative paths better.

The command I used to build in its own folder outside of nixpkgs: NIXPKGS_ALLOW_UNFREE=1 nix-build -E 'with import <nixpkgs> {}; callPackage ./. {}'

EBADBEEF · 2023-11-18T01:45:09Z

Oh, and TIL another way to avoid the zip timestamp problem is to put ensureNewerSourcesForZipFilesHook in nativeBuildInputs!

necrophcodr · 2023-11-18T09:38:10Z

...

I tested your package on nixos 23.05. I had to change wafInstallFlags to installFlags but it still installed into the wrong place! (out/nix/store/.... instead of out/bin/), so I had to tweak it a bit:

...

Why did you test against 23.05?

EBADBEEF · 2023-11-18T15:02:49Z

Why did you test against 23.05?

Yeah that was dumb. Hopefully that means some of my comments are wrong!

TheBrainScrambler · 2023-11-19T17:21:33Z

It's been a month since I last checked on this package, since no one has merged it yet. So there might be breakage perhaps, it wouldn't be the first time. I also don't remember everything so well.
But clearly looking at https://nixos.org/manual/nixpkgs/unstable/#waf-hook-variables-controlling (note: it's the manual for unstable) you have wafInstallFlags, and I know that it worked when I updated it last month. Also if you look at pkgs/development/tools/build-managers/waf/setup-hook.sh you indeed have a wafInstallPhase.

So make sure to test with unstable to see if you're still having problems building it.

Oh, and TIL another way to avoid the zip timestamp problem is to put ensureNewerSourcesForZipFilesHook in nativeBuildInputs!

Ah nice. It's not documented in the nixpkgs manual though :p but I will try this.

EDIT: where did you find it ? I can't even find it on the internet

Can you explain why the SDK is needed to build?

For 64bit you need it for sure. For 32bit you don't need it, because then it will just use the one that is bundled with the game you play. For example Half-Life has in its directory dlls/hl.so and cl_dlls/client.so . Those bundled libraries are compiled for 32bit since the original games are for 32bit, that's why for 64bit you can't use them and have to build the SDK. But you can also just build the SDK for 32bit and it works too. Or so I think. I've never tested it since I'm on 64bit.

for 32 bit build, I needed to copy (prebuilt?!) vgui.so from 3rdparty/vgui_support/vgui-dev/lib

Honestly I've never really understood the business with VGUI.

Also using nixpkgs-review might make things easy for you to build this repo, but as with most things, I'm not sure. I will tell you the command I use to build xash3d-valve once I'm building it.

TheBrainScrambler · 2023-11-19T17:41:06Z

Nice, ensureNewerSourcesForZipFilesHook works, thanks ! Another ugly patch eliminated. I've only tested xash3d-valve though, but I don't see why it would fail on the other games.
I'm building with NIXPKGS_ALLOW_UNFREE=1 nix-build /path/to/my/nixpkgs -A xash3dGames.xash3d-valve where /path/to/my/nixpkgs is where I have my fork of nixpkgs, which has among other things the nix files for xash3d.

EBADBEEF · 2023-11-22T14:14:58Z

Thanks for the help/pointers and also the explanations about how the engine works. I will try to take a look next week.

[ensureNewerSourcesForZipFilesHook] where did you find it ? I can't even find it on the internet

I think grepping through nixpkgs. I was looking for similar date problems and if other packages had the issue for waf. It still it took me awhile to notice it even though it is even in the waf package, hah!

nixos-discourse · 2023-12-26T18:14:33Z

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-already-reviewed/2617/1342

TheBrainScrambler · 2024-07-30T08:23:21Z

I am no longer using Nix. Someone else will have to take maintainership if this ever gets merged

vs49688 · 2024-07-31T07:14:41Z

I am no longer using Nix. Someone else will have to take maintainership if this ever gets merged

I think the lack of momentum on this is due to the license - it's unfree, meaning it won't be cached by Hydra, and people will have to rebuild it every time anyway so there's not really much point, as much as it saddens me.

TheBrainScrambler · 2024-08-02T09:40:27Z

My comment about dropping maintainership is not really related with this PR being stale, it's just that I'm not using Nix anymore, for other reasons.
I suspect more that it's just the huge number of PRs in nixpkgs that make this package ignored even though I've been posting about it 2 or 3 times in the "Already reviewed" thread on discourse. That issue is known and folks are trying to solve this.
But the point of this package was 1) while you have to build it, at least you don't have to write any recipe for it because the recipe is already written, and somehow figure out how to get Nix use your local packages, which combined with a rather bad documentation makes this a bit hard, and 2) the way I made this package was specifically done so that you don't touch your game assets, while all other methods I had seen so far told you to copy some files into your assets which I didn't like.
With that recipe you could just install the package, drop your assets into ~/.local/share/xash3d and be done with it

TheBrainScrambler force-pushed the xash3d branch 2 times, most recently from dc67807 to 46e970e Compare July 21, 2023 15:22

TheBrainScrambler force-pushed the xash3d branch from 46e970e to b3d52b0 Compare July 21, 2023 16:21

ofborg bot added 8.has: package (new) This PR adds a new package 11.by: package-maintainer This PR was created by the maintainer of the package it changes 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin 10.rebuild-linux: 1-10 labels Jul 21, 2023

SuperSandro2000 requested changes Jul 23, 2023

View reviewed changes

TheBrainScrambler force-pushed the xash3d branch from b3d52b0 to 7a245b3 Compare July 31, 2023 17:41

ofborg bot added the 10.rebuild-linux: 1 label Jul 31, 2023

TheBrainScrambler force-pushed the xash3d branch from 7a245b3 to 14104b5 Compare July 31, 2023 18:35

TheBrainScrambler force-pushed the xash3d branch from 14104b5 to 6753542 Compare August 9, 2023 18:33

ofborg bot removed the 10.rebuild-linux: 1 label Aug 9, 2023

TheBrainScrambler requested a review from SuperSandro2000 August 12, 2023 12:02

TheBrainScrambler force-pushed the xash3d branch from 6753542 to 08c68a3 Compare August 13, 2023 13:51

vs49688 reviewed Aug 31, 2023

View reviewed changes

pkgs/games/xash3d/wrapper.nix Outdated Show resolved Hide resolved

vs49688 reviewed Aug 31, 2023

View reviewed changes

pkgs/games/xash3d/default.nix Outdated Show resolved Hide resolved

vs49688 reviewed Aug 31, 2023

View reviewed changes

chayleaf reviewed Aug 31, 2023

View reviewed changes

TheBrainScrambler force-pushed the xash3d branch from 08c68a3 to be1e352 Compare September 1, 2023 10:09

TheBrainScrambler force-pushed the xash3d branch from 7a8f511 to da948c9 Compare September 12, 2023 17:49

ofborg bot removed the 2.status: merge conflict This PR has merge conflicts with the target branch label Sep 12, 2023

necrophcodr approved these changes Sep 12, 2023

View reviewed changes

TheBrainScrambler force-pushed the xash3d branch from da948c9 to 5d67981 Compare October 11, 2023 17:42

xash3d: init at unstable-2023-07-02

6c490dc

TheBrainScrambler force-pushed the xash3d branch from 5d67981 to 6c490dc Compare November 19, 2023 17:36

wegank removed the 12.approvals: 1 This PR was reviewed and approved by one reputable person label Mar 8, 2024

wegank added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jul 4, 2024

stale bot removed the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jul 30, 2024

FliegendeWurst added the 9.needs: maintainer Package or module needs active maintainers label Dec 4, 2024

getchoo mentioned this pull request Dec 5, 2024

xash3d: init at unstable-2024-12-04 #361918

Draft

13 tasks

wegank added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jan 2, 2025

xash3d: init at unstable-2023-06-13 #238392

Are you sure you want to change the base?

xash3d: init at unstable-2023-06-13 #238392

Conversation

TheBrainScrambler commented Jun 18, 2023

Description of changes

Things done

TheBrainScrambler commented Jul 21, 2023

nixos-discourse commented Jul 22, 2023

SuperSandro2000 Jul 23, 2023

Choose a reason for hiding this comment

TheBrainScrambler Jul 31, 2023

Choose a reason for hiding this comment

SuperSandro2000 Jul 23, 2023

Choose a reason for hiding this comment

TheBrainScrambler Jul 31, 2023

Choose a reason for hiding this comment

TheBrainScrambler commented Aug 9, 2023

TheBrainScrambler commented Aug 13, 2023

TheBrainScrambler commented Aug 31, 2023

TheBrainScrambler commented Aug 31, 2023 • edited Loading

vs49688 Aug 31, 2023

Choose a reason for hiding this comment

TheBrainScrambler Sep 1, 2023 • edited Loading

Choose a reason for hiding this comment

vs49688 Aug 31, 2023

Choose a reason for hiding this comment

TheBrainScrambler Sep 1, 2023 • edited Loading

Choose a reason for hiding this comment

vs49688 commented Aug 31, 2023

chayleaf left a comment

Choose a reason for hiding this comment

chayleaf Aug 31, 2023 • edited Loading

Choose a reason for hiding this comment

TheBrainScrambler Sep 1, 2023

Choose a reason for hiding this comment

TheBrainScrambler commented Sep 1, 2023 • edited Loading

TheBrainScrambler commented Sep 9, 2023

necrophcodr commented Sep 9, 2023

necrophcodr commented Sep 9, 2023 • edited Loading

TheBrainScrambler commented Sep 12, 2023

necrophcodr commented Sep 12, 2023

TheBrainScrambler commented Sep 13, 2023

necrophcodr commented Sep 13, 2023

nixos-discourse commented Oct 21, 2023

EBADBEEF commented Nov 18, 2023 • edited Loading

EBADBEEF commented Nov 18, 2023

necrophcodr commented Nov 18, 2023 • edited Loading

EBADBEEF commented Nov 18, 2023 • edited Loading

TheBrainScrambler commented Nov 19, 2023 • edited Loading

TheBrainScrambler commented Nov 19, 2023 • edited Loading

EBADBEEF commented Nov 22, 2023

nixos-discourse commented Dec 26, 2023

TheBrainScrambler commented Jul 30, 2024

vs49688 commented Jul 31, 2024

TheBrainScrambler commented Aug 2, 2024

TheBrainScrambler commented Aug 31, 2023 •

edited

Loading

TheBrainScrambler Sep 1, 2023 •

edited

Loading

TheBrainScrambler Sep 1, 2023 •

edited

Loading

chayleaf Aug 31, 2023 •

edited

Loading

TheBrainScrambler commented Sep 1, 2023 •

edited

Loading

necrophcodr commented Sep 9, 2023 •

edited

Loading

EBADBEEF commented Nov 18, 2023 •

edited

Loading

necrophcodr commented Nov 18, 2023 •

edited

Loading

EBADBEEF commented Nov 18, 2023 •

edited

Loading

TheBrainScrambler commented Nov 19, 2023 •

edited

Loading

TheBrainScrambler commented Nov 19, 2023 •

edited

Loading