Search the Community

My recent experience makes clear that the mouse can be moved, but no click is possible. After Entity list is loaded, everything works fine again.

Mouse look is essential so no. We should use whatever behind-the-scenes solution of messing with the pointer will work... once Wayland or WxWidgets or GTK3 will offer one, it's kind of on them that they haven't up to this point. Until then Jonri's PR works by forcing the X11 backend, which isn't a real solution but in practice solves everything for now. Here's a modified snippet of what I did in PyGame which works. Obviously this code has no effect, just an example to show what works in my project, just in case it's a similar situation here: Maybe Wayland expects us to hide the mouse pointer at a core level before it allows locking, and the reason it doesn't work is DR only hides it visually at top level? pygame.mouse.set_visible(False) x, y = pygame.mouse.get_pos() pygame.mouse.set_pos((x, y)) pygame.mouse.set_visible(True)

Oh well, I guess that rules out any kind of mouse grabbing behaviour that will work on Wayland desktops. I'm not sure what the alternative is. Some kind of on-screen widget that you can click and drag to rotate the camera, like a sort of circular scroll-bar?

I notice that what Blender does is not lock or hide the mouse cursor, but allows it to move, then snaps it back to the other side of the window so you can drag infinitely in one direction. I.e. if you are dragging to the left, when the cursor reaches the left-hand window edge, it immediately re-appears at the right-hand window edge and continues moving to the left. I wonder if re-writing the code to use the Blender approach would solve the problem? Perhaps the back-end code can handle instantaneously changing the mouse pointer position more reliably than trying to lock it in place.

There might be another way, or at least it's what I thought of as a non-developer: Use a different way to transform mouse movement into camera rotation or viewport offset. Is there no alternative to calculating the distance from the pointer to the window center before resetting the pointer to the middle? There must be other mouse look implementations that could work. Most obvious alternative: We can detect how much the pointer moved on the screen compared not to the center, but to its previous position wherever that may be. While of course still trying to lock it in the middle, but if that fails at least it doesn't cause the view to go crazy: The only issue then will be the cursor reaching the screen edge and having to be re-engaged so you can keep scrolling in that direction, which is also a big annoyance but comparatively less bad and not as noticeable unless you do long-range movements in one go. Any reason why we couldn't give this option a try?

Yes, I probably should have been more clear. This fixes everything when running on XWayland (which emulates X the best it can but must still ultimately play by Wayland's rules). Last time I checked, GTK3 was not planning to support mouse pointer warping at all on Wayland and left the function as a no-op in the Wayland version. It might be simplest for us to figure out an easy way to automatically force the x11 backend to be used. Wayland is increasingly becoming the default, but XWayland is not going away anytime soon.

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.

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

I've figured it out! There are 2 parts: 1. The FreezePointer class has a mismatch, it blanks the cursor on the top-level window but does the pointer locking on whatever particular sub-window (i.e. the 2D view widget) calls for it. The cursor has to be explicitly blanked on the same widget that locks the pointer. 2. The clipper tool updates the cursor whenever the mouse moves, even if it's in the middle of dragging and should be hidden. It was easy enough to guard against changing the cursor while the mouse capture is active. This also fixes the same issue that was happening in the 3D view of the model viewer (but not on the main 3D view). I'll submit a PR shortly, @greebo or others will need to test this change on Windows to make sure it doesn't do any harm there. EDIT: The PR is here: https://github.com/codereader/DarkRadiant/pull/37

Yeah the problem is that the entity list makes DR freeze for a couple of minutes with some extremelly large maps. During the freeze it takes over the mouse, so you can't use it in other applications. With the keyboard I can still do everything outside DR. Also I cannot copypaste text in the searchbox in the entity list. That gives an error.

Oh my gosh, thank you for this! After reading what you just said, I realized I've in fact noticed the same thing in another program, but assumed it must be something completely unrelated: I've been working on creasing a CPU based voxel raytracing engine in Python, for which I settled with using PyGame. When the time came to implement first person camera control using the mouse, I noticed it did not work initially... however if I told my code to hide the mouse pointer first, locking it in the center of the window started working. It must be the same thing here in some form, Wayland likely has some very particular expectation on how the mouse pointer must be set in order to be locked. In fact just a few days ago, I tried a virtual worlds software called Vircadia / Overte again to see how it's been progressing. I activated mouse look mode and guess what happened: The exact same behavior of the view spinning endlessly as the cursor drifts away from the center due to lack of locking. So it's clearly happening to many things and not just GTK / WxWidgets related... but no all of them, most games (including TDM itself) work perfectly fine and mouse control never breaks. I'll try your solution later and mention the results, likely tomorrow as it's late now and I need to head off. If it works that would be incredible! At least as a workaround, we could simply not hide the cursor on Wayland, which will look ugly but at least allow using DR without needing hacks until they can solve whatever is happening on their end. Also Plasma 6 was just released, my distribution (Manjaro) will likely be getting it a couple of weeks or at most months from now. I'm curious how that will affect it: Hopefully it won't make the issue worse, but just in case I'd be happy to have a solution in Radiant before then.

I revisited this issue and might have had a breakthrough. I noticed that when using the clipper my cursor wasn't changing, and afterwards when the cursor was no longer hidden when the dragging problem starts happening. If I take out the code that is supposed to change the mouse cursor when activating the clipper, the drag behavior remains correct during and after using the clipper tool. If I remember correctly from last time I went down this rabbit hole, Wayland has restrictions on pointer locking and I think it was only allowed while the pointer is hidden. I'm guessing something with changing the cursor is failing and then it doesn't get hidden before the pointer lock happens, causing Wayland to reject the pointer lock request. And when the pointer doesn't get locked, the math to calculate the drag amount goes all wonky. @MirceaKitsuneor others, if you'd like to try a quick and dirty workaround, find the void OrthoView::setCursorType(CursorType type) function and put a return statement on the first line so it doesn't actually change the cursor. I'll see if I can figure out what's actually going wrong when setting the cursors so we can make a proper fix.

You cheeky nandos. XD Have you not considered using the screen? She walks behind it, there is a shadow of her lifting her arms, the light flickers - POOF - model swap, she steps out clothed. Although, there had to be something preventing the player from walking behind the screen. I liked how you handled her undressing to begin with. What startled me earlier tho, along with creepy music while the Builder's priest sings in the background, is the dress mannequin... with human hands.

That "fall" delay was by design. Because there is no animation available to show her actually re-dressing from the trunk of clothing, so instead I wanted you to have to imagine it. Rather than actually catching up with her and seeing the instant body swap.

Oh no, that's not how the Steam Deck works. On a computer, each key is programmed to do only one thing.In any game, when you press "F", the system will understand that the "F" key was pressed. But on the Steam Deck, I have to assign functions to each key myself. For example, I can make the "A" button act as "space" and the left trigger as "right-click". That's why I'm saying that opening the console on the Steam Deck is difficult. Even though it has a lot of buttons, I have to temporarily program three keys for functions that are not really used.

@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.

There is nothing to upload anywhere unless the ask is to create an AutoHotKey executable in which case false positives would easily become my new nightmare. Thanks but I'll pass! This one truly is a proof of concept. I have been using this hack (with its shortcomings) since @Obsttorte and I first worked on it and I am convinced this could become a great project for an eager developer. Controlling the speed with the mouse-wheel not only feels natural but it would free us from the 3-speed limit and make some keys obsolete. An all-around improvement for those that may (optionally) use it.

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

I thought it would be convenient to collect in one place a list of all mods\addons\improvements created by the community for TDM. After surfing the entire forum I collected the following list of mods, and I present to you their list below. I will be glad if you correct me and provide any other links to mods that I may have missed. Graphic mods Fresnel Mod (MoDB link) Flame Glare Mod (MoDB link) ModPacks Unofficial Patch (MoDB link) TDM Modpack (MoDB link) (with the possibility of separate installation) Gameplay mods Augmentation Mod Wearable disguises Player Lamp (beta) Adjust player speed with mouse wheel Stealth Statistics Tool & Loot Stealth Stat (MoDB link) Textures TDM Texture Mod Small UI tweaks Reflections to all materials containing specular maps Sounds New Footstep sounds Collection of adjusted sounds by Anton Thiefier Sounds Blackjack Draw/Sheath SFX (MoDB link)

Hi i never did a beta, what specs do you need? exept time to spend i have a rysen7 and a keyboard and a mouse

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.

Welcome to the forums Ansome! And congrats on making it to beta phase!

"...to a robber whose soul is in his profession, there is a lure about a very old and feeble man who pays for his few necessities with Spanish gold." Good day, TDM community! I'm Ansome, a long-time forums lurker, and I'm here to recruit beta testers for my first FM: "The Terrible Old Man", based on H.P. Lovecraft's short story of the same name. This is a short (30-45 minute), story-driven FM with plenty of readables and a gloomy atmosphere. Do keep in mind that this is a more linear FM than you may be used to as it was deemed necessary for the purposes of the story's pacing. Regardless, the player does still have a degree of freedom in tackling challenges in the latter half of the FM. If this sounds interesting to you, please head over to the beta testing thread I will be posting shortly. Thank you!

New script for mappers: my flavour of a fog density fading script. To add this to your FM, add the line "thread FogIntensityLoop();" to your map's void main() function (see the example in fogfade.script) and set "fog_fade" "1" on each foglight to enable script control of it. Set "fog_intensity_multiplier" on each info_location entity to change how thick the fog is in that location (practically speaking it's a multiplier for visibility distance). Lastly, "fog_fade_speed" on each foglight determines how quickly it will change its density. The speed scales with the current value of shaderParm3, using shaderParm3 = 1000 as a baseline. So i.e. if shaderParm is currently at 1/10th of 1000, then fade speed will be 1/10th as fast. Differences to Obsttorte's script: https://forums.thedarkmod.com/index.php?/topic/14394-apples-and-peaches-obsttortes-mapping-and-scripting-thread/&do=findComment&comment=310436 my script uses fog lights you created, rather than creating one for you. Obsttorte's script will delete the foglight if entering a fogfree zone and recreate it later more than one fog light can be controlled (however, no per-fog-light level of control) adding this to the map requires adding a line to your void main() script, rather than adding an info_locations_settings entity with a custom scriptobject spawnarg in my script, mappers set a multiplier of fog visibility distance (shaderParm3), while in Obsttorte's script a "fog_density" spawnarg is used as an alternative to shaderParm3 smaller and less compactly written script fogfade.scriptfogfade.map

I'm thinking along the same lines. For the issue in the bugtracker here the solution is described as: To me it would make more sense to swap the two triggers for bodies. That way * "Frob" would mean "grab and hold object in front of you", and "Frob" again would mean "release" consistently for all three objects. * "Hold frob" would mean "interact" (="shoulder"/"unshoulder", "extinguish", "eat") consistently for all objects. And if "unshoulder" required "Hold frob" it would reduce the risk of unintentionally un-shouldering bodies when trying to operate doors. I may be missing something here...