Jump to content
The Dark Mod Forums


  • Posts

  • Joined

  • Days Won


Everything posted by greebo

  1. Some include seems to be missing, I'll try and fix it.
  2. Thanks, I've added libeigen3-dev to that section. libgtest-dev should already take care of the gtest dependency, but this didn't work for you it seems?
  3. Sync or pull doesn't restore any files that have been locally deleted. You need to use "Git > Revert...". (Or alternatively Git > Checkout "master" (with force) or Git > Reset (hard) to restore your working copy to a committed revision.) The repo-browser is ok to restore specific files manually, but Git > Revert is better.
  4. The file should be there in radiantcore/patch/PatchConstants.h. Can you confirm?
  5. Please open a bugtracker entry for this, I assume the parser needs to be adjusted to handle the rect-100. It's entirely possible that this is a regression of some sort.
  6. I don't think that the file has problematic code in it, but I can't prove it to you. I'm afraid these positive detections happen every now and then, something is triggering the scanners. Uploading the sound.dll file to the online scan services shows this: https://www.virustotal.com/gui/file/7fe3607c7dd33cfee7cef53d0ccbdd3142a9f8860cfe24d639c4be043136c4dc It confirms that BitDefender doesn't like the file, for what it's worth. I could look into creating a checksum of the uploaded files next time I create a release, but this doesn't really add much value other than you're being able to prove that the file's the same as the original on my system. If the sound.dll gets infected on my machine while I build the release, the checksum would still be matching. One could make sure and compile DR from source code, to rule out anyone messed with the released files on my computer or on Github.
  7. I can confirm the problem with the vanilla D3 resources, the parser is running into a bug in the pak0005.pk4/materials/patd.mtr file. Issue: https://bugs.thedarkmod.com/view.php?id=6108
  8. There is a lightscale setting in the .game file, which can be used to make lights brighter or darker in DR's render view. Not sure how this could help when exporting scenes to other engines, but that's about the only thing we have here to adjust light brightness globally, other than changing every light in the scene. See for example doom3.game, Line 133: <lightScale>2</lightScale>
  9. Thank you. It might be possible that the material parser thread is failing on some declaration. I'm going to try if it does the same on my old D3 installation, I just have to track down the PAK files.
  10. Can you maybe try launching DR from the console to see if there's any output? The darkradiant.log file in ~/.cache/ might also give me some insight. Can you paste the log contents after it crashed, please?
  11. The installer (I think) is overwriting everything in the installation directory, as far as I know, it doesn't remove any previous installation. But I might be wrong on that, since I rarely use the installer myself on my development machine. You don't need to backup your user settings, since version 3.0 every new minor release (3.x) is using its own separate settings folder and is not overwriting settings from previous versions anymore.
  12. I installed Manjaro XFCE, and scrolling with the mousewheel is moving the camera view as expected, with and without freelook mode. That's in a virtual machine, it is compiled against wxWidgets 3.2.0.
  13. DarkRadiant 3.3.0 is ready for download. What's new: Feature: Remove menu options which are not applicable to current game Feature: Grey-out menu entries that are not applicable Feature: FX Declaration Parsing Support Feature: FX Chooser Feature: Renderer now takes "translucent" keyword into account Fixed: Lighting Mode Renderer draws hidden lights Fixed: Loading map results in "Real Hard DarkRadiant Failure" exception Fixed: Crash when trying to set default mouse or keyboard bindings Fixed: Unit Tests intermittently get stuck on Github runner Fixed: xmlutil thread safety problems Fixed: Some materials aren't displayed correctly Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/3.3.0 and of course linked from the website https://www.darkradiant.net Thanks to all the awesome people who keep using DarkRadiant to create Fan Missions - they are the main reason for me to keep going. Please report any bugs or feature requests here in these forums, following these guidelines: Bugs (including steps for reproduction) can go directly on the tracker. When unsure about a bug/issue, feel free to ask. If you run into a crash, please record a crashdump: Crashdump Instructions Feature requests should be suggested (and possibly discussed) here in these forums before they may be added to the tracker. The list of changes can be found on the our bugtracker changelog. Have fun mapping!
  14. I thought the flatpak is using wxWidgets 3.2.0? But as you had the problem with DR 3.0.0 too, I assume it's not caused by wx3.2. I'll check it out as soon as I get a chance.
  15. Yes, it's working normally, for me at least. There's no key binding necessary for that either, it's hard-coded to react to the mouse wheel.
  16. Ok. Testing my existing Arch VM with wxWidgets 3.2.0, mouse wheel is working. Maybe it's something related to XFCE, I'll try to install that version.
  17. Which Linux distro are we talking about? I can try to repro it in a virtual machine.
  18. No luck with this dump, but in this case I think the log file should show something that lead to the crash.
  19. I've tried to look for similar reports like this, but there's nothing that sounds like the problem here. That might also be due to GLCanvas not being used that much (and wxWidgets 3.2.0 itself is not that widespread yet to begin with). At this point I can only speculate, since I haven't access to any AMD hardware at the moment. I can offer to look at a crashdump you produce with DR 3.0.0, and see if its trail is also leading to the AMD drivers.
  20. @HMartThis is where it crashes: atio6axx.dll!00007ffe5c79cc74() Unknown atig6pxx.dll!00007ffe9665c18c() Unknown opengl32.dll!pgldrvLoadAndAllocDriverInfo() Unknown opengl32.dll!LoadAvailableDrivers() Unknown opengl32.dll!__DescribePrimaryPixelFormat() Unknown opengl32.dll!wglNumHardwareFormats() Unknown opengl32.dll!wglSetPixelFormat() Unknown gdi32full.dll!SetPixelFormat() Unknown wxmsw32u_gl_vc14x_x64.dll!wxGLCanvas::FindMatchingPixelFormat(const wxGLAttributes & dispAttrs, tagPIXELFORMATDESCRIPTOR * ppfd) Line 1068 C++ wxmsw32u_gl_vc14x_x64.dll!wxGLCanvas::Create(wxWindow * parent, ...) Line 769 C++ wxmsw32u_gl_vc14x_x64.dll!wxGLCanvas::Create(wxWindow * parent, int id, ...) Line 750 C++ wxmsw32u_gl_vc14x_x64.dll!wxGLCanvas::wxGLCanvas(wxWindow * ...) Line 690 C++ The code is trying to construct a render window, it's heading off somewhere into the ATI drivers where it dies. It appears that this is something that changed between DR 3.2.0 and DR 3.0.0, at least for you? DarkRadiant 3.2.0 uses the newly released wxWidgets 3.2.0, which seems to be the only relevant change here to me. The GLWidget code hasn't been changed at all for a couple of releases, so maybe it is a problem with wxWidgets 3.2.0 constructing the GLCanvas in a different way than before.
  21. Yes, I can upload them to darkradiant.net, no problem. If you want to place them yourself, you can clone https://github.com/codereader/codereader.github.io and create a Pull Request with the screenshots you want to have added. There's already an images/screenshots/ directory in that repo.
  22. It says I need to get permission to download that file, please.
  • Create New...