Jump to content
The Dark Mod Forums

Ludvig

Member
  • Posts

    19
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Ludvig

  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.
  15. Yeah that's true, the installer could very well be bundled with the manifest! I just did it the way I'm most used to, fetch the sources from upstream and use local files only when absolutely necessary. Either way though, once it's on flathub it shouldn't really matter since it'll use the installer from when the package was built, it won't fetch it during the package installation itself. And, as you say, after the user launches the app the first time, the installer would then update itself regardless. And yeah, flatpak solves both the glibc and the opengl problem. The freedesktop runtime provides the needed opengl libs, which won't suddenly change regardless of what else the user runs on their system. If they use ubuntu from 2018 or arch linux, either way the runtime will provide the same environment. As a bonus, the way flatpak handles glibc, this should also enable the game to run on platforms that use other libc implementations (such as musl) if I understand it correctly, but I haven't tested that myself. As far as I can tell from my testing, everything seems to work. I can change settings, download and install missions, and play the game on either graphics card on my optimus laptop. So the game seems already very well behaved for sandboxing (I was honestly surprised how easy it was to get it to work). If it needs other permissions later we can add that in the manifest, but so far there doesn't seem to be any reason to.
  16. Thanks! Yeah my first thought was to compile it from source and create a standalone flatpak package. The downside there would be that, in flatpak, I'm not sure how it would handle installations of user missions for example. The game seems to assume the install location will be writable from what I can tell, which is why I needed to copy the installer to the users own data dir to make everything work. I think this is also a problem with traditional packages regardless, judging from the manual installation part there, and I don't think this is "fixable" in a good way unless the game is severely modified (install to a read-only location and put missions in ~/.local/share/tdm and configs in ~/.config/tdm for example), but I'm not an expert at this. However, that could also be done with the flatpaks, if it was implemented in that way. You could then make the manifest automatically fetch the source from the svn repository, either specifying a certain commit/tag/release or from the most recent one, install the build dependencies and build the package, and then put it on flathub for testing. The user would then just install the package as usual, no compilation time and no build environment necessary, and no need to use the installer. The flathub build bot could also run this nightly and use the flathub beta repository for people who want to test nightly builds, essentially providing both a stable package and a nightly one for testing. It's way above my level to make that work nicely though.
  17. Thanks! Yes, that's a fair point. However this uses the official installer instead, both for the original installation and updating. So once this is submitted, it should maintain itself (the minecraft and steam packages work in a similar way AFAICT). This would be basically just an easy way of distributing the official installer to people through flathub.com. There are some benefits, in my opinion: Reliability: Applications in flatpak uses runtimes instead of the system libraries. This takes up more space, but you as a packager know exactly what system your program runs on. It only needs to match a single runtime environment, rather than several possible configurations that can vary between distributions. Users won't need to go hunting with ldd if the program doesn't run anymore, if it works on one computer it should work on all. Security: Flatpaks are sandboxed by default. This game, when ran through flatpak, can't access any of the users regular files, which might help convince users to give it a try! Visibility: it'll show up in every linux users store if they use flatpak and have the flathub repository enabled: https://flathub.org/apps/category/Game Control: The control over the package would be in the hand of the developer instead of the distro packager. So in this case, you'll still have full control in how the game is packaged and distributed, since it uses the same installer and you'd be the ones with access to the flatpak manifest on flathub. Maintenance: Compared to regular distro packages, this won't have particularly high demands to stay up to date. This is the manifest file: app-id: com.thedarkmod.TheDarkMod runtime: org.freedesktop.Platform runtime-version: '21.08' sdk: org.freedesktop.Sdk command: launcher.sh finish-args: - --share=ipc - --socket=x11 # - --socket=fallback-x11 - --socket=wayland - --device=dri - --socket=pulseaudio - --share=network - --talk-name=org.freedesktop.Notifications modules: - name: thedarkmod buildsystem: simple build-commands: - install -Dm755 tdm_installer.linux64 /app/bin/tdm_installer.linux64 - install -Dm755 launcher.sh /app/bin/launcher.sh - install -Dm644 com.thedarkmod.TheDarkMod.desktop /app/share/applications/com.thedarkmod.TheDarkMod.desktop - install -Dm644 com.thedarkmod.TheDarkMod.png /app/share/icons/hicolor/48x48/apps/com.thedarkmod.TheDarkMod.png sources: - type: archive url: https://update.thedarkmod.com/zipsync/tdm_installer.linux64.zip sha256: f321c07177393834e37e9821f532994e6a871179c2875fa46460a6fdf7054884 - type: file path: launcher.sh - type: file path: com.thedarkmod.TheDarkMod.desktop - type: file path: com.thedarkmod.TheDarkMod.png It's a fairly simple structure, I think. Basically what would be needed is to change the sha256-sum when you want to push an update. Runtime-version can also be updated, the runtime environment is updated once a year. Flatpak is able to have several runtimes installed though so there's no rush in updating that, and it's just a matter of changing the version number to the new version after making sure the game runs with the new runtime as well. Updating the runtime shouldn't have any other issues compared to distributions updating their system packages normally, but worst case you can keep using an older runtime if needed and it shouldn't impact the rest of the system. (Speaking of the sha256 sum, it's needed by the flatpak builder, but it'll be baked into the package once it's on flathub so it shouldn't matter. It'll auto-update itself on the first run regardless, since the current version doesn't match the checksum either way due to the builder stripping the files when packaging. The initial installer is only used as a way to kickstart the actual installer, it copies the packaged installer, runs it, lets it auto update and then it'll use the one provided through the auto-updater afterwards). Now, there's only really two drawbacks with this system as I see it: Flatpaks needs runtimes, this means that if this is the only flatpak you use you'll need to install the freedesktop runtime which is an added 100-200MB or so. However, runtimes are shared between packages, so if any other package in the system also uses the freedesktop runtime, it'll already be installed. Installing desktop shortcuts and stuff, I don't think it'll work. Even if you give it write-access to the user desktop, the shortcut itself would probably need to be modified. In fact, I don't think you can customize at all where the game will be installed the way it's currently set up, it'll always end up in the package directory under ~/.var, like (most) flatpak packages.
  18. Hi! This is a manifest to install the installer as a flatpak. It contains the following: com.thedarkmod.TheDarkMod.yml - Flatpak manifest, easily readable. com.thedarkmod.TheDarkMod.desktop - Desktop file. You can right click on it in an app launcher and choose "Installer" to open the installer program. com.thedarkmod.TheDarkMod.png - Icon for .desktop file, can't use .ico for this. launcher.sh - Simple script to initialize installation directory and choose between installer or game. On first run the script will copy the installer to a sandboxed location under your user home (~/.var/app/com.thedarkmod.TheDarkMod/data/TheDarkMod), and then start it. The game will then be installed to this location. Afterwards, the script will check for the game launcher instead and run that if possible, otherwise it'll try to run the installer again. You can also open the installer by right-clicking on the icon and choosing "Installer", or manually by running: flatpak run com.thedarkmod.TheDarkMod install For the people using prime/optimus systems it should also default to running on the dedicated GPU rather than the internal when using the desktop-file. To test this app locally you need to install flatpak-builder and the org.freedesktop.Sdk runtime in flatpak. You can then build and install the package by extracting the zip, entering the tdm directory in a terminal and running: flatpak-builder --force-clean --user --install build com.thedarkmod.TheDarkMod.yml To get this app published on flathub you can submit it via the instructions at https://github.com/flathub/flathub/wiki/App-Submission. I've never submitted an app myself so I don't know exactly how it's done, but AFAICT, it should just be putting these 4 files in a git repo and send a pull request to the flathub repo on github. Feel free to edit any files as you see fit. The app name was based on the webpage URL, but maybe you want to change that or edit the capitalization or something like that. thedarkmod-221003.zip
×
×
  • Create New...