Possible to specify full path to game directory and writeable folder?

[sofakng]

I'm using Xash3D-FWGS on macOS and I'm trying to build an app bundle (read-only) so I need a way to specify the full path to the game directories and read/write path for configs and save games.

Is this possible?

It seems like I specify the path to the game files (-rodir) but Xash3D-FWGS will still write config/data to the current path.

[Velaron]

configs are written to the directory passed with "-game" parameter i think or XASH3D_BASEDIR env variable, -rodir or XASH3D_RODIR is obviously only for reading

[sofakng]

Doesn't seem to be working...

Here are example file location:

• /opt/xash3d/xash3d (executable)
• /opt/xash3d/libref_gl.dylib
• /opt/xash3d/(...)
• /games/valve/halflife.wad
• /games/valve/(...)

It doesn't seem like I can execute xash3d -game with a full path (it errors it can't find gfx.wad). If I set XASH3D_BASEDIR then it looks for both the Xash3D libraries (libxash, etc) AND the game data in the bae folder.

[Velaron]

you have to specify both at the same time, XASH3D_RODIR=(path-to-game-data) XASH3D_BASEDIR=(path-to-store-the-configs)

[sofakng]

Thanks so much for the help but maybe I'm still doing something wrong?

For example, if I run "./xash3d -rodir /games -game ~/.config/xash3d" it still writes files to the xash3d executable's folder. (it seems to ignore the -game parameter)

However, I can specify -game gearbox (or similar) and it does look for the gearbox data inside the rodir, but it will write the config/saves to the xash3d executable directory.

[Velaron]

I am pretty sure XASH3D_BASEDIR is actually different from the -game parameter, while -rodir behaviour should be the same as the env variable

[Velaron]

if i had to guess you have to use it like this, but I can't test it right now
XASH3D_BASEDIR=~/.config/xash3d ./xash3d -rodir /games -game gearbox

[a1batross]

Yeah, there aren't any -basedir command line parameter, and it's not planned to add it.

I would recommend writing a simple shell script, that will set up XASH3D_RODIR and XASH3D_BASEDIR environment variables and allow passing any command line parameters.

Like this:

#!/bin/sh
export XASH3D_RODIR=/games
export XASH3D_BASEDIR=~/.config/xash3d

exec $DEBUGGER /opt/xash3d/xash3d "$@"

This of course can be remade into something more advanced, like I did for Flatpak port: https://github.com/FWGS/xash3d-fwgs/blob/master/scripts/flatpak/run.sh. The XASH3D_BASEDIR is set to be in XDG_DATA_HOME, according to XDG specification. XASH3D_RODIR is detected through scanning default Steam library paths, though it's not very unreliable and we should parse VDF configs instead... but it's still an example of a bundled Xash3D FWGS engine.

[sofakng]

Thanks again so much for the help!!

I'm trying to experiment and understand it better, but doesn't Xash3D expect the libraries (libxash, libref_gl) to be located in the BASEDIR? (ie. I would have to copy the libxash/libref libraries into ~/.config/xash3d)

I'm trying to have all Xash3D binaries in the same folder (xash3d, libxash, libref_gl) which is read-only, and then the game folder in a different location which is writeable.

Does that make sense?

[a1batross]

Libraries are tricky.

Game libraries usually found through VFS layer, so they can be both in rodir and basedir. There is specific function called FS_FindLibrary for that.

But engine libraries are found through the dynamic linker. That's where I used RPATH flag. I don't know if RPATH is supported on OSX, but it's hardcoded to look into ${ORIGIN} which linker sets to the executable path.

[a1batross]

The dynamic linker behavior on OSX is controlled by DYLD_LIBRARY_PATH environment variable as far as I know in case if RPATH is being ignored.

[sofakng]

Thanks - That is really helpful.

Where does Xash3D create its config and save games? Is it always in the current directory + gamename or is it off the BASEDIR?

[a1batross]

@sofakng BASEDIR is the CWD and CWD is always our writable directory. And yes, it preserves the hierarchy, so game-specific configs, saves, screenshots are always saved in game directory, subdirectory in BASEDIR.

By the way, keep in mind, RoDir isn't ideal. It's good for app bundles like this or Flatpak, but not ALL mods support it. It actually depends on mod developer, if they did have used standard C/C++ IO, it doesn't go through our Virtual FS layer, and mods might not work as expected because they can't access files in RoDir, they just don't know anything about it.

If you're making an app bundle, both RoDir and BaseDir should be accessible to the user. And if they are accessible, and you're not trying to auto-detect Steam folder, you MIGHT actually NOT need RoDir, just place all mod files in BaseDir.

[sofakng]

Aha! I've found part of the problem. It looks like macOS should use @loader_path instead of $ORIGIN.

If I modify this line then it finds the libraries perfectly:

xash3d-fwgs/wscript

Line 354 in bee35a1

conf.env.DEFAULT_RPATH = '$ORIGIN'

I found this issue from another project: bazelbuild/bazel#4589

(the other option appears to be @executable_path)

[a1batross]

if conf.env.SAILFISH == 'aurora':
 conf.env.DEFAULT_RPATH = '/usr/share/su.xash.Engine/lib'
elif conf.env.DEST_OS == 'darwin':
 conf.env.DEFAULT_RPATH = '@loader_path'
else:
 conf.env.DEFAULT_RPATH = '$ORIGIN'

Like that?

[sofakng]

Yup!

That works perfectly. I can then set XASH3D_RODIR and XASH3D_BASEDIR and it works as expected.

Thanks so much again!

[a1batross]

c6b6938

[sofakng]

Perfect! Tested and working. Thanks again!

[a1batross]

@sofakng btw you really helped with OSX support for the last few days. Do you want to maintain it? @tomkidd also asked about OSX maintainership. You both can team up.

If you don't have too much time, ports maintainership is usually passive. It's rare when we have platform-specific bugs, but it would be nice to have continuous builds for Mac, or better integration with Mac exclusive features (???).

=======

Here goes the rant, sorry about that, lol.

As I said before, the problem to maintain Apple ports for me is that I don't have any hardware atm. It's not like I have a personal grudge against Apple, except about running OSX in virtual machines on non-Macs, it just happens.

Yes, all their devices are made for consumer market but usually when I see prices to let's say Mac Mini, I would rather choose something different, rare and outdated or not available to consumer market hardware, especially if you know who to ask for help. Or even if I get a device with Apple M1 or Apple M2, I would rather use it to contribute to Asahi Linux. :)

[sofakng]

Oh, no problem... I'm just glad to have it working and I can't thank you enough for making the changes!

@tomkidd runs MacSourcePorts.com and does a fantastic job of maintaining everything. I'd be more than willing to help where I could but he's probably a better person to list as maintainer if he's interested.

As for the rant, I understand that Apple devices aren't for everybody. They are typically overpriced and locked down, but it's hard to beat the quality of the screen, keyboard, trackpad, speakers, etc. It was both good and bad when they used x86 processors though. I loved running bootcamp for a full Windows/Linux experience, but the new arm64 chips are crazy efficient.

I can't wait for Asahi Linux to mature (especially the video drivers!). I would love for it become a replacement for macOS even! :)

Anyways -- thanks again so much for this fantastic project/fork!!

[a1batross]

@sofakng could you then add yourself here https://github.com/FWGS/xash3d-fwgs/blob/master/Documentation/ports.md? We do not ask for email addresses, GitHub handle is enough.

[tomkidd]

Yeah for the ports I maintain for Mac Source Ports, I try and hammer everything into using ~/Library/Application Support/ subdirectories, which has the advantage in that it allows people to just run the app bundle wherever it is and also doesn't pulverize anything when a new bundle is available, doesn't break the bundle signing by adding files to the Resources folder, etc. I'm not sure it's actually the best practice but it's what most other ports do so I've kept going with it. The goal of the site is to have as little friction as possible for the benefit of less technical users.

For Xash3D-FWGS, I've got this somewhat hacky way of adding this ability in while also being able to look in the bundle for the DLLs, extras.pk3, etc. and there was this glitch in it for an embarrassingly long time dealing with C string handling that I've merged in a fix for now, but there's been 700+ commits since then and my last rebase attempt was unsuccessful so I'm evaluating how to regroup.

In any event though, for that older version I now have an ARM64 bundle happening where you can switch between HL1, BS and OpFor so long as the data folders are in place, my goal is to get that going for Intel/Universal and with the latest changes.

[sofakng]

Sounds good ... I've submitted a pull request: #1427. Hopefully @tomkidd can add his name as well if interested.

@tomkidd - I'm not too familiar with app bundles and code signing, but I was able to get everything compiled from the latest code. I was also able to create app bundle using a shell script to call Xash3D with the required parameters so the data is located in ~/Library/Application Support but the executable and libraries (dylibs) are stored in the app bundle.

I think the extra code you added to load the libraries isn't needed after @a1batross changed RPATH from '$ORIGIN' to '@loader_path' in the build script.

Here is the app bundle so maybe you can take a look and let me know what you think? It's compiled (and unmodified) from the git code except the HLSDK required a small change (FWGS/hlsdk-portable#390)

Half-Life.app.zip

[tomkidd]

Your bundle works, the only thing that's an issue with the shell script approach is that utilities like Appparency can't see executable information. Not the end of the world but I think it might still have value to have a code-based approach like some other ports I work with do

I just figured out how to get my changes working with the latest code, I'll experiment to see if any of it is unnecessary with that RPATH stuff like you said. Some of the changes are based around getting valve/extras.pk3 to load from the bundle while everything else loads from App Support (amongst other things, it gets the little "close" and "minimize" buttons on the menu working, I think).

Also thanks for pointing out the HLSDK thing, I was literally having issues yesterday due to that.

(and if it's too chatty to keep this going as a conversation in a GitHub issue feel free to email me - my email address is on my profile)

[a1batross]

If script isn't the best solution, it might be possible to fork game_launch here to have OSX specific version.

game_launch itself is a simple stub for possible expansion by game developers. But usually, everybody just change default game directory name. :)