Allow (opt-in?) writing to XDG_STATE_DIR instead of requiring `cwd` to be writable

[x10an14]

Description

• Currently, the installation says that the program requires the folder it resides in to be writable by the user running the program.

Suggest a solution

• Leverage the XDG/Freedesktop standard (https://github.com/xdg-net/Xdg.Directories maybe?) to write to $XDG_STATE_DIR/<program name "xcom2-aml"?>/, which always should be writeable for the executing user.

Would make things easier for those of us who like to install programs into immutable filesystems for a plethora reasons (including security ones).

[RevZero]

I get your point, however

• The steam_appid.txt has to reside in the same folder where the steam_api64.dll is located. AML creates this file on first start (depending on game type selection) and thus, requires write access to the binary folder.
• AML is supposed to be "portable". But using a special folder could be optional of course.

PS : I don't see the benefit of XDG here. I would leverage Environment.SpecialFolder instead.

[x10an14]

"and thus, requires write access to the binary folder"

Ref:

The steam_appid.txt has to reside in the same folder where the steam_api64.dll is located. AML creates this file on first start (depending on game type selection) and thus, requires write access to the binary folder.

Some clarifications/confirmations, it's these folders you refer to inside the Steam folder containing your game libraries?

Location(s) of **steam_appid.txt** inside Steam folder

-> $ find . -type f -name steam_appid.txt
./common/Risk of Rain 2/steam_appid.txt
./common/The Two of Us/steam_appid.txt
./common/Valheim/steam_appid.txt
./common/Door Kickers - Action Squad/steam_appid.txt
./common/Counter-Strike Global Offensive/steam_appid.txt
./common/Tabletop Simulator/steam_appid.txt
./common/ProjectZomboid/projectzomboid/steam_appid.txt
./common/Deadlock/game/bin/win64/steam_appid.txt

Location(s) of **steam_api64.dll** inside Steam folder

-> $ find . -type f -name steam_api64.dll | grep Rain
./common/Risk of Rain 2/steam_api64.dll

Yeah, I get why AML needs write access here, but is this the only folder it requires write access to?
Ref. the cwd (current working directory, AKA path you start AML from) mention in issue title?

---

XDG

Ref

PS : I don't see the benefit of XDG here. I would leverage Environment.SpecialFolder instead.

Well, it'll open up the opportunity for AML to be used (at own risk and etc of course) on other operating systems (like SteamDeck OS).
Not just windows.

A benefit of XDG I didn't see you address, is that even if the XDG standard was developed for linux derived OSs, plenty of programming languages and 3rd party dependencies use and rely on it now to standardize across MacOS, Windows, and not just Linux OSs.

[RevZero]

I am not sure I follow. What I meant is, that the steam_api64.dll is located in the AML-folder because it is a dependency for the Steamworks.NET.dll library. From Steams API perspective, AML is a game, which is why steam_appid.txt is required to identify the game id. By choosing between XCOM2 and Chimera, AML creates the file with the respective game id accordingly.

The SpecialFolder stuff from .NET has multi-platform support (Windows, Linux and MacOS IIRC). So I would imagine this would suffice.

[x10an14]

The SpecialFolder stuff from .NET has multi-platform support (Windows, Linux and MacOS IIRC). So I would imagine this would suffice.

Apologies for my ignorance/incompetence.
I know lots if .NET is cross platform, but from your link I can see no mention of a) where these folders/locations equivalenta would be on other systems, and b) nor how it can be overwitten/steered with e.g. environment variables (XDG_STATE_HOME being an example of how this is purposefully designed into the XDG protocol/standard).

Would you be able to give some directions to find the answers to a and b?

[x10an14]

Found the answer to a) in a private blog post from 2015: https://jimrich.sk/environment-specialfolder-on-windows-linux-and-os-x/

[RevZero]

Sorry for the lack of a response. I was busy and forgot about it.
The MS documentation is indeed lacking some information with respect to special folders and other platforms. The blog post is 9 years old, IIRC there were some changes to those folders since then, so I would not rely on those examples. There are some stack overflow posts with more recent information.

But regardless, there is still the problem that AML needs write access to the application folder, as described above.