Jump to content
The Dark Mod Forums

Ludvig

Member
  • Posts

    19
  • Joined

  • Last visited

  • Days Won

    1

Ludvig last won the day on October 5 2022

Ludvig had the most liked content!

Reputation

11 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Yeah that might be a good idea, but it's not something specific to this package.
  2. Yeah, that's something that flatpak does, and only for nvidia since the driver isn't fully open source. Basically flatpak checks what version of the driver your system is using and tries to install a corresponding version for the runtime. These need to match for hardware acceleration to work within flatpak. You can see if you have any old nvidia runtimes that can be removed by running flatpak remove --unused
  3. Yeah, the permission then should be --filesystem=xdg-data/darkmod:create for the manifest for DR too, so either the darkmod installer or DR can create the dir. The launcher script I made already checks if the folder exists, and if not it creates it, so it'll handle the folder already existing. And yeah I think it's reasonable to lock down access by default, and the people with advanced use-cases should be able to find information on how to customize their install. However, I don't think it's possible to customize the install path for the flatpak, since the launcher script currently assumes it's installed in the default location. So currently, if they want to install multiple versions, they'll need to use another installation method. Fixing this would be difficult as it is now, I think, because we'd need to get the install path from the installer somehow, and we'd have to include a lot more logic checks in the launcher script I think. The idea then would be that the launcher script would check the default game directory for a log, and extract the actual install path. But I don't think that's currently feasible. Of course, having one flatpak installation of DM and another non-flatpak installaton will work just fine! I made a quick 64x64 icon by scaling down the 128 icon with linear scaling in gimp. Looks a little blurry to me.
  4. Thank you for the feedback! Yeah I should clean out commented lines. The manifest was just based on a template I've used for other projects, so I haven't gotten around to that, same with the --talk and --socket permissions. The icon thing is correct, I just used the one from the project but I need to find a bigger one (or just upscale this one, as a last resort maybe). As for the flathub.json I just copied the one from DarkRadiant. Hope you don't mind! Regarding DarkRadiant, changing the install location for this is probably a good idea, because of the restrictions you described in the other thread, the question is what to use. Ideally flatpaks shouldn't have more permissions than what they need (so preferably no --filesystem=host or --filesystem=home if not absolutely necessary). The XDG specification also doesn't seem to have a default directory for games, but one work-around would be to use the actual XDG_DATA_DIR (usually defaults to /home/$USER/.local/share), which would fit with how other applications store their data. This would make the game folder kind of hard to navigate to from DarkRadiant though, maybe? Would it be possible to set the default search-path for DarkRadiant to something like ~/.local/share/darkmod? In that case DarkRadiant would just need --filesystem=xdg-data/darkmod for its permission. I've modified the manifest with your suggestions and the proposed change in default location. If you want to give it a try, I suggest deleting ~/.var/app/com.thedarkmod.TheDarkMod first so there are no conflicts with the old game installation. Edit: I used https://steamuserimages-a.akamaihd.net/ugc/155775322931431372/F03A45CA10D985E847A7D694AA3A91D6F829F77E/?imw=637&imh=358&ima=fit&impolicy=Letterbox&imcolor=%23000000&letterbox=true as a basis and created a new 128x128 icon for the app. Would this be acceptable, you think? com.thedarkmod.TheDarkMod.yml
  5. Hey! Have you had a chance to try this with the flatpak manifest I'm working on? I'm curious if one flatpak app can access another's dir in ~/.var or if it's completely disabled. If it's the latter, we need to change the default installation path in the darkmod flatpak:
  6. Hi! That's the eventual plan yeah. I think technically we're good to go, we just need to create a file for appstream data: https://github.com/flathub/flathub/wiki/App-Requirements including license information. I haven't worked with appstream data yet, so if you want to help out feel free to send a merge request at https://github.com/ludvigng/thedarkmod (or here in the thread works too), otherwise I'll start working on that next. After that's done, I think we can just fork the flathub repo, create a branch with the app and submit a pull request against the new-pr branch and then just wait.
  7. I've updated the manifest to use the new freedesktop 22.08 runtime. thedarkmod-221003.zip
  8. The tdm_installer is not run during the build process, it's run only when the user first launches the app. This is more concerning stuff that uses npm or similar package systems that might want to download other packages during the build. Any such dependencies must be declared in the manifest itself and downloaded by the flatpak builder instead. The build process for this package is just downloading the tdm_installer along with the launcher script and desktop file, and placing these files in a specified location. Nothing is actually built or run during the build.
  9. For flathub it depends, I think. Usually it's good hygiene, but sometimes it's not possible due to licensing or other issues. I'm not sure if flathub has a hard stance on it, compared to debian or fedora. If we submit it, they'll might comment on it and it could depend on the reply. Zotero for example does something similar to our manifest, where it downloads the official binary package from their web page and then just puts the files in the correct location, even though it's technically mostly AGPL? https://github.com/flathub/org.zotero.Zotero/blob/master/org.zotero.Zotero.json If that becomes an issue, I could try whipping up a manifest that builds from a particular rev from the svn, but I'm not familiar with svn in general and it would likely take much more time for me to test and build it, so it'd have to happen after the summer (I'm working on my master's thesis now, then I have some work lined up). I'm also not sure how to work in the downloadable missions with that, since technically they would have to be installed in the installation dir, which in this case would not be writeable by the game itself. So either it'd have to copy the compiled code to the user dir in .var and then run from there, basically duplicating the amount of disk space, or we'd have to modify the game code (and I'm not a programmer! ). So I think that could be reason enough to motivate why we do it the way we do it. It'd either be a big waste of space, or it'd be skirting the line of the security model if we modify the app install dir during runtime or we'd have to do considerable work to change the code. Neither option is good, compared to what we're doing now.
  10. I've updated the link in the OP with the latest version from the git repo of the launcher script and flatpak manifest etc. I've also checked the script with shellcheck to ensure it passes shell sanity, and it detected no issues. Only suggestions were to properly escape the variables and to add || exit to the cd command in case it fails, both which have been added. thedarkmod-main-2022-05-06.zip
  11. Good that the sound issue goes away by itself, I haven't really tested this in a VM so I don't know any other potential issues. I don't think many users would be playing this in a linux VM either way, but it's good to check for compatibility regardless. 1) Yeah, that's probably the best compromise. 2) Yeah that seems to be correct. PrefersNonDefaultGPU is indeed a newer thing in the .desktop files, the old one was X-KDE-RunOnDiscreteGpu=true which newer versions of flatpak-builder complains about if you include them. .var is the standard to store user data for flatpaks. I could change the launcher to install in the users home dir instead, but then we'd need permissions for the entire home dir which would sort of defeat the sandboxing (and is usually discouraged by flatpak users AFAIK). Other games in flatpak also seem to prefer the .var directory, probably for the same reason of sandboxing (steam, minecraft, various emulators etc all store their things in .var). $XDG_DATA_HOME is just a standard name for the user local data, which normally would be /home/username/.local/share, but in flatpak will mean /home/<username>/.var/app/<appname>/data, it's the sandboxed user data storage basically. This is where apps "should" store their application data, while configs usually would go in XDG_CONFIG_HOME (which means ~/.config normally or ~/.var/app/<appname>/config in the flatpak sandbox). I have made a github just to keep track of the changes, if you want you can put a pull request there: https://github.com/ludvigng/thedarkmod otherwise I'll just make the changes from your suggestions in the thread either way.
  12. Odd, yeah. These are the corresponding lines when running the flatpak on my native linux system: ----- Initializing OpenAL ----- Setup OpenAL device and context OpenAL: found device 'ALSA Default' [ACTIVE] OpenAL: found device 'HDA Intel PCH, ALC294 Analog (CARD=PCH,DEV=0)' OpenAL: found device 'HDA Intel PCH, HDMI 0 (CARD=PCH,DEV=3)' OpenAL: found device 'HDA Intel PCH, HDMI 1 (CARD=PCH,DEV=7)' OpenAL: found device 'HDA Intel PCH, HDMI 2 (CARD=PCH,DEV=8)' OpenAL: found device 'HDA Intel PCH, HDMI 3 (CARD=PCH,DEV=9)' OpenAL: found device 'HDA Intel PCH, HDMI 4 (CARD=PCH,DEV=10)' OpenAL: device 'ALSA Default' opened successfully OpenAL: HRTF is available [ALSOFT] (EE) Failed to set real-time priority for thread: Operation not permitted (1) OpenAL vendor: OpenAL Community OpenAL renderer: OpenAL Soft OpenAL version: 1.1 ALSOFT 1.21.1 OpenAL: found EFX extension OpenAL: HRTF is enabled (reason: 1 = ALC_HRTF_ENABLED_SOFT) OpenAL: found 256 hardware voices ----- Initializing OpenGL ----- I don't see any other openal stuff after that. Given how old 16.04 is in terms of software, it could just be some complication between openal, flatpak and the VM software, I think. Actually, looking through the terminal feedback, on your last post you mentioned it looking for the "darkmod" path. Seems it still is: no 'darkmod' directory in exe path /home/ludvig/.var/app/com.thedarkmod.TheDarkMod/data/TheDarkMod, skipping WARNING: using hardcoded default base path I guess that because it doesn't do partial matches it seems to work. We could probably change the install directory to just "darkmod" (full path would be ~/.var/app/com.thedarkmod.TheDarkMod/data/darkmod then instead), and it should still work as expected. On the other hand, I don't know if it actually matters, since it seems to be working either way right now? EDIT: Actually, I changed the path in the launcher script to install to a directory named "darkmod" instead, and everything still seems to work fine. I think it's probably better to use that then, since it's what the game seems to expect! The path warning disappeared too, so that'll make less risk of misleading warning messages I guess.
  13. Yep! Tested it during the training missions with two different saves. Maybe it's a windows-specific problem? Paths in linux are case-sensitive which might also make a difference? I'm not actually a programmer so my knowledge is very limited in of the specifics in how it actually works on a deeper level. Worst case we could rename it to something like com.tdm.TDM, but that might be hard to decipher for people unfamiliar with the game? Plus it's usually a nice thing if parts of the name references the actual source (like freedesktop.org being the owner of org.freedesktop-packages).
  14. I got the same error running from the live environment, but after doing an install in a VM, enabling universe, multiverse, xenial-backports, doing a system update and then adding the alexlarsson PPA to install flatpak it seems to work. Maybe something is out of date? EDIT: For what it's worth, it worked immediately on 18.04. I'm guessing you're probably using 16.04 to build for maximum compatibility of glibc, which is good, but in 18.04 I didn't have to add the PPA to get flatpak installed, everything worked straight from the live environment. Since 16.04 is on extended maintenance (meaning, people would need a support contract to keep receiving security updates I think), I don't think many people will be running the game on such an old platform. But it should be possible to use the flatpak too, if they choose to.
×
×
  • Create New...