Search the Community

Ah, pity I wasn't reading the forums back in February. I'm fond of that game, along with Bugbear's other early title, Rally Trophy. I was never too good at FlatOut, but it was always a hoot to play.

In case anyone decides to pursue this further, here are a couple more references: https://discourse.gnome.org/t/pointer-warping-on-wayland/9197 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/158 Seems like this feature is also common in PCB design software. The "correct" solution would be to use Wayland's pointer locking interface and relative mouse events, which is essentially what the FreezePointer class accomplishes by continuously warping the pointer back to its original location. The complication is that the way it works now all goes through wxwidgets which then goes through gtk3 on Linux. To fully implement this, I think someone would have to: Create a platform-specific alternative to the cross-platform FreezePointer that we have now Make sure it's only called on Wayland, and only if the pointer locking API is available Work your way through the wxwidgets / gtk3 layers to get hold of the native wayland surface and pointer handles Reconcile the Wayland mouse events with the mouse events received by wxwidgets If someone was motivated enough to pick this up, it might make sense to try to build this in at the wxwidgets level and try to get it accepted there. It would help keep platform-specific code in the right place and also make a couple other projects happy.

Cannot reproduce on Ubuntu 22.04. Although the Entity List can take a long time to load in a large map (painterswife.pk4) at no point does it lock the system or capture the mouse.

I manually integrated and tested your PR. There is good news and bad news: The good news is that when running with the "GDK_BACKEND=x11" flag, using the clipper tool no longer breaks the window forcing me to restart DR afterward, the model / entity viewer no longer experiences the issue either. The bad news is that flag is still required, every viewport retains the problem if running Radiant in Wayland mode, we still have a big problem Linux users will increasingly run into as distros adopt it (KDE Plasma 6 now uses Wayland by default). So please integrate the PR if it doesn't break anything, it makes life much easier in the meantime! But this should remain open until either DR or WxWidgets or Wayland solve the core issue that exists when running in native mode.

When I open the entitylist DR freezes a while while loading the entitylist. On very large missions this can be very long. At that moment at first it seemed the whole system freezes, but I found that I can still use the rest of the system with the keyboard, but not with the mouse. System: Manjaro Linux xfce Version DR: 3.8 Flatpack install

This is my second time opening Dark Radiant in another computer. When i open it i see this: ( i don't know why the image appears blurry here ) So far i see the Grid and the Camera are not scaling well. Notice that i am using fractional scaling in Ubuntu (Resolution: 2560x1440 - Scale: 150% - Refresh Rate: 165.00 Hz) System info attached system_info.txt

Edited Yes, I play Linux version on steamdeck(

@uyvie are you using Linux? If so, there's a known problem with the peek function. See bug 6477.

Great little mission , what sets it apart from my point of view was the atmosphere, city design and the nice touch at the start of the mission. The only thing I miss (which I realize is a personal preference) is a bit of fog/mist in the city / garden, but other than that it was for me a near perfect mission albeit a bit limited. Played on 64bit Debian 'Trixie' with the 'darkmod' directory on NFS. (For some reason the first time i tried this mission darkmod failed to load the savegame. Only happened once, but still worth mentioning I think). Perhaps a bit off topic, but I wish the amazing city is being reused and made larger in another mission. Roaming the city (and it's roof tops) in another mission with a werewolf lurking around somewhere in the city would be a great second mission. Perhaps a second mission could be inspired by H.P. Lovecraft's 'the lurking fear' or 'the hound' if I may be so bold (and bald) as to say so.

Thanks for sharing your thoughts with me/us, @uyvie ! I am not familiar with the Steam Deck but it is good to know TDM works on portable devices. The TDM's autocommands.cfg file allows you to set hotkeys automatically (among other things) and you probably want to check how it works and see if you can set your preferred key bindings there. The Modpack includes an autocommands.cfg file with some examples. You definitely should see something and if you don't it is safe to say the peek does not work on the Steam Deck. The non-modded peek apparently does not work on Linux either so something is amiss somewhere

@snatcher I understand that when you feel your work doesn't live up to your goals that you don't want it out in the wild advertising your own perceived shortcomings but that leads to a troubling dilemma of authors who are never satisfied with their work offering fleeting access to their in-progress designs then rescinding them or allowing them to be lost. When I was a member of Doom3world forums, I would often see members do interesting experiments and sometimes that work would languish until someone new would examine it and pickup the torch. This seemed like a perfectly viable system until Doom3world was killed by spambots and countless projects and conceptual works were lost. I guess what I am trying to say is that mods don't need to be perfect to be valuable. If they contain some grain of a useable feature they might be adapted by mission authors in custom scenarios. They might offer instructive details that others trying to achieve the same results can examine. It would be great if known compelling works were kept somewhere safe other than via forum attachments and temporary file sharing sites. I suppose we used to collect such things in our internal SVN for safe keeping but even that isn't always viable. If folks would rather not post beta or incomplete mods to TDM's Moddb page, perhaps they would consider creating their own Moddb page or allow them to be added to my page for safe keeping. Please don't look at this as some sort of pressure campaign or anything. I fully understand anyone not willing to put their name next to something they aren't fully happy with. As a general proviso, ( if possible \ permitted ) I just want to prevent the loss of some valuable investigations and formative works. The end of Doom3world was a digital apocalypse similar to the death of photobucket. It is one of my greatest fears that TDM will become a digital memory with only the skeletons of old forum threads at the wayback archive site.

Yeah, that's two separate things going on. The Builders will eventually flip out if one of them is crushed by the elevator and they spot his corpse, but the other bug was legitimately a bug. The location separators between different areas have a sound loss associated with them so that a sound occurring on one side of a doorway is heard by AI at, say, 10 or 15 dB quieter. One of these was set to a negative sound loss, ie, it amplified the sound turning it into a huge megaphone that blasted noise all over the level. It wasn't just setting off the Builders but also all of the watchmen, the apartment landlord, and often the undead. To make it worse, the bug only had this effect on Windows. I'm a Linux user so it took me forever to figure out what was happening.

Congrats on the release! Remember to check ThiefGuild as well as the DarkFate forums (via Google Translate) for additional feedback.

Congrats on the release! Thanks for the great mission, I had a lot of fun. I played the mission with Linux and had no problems

I like how this has essentially become a Linux thread despite it not being the intended focus. I play around with Ubuntu MATE because I like Ubuntu and the MATE variant has an environment I prefer with a bunch of changes I like, a good compromise between old and new. That said, TDM behaves a bit oddly in Linux. For some reason in TDM it misses the occasional mouse click - if I happen to click fast enough there's a chance the event won't register. It seems to be something inherent to the Doom 3 engine in Linux - even in dhewm3, if I make a really fast click on the mouse it can sometimes ignore that mouse event and not fire the weapon. Generally you have to be really quick on the down/up event for it to happen, but it happens, it's reproducible and I can't just accept having to consciously be aware of my mouse behaviour and remembering to click long enough to guarantee the event is registered. I'm sure many won't notice this issue, but I'm pretty fussy about such things so it annoys me. This doesn't happen on anything else in Linux, just Doom3/TDM. Not surprisingly Windows doesn't have this issue, and it's a good example of the reasons why I don't bother moving entirely to Linux. I can't stand odd quirks like this and there's odd quirks EVERYWHERE in Linux. There's quirks aplenty in Windows too of course, but I'm used to them.

I spend 90% of my time on Linux Mint. I occasionally pop over to Windows 10 to check a few things or run some updates but Linux Mint is my home. TDM runs better under Mint than Windows for me but your mileage may vary. When running TDM in Linux, you must set FPS to "Uncapped Mode" in the Advanced settings, the old capped mode has terrible stuttering and performance under Linux ( even native Doom 3 has this issue ). You can set Max FPS to 60 if you are worried about any inconsistencies with game timing ( the only known issues are rare problems with audio behavior at really high FPS). Just don't use the native 60FPS capped mode, use Uncapped mode with a Max FPS value.

Switching systems is a longer term time and effort investment than a way to compile a program. Especially because I am willing to invest some time learning linux. Mint, probably. I don't have any strong preferences, I just want something reliable and low maintenance, where I can focus on work.

Changelog of 2.13 development: dev17042-10732 * Restored ability to create cvars dynamically, fixing bow in missions (5600). * Fixed issue where .cfg files were saved every frame (5600). * Added sys.getcvarf script event for getting float value of cvar (6530). * Extracted most of constants from weapon scripts into cvars (6530). dev17035-10724 * Support passing information between game and briefing/debriefing GUI via persistent info. Also changed start map & location selection, added on_mission_complete script callback (6509 thread). * New bumpmapped environment mapping is now default (6354). * New behavior of zero sound spawnarg is not default (6346). * Added sound for "charge post" model (6527). * Major refactoring of cvars system to simplify future changes (5600). Known issues: * Bow does not shoot in some missions (only in this dev build): thread dev17026-10712 * Nested subviews (mirrors, remotes, sky, etc.) now work properly (6434). * Added GUI debriefing state on mission success (6509 thread). * Sound argument override with zero now works properly under cvar (6346 thread). * Environment mapping is same on bumpy and non-bumpy surfaces under cvar (6354 thread). * Default console font size reduced to 5, added lower bound depending on resolution. * Added high-quality versions of panel_carved_rectangles (6515). * Added proper normal map for stainglass_saint_03 (6521). * Fixed DestroyDelay warning when closing objectives. * Fixed the only remaining non-threadsafe cvar (5600). * Minor optimization of depth shader. * Added cm_allocator debug cvar (6505). * Fixed r_lockView when compass is enabled. dev17008-10685 * Enabled shadow features specific to maps implementation (poll). * Auto-detect number of parallel threads to use in jobs system (6503). * Improved parallel images loading, parallelized sounds loading, optimized EAS (6503). * Major improvements in mission loading progress bar (6503). * Core missions are now stored uncompressed in assets SVN (6498). * Deleted a lot of old rendering code under useNewRenderPasses + some cleanup (6271). dev16996-10665 * Environment mapping supports texcoord transforms on bumpmap (6500). * Fully disabled shadows on translucent objects (6490). * Fixed dmap making almost axis-aligned visportals buggy (6480). * com_maxFps no longer quantizes by milliseconds on Windows 8+. * Now Uncapped FPS and Vsync are ON by default. * Supported Vsync control on Linux. * Added set of prototype materials (thread). * Fixes to Stone font to remove stray pixels (post). * Loot candlestick no longer toggle the candle when taken. * Optimized volumetric lights and shadows in the new Training Mission (4352). * Fixed frob_light_holder_toggle_light on entities with both skin_lit and skin_unlit. * Now combination lock supports non-door entities by activating them. * Added low-poly version of hedge model (6481). * Added tiling version of distant_cityscape_01 texture (6487). * Added missing editor image for geometric02_red_end_HD (6492). * Added building_facades/city_district decal material. * Fixed rendering with "r_useScissor 0" (6349). * Added r_lockView debug rendering cvar (thread). * Fixed regression in polygon trace model (5887). * Added a set of lampion light entityDefs.

As for distros -> Solus due to it being one of the few that works well with my hardware (does not offer the same ammount of packages most other distros do as they test each of them extensively for stability issues before they go into the package manager). Linux Mint seems to be pretty liked as well. OpenSuse probably the best for cross development. Manjaro should also be pretty good for gaming. Arch Linux for its massive package database (can be a bit hard to setup) Msys2 is based around the arch package manager so should be good for cross development to. Zorin OS if you want something close to windows (had a few rather annoying bugs with Lutris on it the last time i tried it though).

For peeps coming from Windows with no desire to invest a lot of time in learning Linux and the command line (you have to anyway to a certain extend) I would advise Linux mint if you want a fixed release or Manjaro if you want it rolling. Although @revelatorhad good experience with Solus. You can already start using it now in a multi-boot setting. So you are willing to invest time into figuring out some obscure way to get it working instead of invest time in a proper solution for the future. Why do you need to compile a Windows version, instead of a Linux version? I guess you could ask someone with Windows 10 to compile it for you?

Sure you can, it's called cross compilation. https://en.wikipedia.org/wiki/Cross_compiler In the Linux VM you'd install something like mingw-w64 and use that as the compiler, the output being a Windows exe. Of course the project would have to be set up to support it so I don't know if TDM is already set up for that.

None of this is relevant, though. I will be switching OS and experimenting at some point, but I have other priorities to worry about in my life and no willingness to be adding that on top right now. Meanwhile, this is what I have to work with, and I'm trying to find out if there's a way I could still compile DR with it. @OrbWeaver I could use virtual box to run a linux distro, but could I compile to a windows executable from it? (I presume I can't.)

I don't have a 32-bit OS but I am able to launch the 32-bit executable on Linux Mint 21.3. I think the story is similar to what I saw in 2.10. Lots of large maps produce AAS errors on launch but seem mostly functional. King of Diamonds seems to have lots of AI that are circling or having path finding issues. On a positive note, I was able to launch "The Painter's Wife", "Penny Dreadful 3", "Behind Closed Doors", " Shadows of Northdale 1", "Not an Ordinary Guest" basically all the largest maps and no loading errors were seen and all allowed in-game play. Oddly enough both Iris and The Painter's Wife have no AAS errors and no AI path-finding bugs even though they are the largest.

Given updates from Windows 7/8 to 10 and from 10 to 11 have been free, it seems like a low-impact financial decision on the part of the end user. I mean I'm tired of MS's BS and complications too and don't like a lot of the changes in newer versions of Windows, but I found workarounds and solutions to all the common issues and felt it was a better outcome than relying on EOL software that's going to be harder and harder to maintain especially when software/hardware vendors no longer support it. Still, if you find Linux is an option then it's better than a system that no longer runs anything without major issues. /sidetrack