Leaderboard

This kind of mechanic would break a ton of existing FMs. Some (I dare say even most) mappers often choose electric lamps so that they can't be extinguished or turned off, forcing the player to time their movements through the light. There are of course switchable electric lights, but that is up to the author on how they want to implement those. It would definitely be fun to see an FM implement this Splinter Cell-style mechanic, where the mapper has designed their map to function in such a way, but to add this as a core feature would break the gameplay of countless maps

I give you an extra star if you make a mission with a "connections" theme.

This sounds like something suitable for a mod (or an individual FM where the author desires this kind of mechanic), but not as a core gameplay feature.

Hi Ansome. Congrats on the release. It's a nice little mission. Hey all, if you like this fan mission, please consider logging in to ThiefGuild.com and leave a 1-10 rating. This will help to grab attention of others on the main page of the site. The Terrible Old Man page: https://www.thiefguild.com/fanmissions/64085/the-terrible-old-man Thanks! Konrad

It doesn't matter if you want to warp the pointer every frame or only once, in both cases GTK3 chose not to support it on Wayland. Here's the hack that Blender came up with: https://projects.blender.org/blender/blender/issues/77311 They found they had no choice but to render the cursor internally to get the intended behavior. Probably easier to do when you built your own widget toolkit like they did, rather than having to go through wxwidgets and GTK.

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.

Sounds like a good idea to me. I'm all for breaking glass, also windows (the "penalty" is that it should be very loud to A.I. So, a thing you surely will only do very rarely.). I think this will take a lot of consideration on the mapper side, though. Amount of arrows in the starting gear and in the mission itself, consideration where to put destructable lamps, and where to avoid them. Not to mention that I don't know how much effort has to be put in the technical side (making the lamp destructable and killing the light it sheds). Thinking about it, I think it kinda defeats the "stealth" element, doesn't it? Why would you make loads of noise and possible alert half the A.I. in a mission, for pretty little benefit? A thief surely will do everything to avoid that kind of noise and attention.

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.

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

I always loved the "connections" theme and I think it is very fitting to celebrate TDM. It's a shame we can't have 4 polls per thread because then my proposal would be to have free-for-all with a "connections"-rating added that evaluates how well the mission integrates into or expands upon the existing lore.

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.

@nbohr1more another idea: there are several abandoned WIPs. Maybe doing some sort of contest with them?

I like proposal 2 because I have thought of doing that many times, but realistically, just allowing people to do whatever they want seems less restrictive, so more people might join in. Besides, if someone still wants to reinterpret a T1 or T3 mission, well, nobody is stopping them. Perhaps "include a nod to a classic Thief/TDM map somewhere in your mission" could be a milder requirement. Campaigns just take too much time to make.

In principle I like the idea of community campaign building. But the official campaign itself never really captured my imagination, not to mention it'd be hard for people to have an idea of where it's going, much less making it cohere. I scripted a Dark Mod campaign meant to introduce the districts, factions, and lore that does capture my imagination. But I'm not in any real position to ask people to build for it, and also there's still the problem that people may have different visions for it that may not cohere well. As for the "connecting mission", that might be interesting... But I'd reframe it a little, not that it has to be connecting per se, but you know, a hero or even another character from some FM in an adjacent setting alongside (or before or after) an existing FM, kind of like what Rozencranz and Guildenstern did for Hamlet, if you know about that. I think it's better to have it more open ended how an author wants to build off an existing FM than only connecting two FMs per se. That might be a really interesting theme to see play out.

Since there were objections to it, I went with the two most generic options with popular support. I added horror to the poll since that's always popular here.

Yes, the stim/response system allows for this kind of thing. Easy enough to emit a custom stim around the lantern and put a response on all photophobic AIs to that stim. The response script would check whether the photophobic AI is within the lightbeam, then call a flee function on it. The main problem is that the flee function is unreliable if the AI is already busy with something else.