Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by jonri

  1. @datiswoustry upgrading your flatpak to the new 3.3.0 release. The 3.2.0 flatpak was indeed compiled against wx 3.0.5, but since a blocking bug got fixed the new one is using wx 3.2.1. I've got both flatpaks installed, and for me the old one has the scrollwheel issue and the new one does not.
  2. The Flathub package has been updated, it should be available once their system finishes building it.
  3. I just copied this information out of the .desktop file. It wouldn't hurt to clean some of those up though, the longer description was also there but might be a bit brief for a graphical package browser too. Not DarkRadiant specific, but I think you usually just have to install the Flatpak version of your system theme. For me (KDE / Breeze), I had to install https://github.com/flathub/org.gtk.Gtk3theme.Breeze and apply the workaround from the readme.
  4. Good news everyone! Flathub accepted our package as-is! You can find it here: https://flathub.org/apps/details/net.darkradiant.DarkRadiant I started writing a wiki article for it yesterday, I'll change the wording to let people know how to opt in to the sandbox instead.
  5. I think this is the only outstanding issue left. Instead of requiring TDM to be in /home, my alternative idea is to provide instructions for the user to modify the permissions after installation. This can either be done with a single command along the lines of flatpak override --user --filesystem=/path/to/tdm net.darkradiant.DarkRadian or by using Flatseal to so the same graphically. I propose putting these instructions in a wiki article that we link to in the package description, and possibly a little sentence on the Game Setup dialog in the next version of DR saying "Can't find your game path? Click here for instructions" that would show up in the flatpak version only. This process seems to be what various media players have settled on doing when they need persistent access to an arbitrary directory. As long as your TDM path doesn't change, this would be a one-time process.
  6. Where should we expect the files to be? The darkradiant flatpak is separate from the game itself. Since TDM has its own installer, the files could be anywhere the user decides.
  7. I'm not concerned about the DR flatpak install location, but rather being able to access the TDM game files in whatever arbitrary location the user has installed them. 1. We need to read the game files for the user to make use of any game assets in their map. 2. We need to write the map and its supporting files to this location for them to be loadable in-game.
  8. One of flatpak's strengths and limitations is that it tries to sandbox off anything that is not required for the application to run. Since TDM can be installed anywhere, the only way to support that is to let the application have access to the whole filesystem, which essentially defeats the sandbox. There's a concept of "portals" that lets the user poke holes in the sandbox to load and save files, but I think DR does too much file access behind the scenes for this to work. I need to do more research here. If we can't find a good way forward, in the worst case we could provide instructions on how the user can use flatseal to change the flatpak's permissions and allow access to their chosen TDM install path after installation.
  9. Got a small laundry list of things to fix up to pass validation: We need a content rating, I'm looking at how to generate that now. We need a 128x128 icon. I found this so I was wondering @greeboif you had any other icon source files lying around. If not I'll just upscale the 64x64 icon to meet the requirement. Screenshots of the application are also mandatory. I could make a wiki page to host them and it would probably be fine, but for maximum stability of the links could we put a Screenshots page on www.darkradiant.net without too much trouble? Allowing access to the whole filesystem is strongly discouraged, but hard to avoid if we want to support arbitrary TDM paths. Would it be reasonable to assume that most people install TDM in their /home directories, or would accept that limitation if they were using the flatpak DR? A couple other side notes: I realized that net.darkradiant.DarkRadiant would be a more accurate package name than com.thedarkmod.DarkRadiant, so anyone who built the test version will want to uninstall it once the flathub version comes out. I had to make an appstream metadata file, ultimately this can go in the main DR repo and will probably need to be updated with the new version number on each release.
  10. I think I've got this in good shape: Upgraded to the new DarkRadiant release 3.2.0 Icon is now installed correctly Tested wxgtk 3.2.0, it works better than it did before but still found issues (bug report to come tomorrow) so I will keep the flatpak on wxgtk 3.0 for now. Tested on wayland wxgtk-3.0 does not work in native wayland mode, but seems to be ok in xwayland wxgtk-3.2 will likely work natively on wayland once remaining issues are fixed In either case, a user on wayland won't have to worry about it, the flatpak manifest is configured to do the right thing I'll submit this to flathub for review tomorrow.
  11. Thanks for taking a look! I think this is to be expected, flatpak should keep configuration files within the app's sandbox. I think figured out the difference - I normally run in SplitPane layout and this doesn't happen there. I was able to reproduce it in the default layout. It's been surprisingly harder to fix than expected. The directive in the build script that's supposed to do it can't find the original icon. At worst I'll just make a copy of the icon and a new .desktop file to go with it. I should also be able to give it a test on a KDE wayland session.
  12. If anyone is inclined to try out the flatpak by building it locally, here are the steps: Install flatpak and flatpak-builder using your normal package manager. Create a new directory and place the attached com.thedarkmod.DarkRadiant.yml inside of it. In the directory, run `git clone https://github.com/flathub/shared-modules.git`. Run `flatpak install org.freedesktop.Platform//21.08 org.freedesktop.Sdk//21.08`. Run `flatpak-builder --user --install --force-clean build-dir com.thedarkmod.DarkRadiant.yml`. Grab a coffee while you wait for DR and all its dependencies to compile. Launch DarkRadiant from your UI, or run `flatpak run com.thedarkmod.DarkRadiant`. Specifically, I'm interested in: Build issues: this should work pretty universally since it builds against a common SDK, but if the steps above don't work let me know. Runtime issues: this should also run universally, if it doesn't launch then something went wrong. If it runs but you come across a specific feature that doesn't work, let me know and I'll see if we can work around it. If anyone runs Wayland, please let me know either way whether it is working. If not, there are some permissions I should add. Known issues: The flatpak currently can't find the icon. It should just be a matter of getting the build file to copy it to the right place, so I can resolve that easily. This doesn't use flatpak's portals for file access. One of flatpak's advantages is its sandboxing features, but I currently have this app's permissions set to allow the whole filesystem (even so, technically there are some things flatpak still sandboxes away). It would take a some development to use portals for file dialog boxes, the big unknown to me is how to deal with accessing the game directory which could be anywhere. This doesn't prevent us from releasing, but it might be nice to look at in the future. If everything looks good, I'm planning to get this up on flathub this weekend. com.thedarkmod.DarkRadiant.yml
  13. Yes, that was the big one and I responded with more details. There were some other new asserts as well. I updated my flatpak build script with the new DR release this week and re-tested. I'll post the build script and some instructions soon for others to test. From what I can tell, the standard practice is to commit the build script to Flathub instead of the project repo. Once we agree everything looks good I can submit the PR at flathub unless@greebo would prefer to do it.
  14. Can you clarify which window you're referring to? I don't think I had this problem on Arch so I'm not sure where to look. wxWidgets 3.2 also now has a cmake build option, so that might make it easy to integrate with the DR buildsystem if we went this route.
  15. I figured out the crash, it seems we will have some things to fix in order to get DarkRadiant to work with the new(ish) wxwidgets 3.2 release. I didn't originally think wxwidgets was at fault since I got the same crash in my flatpak downgrading to 3.1.x. It wasn't until my main system upgraded to 3.2 that I went back and looked, and realized my previous working version was 3.0.5 (they do odd/even for unstable/stable releases). I built the flatpak against 3.0.5 and things seem to be working well now! I'll put the flatpak through its paces, especially around file loading/saving, and make sure there is nothing else broken. If everything looks good, there's just a couple odds and ends to clean up the permissions and this should be good to go. I'll also file issues for the things that broke when I tried wxwidgets 3.2. It's already the default in Arch, and since it's considered a stable release I'm sure it's going to end up everywhere else eventually too. Fortunately we can keep the flatpak on 3.0.5 as long as needed.
  16. I'm giving it a go this weekend, getting the flatpak to build and start up went surprisingly smoothly. It crashes when you try to do anything with a shader though, so this is where the last 10% is going to take 90% of the time...
  17. I've been using Fedora Kinoite (the KDE equivalent of Silverblue) on my laptop for the past couple months as an experiment, and Flatpak is its primary package manager. I've been looking for an excuse to learn about the Flatpak packaging process, so if nobody else gives it a go I'd be interested in trying to make a build in the near future.
  18. Well, you certainly work fast I was going to make sure everything worked as I hoped before dropping a patch into the bug tracker myself. I built the latest svn with your changes, plugged the new functions into my chest script, and it looks pretty good! https://streamable.com/18pngh The one thing I noticed is that calling addFrobPeer seems to highlight the peer even if it should be out of range, so we might need to come up with a better workaround than unconditionally calling peer->SetFrobbed(true); in that function.
  19. I actually went pretty far down this rabbit hole myself because I really wanted to have the whole chest simultaneously frobable (frob_peer'd) when closed but only the lid frobable when open. I came to the conclusion that if the AddFrobPeer and RemoveFrobPeer functions were exposed to scripting, it would be possible to achieve this. I haven't gotten around to actually implementing and testing it yet, but definitely want to before 2.11 starts stabilizing. My end goal was to make an entityDef where you supply the body and lid models along with the hinge location and out pops a fully-functional chest. The first iteration of this is actually already in my SW1 FM, and I hope to refine it more for my next one. This is definitely more of a look-forward approach rather than something that would improve existing FMs, though.
  20. Glad you enjoyed it! I did dial down the audio perception a fair amount - but what I noticed is that the AI will still make remarks about noises just as frequently, but they just won't get alerted as easily. I didn't look too much farther into it beyond that. That light is indeed from the lantern by the roof guard, it should have a subtle volumetric effect that helps you see its range if you have shadow maps enabled instead of stencil shadows. I remember the shadows themselves having some weirdness using that particular light too, which probably doesn't help things either.
  21. Think outside the box! More specifically:
  22. Happy to oblige, here's a little description:
  23. I think it comes down to the ability to tame a horse and its subsequent utility to humans. I remember a FM where a pagan had "spidey babies", it would be cool to see a mission where you played from that perspective. Anyways, I just didn't put much thought into what "team" the horses were on in my FM. The stated reason for no killing is to give you a clean getaway, so we'll just pretend that a dead body of any sort leaves clear evidence of misdeeds, whereas stolen goods are harder to investigate
  • Create New...