Jump to content
The Dark Mod Forums


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by jonri

  1. I just updated the flatpak, so it should hit flathub in a little bit.
  2. I've been trying to finish off a handful of projects and experiments I had started a while ago, and remembered that I ran into a roadblock. I was trying to build some custom entities with slightly complex behavior and had wanted to access a def_attach'd entity from the script on its parent object. These script functions sounded pretty close: scriptEvent entity getAttachment(string attName); Get the attached entity with the given attachment name Will be NULL if the name is invalid or if the entity no longer exists Spawnclasses responding to this event: idActor scriptEvent entity getAttachmentInd(float index); Get the attached entity at the given index. Will be NULL if the index is invalid or the entity no longer exists index: starts at 0 Spawnclasses responding to this event: idActor scriptEvent float getNumAttachments(); Return the number of attachments on an AI. Used to iterate through the attachments if desired. Spawnclasses responding to this event: idActor But as you can see, they only apply to idActors. I dug into the source code and found that the code that handles all 3 of these functions just calls into the idEntity base class to retrieve the attachment, and there does not appear to be anything specific to idActor with those. As such, I'm fairly certain that these script events could be moved to idEntity without breaking any existing usages (assuming script event inheritance works as expected). Are there any downsides to doing this? I can create a bugtracker entry and/or provide a patch if there are no objections.
  3. I wonder if this explains https://bugs.thedarkmod.com/view.php?id=6165 which I was never able to get anywhere with. When I get a chance I'll make a build with that fix and see what happens.
  4. DR uses wxGTK on Linux, so I'd expect anything that works for other GTK applications would do the trick. I'm not set up to try it myself, but it looks like you might try setting the GDK_BACKEND=x11 environment variable.
  5. Can you convince it to run under xwayland? A proper fix is preferred, of course, but this might make it usable in the meantime.
  6. Flatpak is updated and should show up on Flathub in a bit.
  7. I created a bug tracker ticket for this issue: https://bugs.thedarkmod.com/view.php?id=6165 I made a build with debug symbols on my desktop, and oddly enough darkradiant exits entirely rather than crashing with a SIGTRAP when I try to debug it. I'll keep investigating...
  8. I updated the flatpak earlier today and the new version is now available on Flathub. Unforunately the crash when opening certain dialogs is still present for me, but hopefully I'll have more time to look into that this week.
  9. A bit of a guess here, but have you watched your memory usage while this happens? Those symptoms sound a bit like you're running out of RAM and swapping. Could be video RAM too, maybe...
  10. I don't have enough symbol information to get the value of the variables, so I won't be able to help out there until I get a chance to make a debug build. I tried with G_MESSAGES_DEBUG=all and didn't get anything on the console either.
  11. Launching a new 2D view, TexTool, or Light window all cause a crash for me as well in the Flatpak version (using Fedora and AMD). I'd guess junk rendering or the crash might both stem from the same underlying issue. Interestingly, the Light window actually displays and the area where you choose your material says "Loading Resources" before it stops. Running it in GDB yields a SIGTRAP. Here's the stack trace: Hopefully this helps somewhat; I won't get a chance to run it in a debugger until next week if needed.
  12. I'm afraid to ask which kind of "coke" would be required for this...
  13. I've updated the flatpak (and cherry-picked the above post-release Linux fix). It should show up online once Flathub's build scripts pick it up and do their thing.
  14. I took a stab at it, here's what I did in case you want to try to improve it some more. In Gimp I used scaling with NoHalo interpolation, and then I adjusted the contrast to +30.
  15. Did you file a bug report yet? I noticed that I can drag the layers, but dropping them doesn't do anything.
  16. I like this approach, it seems like it would be easy to have some logic in DR that if the game path isn't set and that directory exists, then set it by default. This would keep it from affecting anyone that isn't using the flatpak version, and for anyone who just installs both flatpaks things will already be set up with the right paths. Locking down the filesystem for DR may be a minor inconvenience to anyone who keeps multiple TDM installs around (dev builds, etc), but in this case Flatseal provides an easy, one time solution to open up full access (I've already documented the reverse in the wiki). Your 128px icon looks fine to me, seems to be from the same original source as the 48px icon. Does it look ok if you derive a 64px icon from it too?
  17. @Ludvig nice to see you're getting this ready for Flathub! Since I just went through this with DarkRadiant, I took a look at your manifest to see if there's anything that will trip up the process: Comments are fine, but they don't like commented out lines so you'll want to clean those up before submitting. They require a 64x64 and a 128x128 icon file, and the one you're providing is 48x48. You might need to go hunting in the assets or on the wiki, or see if someone here has a suitable icon lying around. I'm not sure about having --socket=wayland and --socket=x11 together. If we don't have explicit wayland support then --socket=x11 should be sufficient on its own; if we do, then I think you use --socket=wayland with --socket=x11-fallback. You have --talk-name=org.freedesktop.Notifications but I don't remember anything in TDM or the installer that would make use of it. If there is, feel free to correct me You'll need a flathub.json file that tells their build system which CPU architectures to support or skip. Without this, I think it will try to make an ARM package too. Once you've got an appstream file I'll gladly check it over for you too.
  18. I haven't, but I'll certainly try it out! Ordinarily Flatpak packages can't get to each other's files, but if it can be installed to an agreed-upon location outside the sandbox we should be able to make this work.
  19. @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.
  20. The Flathub package has been updated, it should be available once their system finishes building it.
  21. 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.
  22. 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.
  • Create New...