Search the Community

Thanks, that would be one of the issues down. Could you also make it so when both creep and run are set to toggle, toggling one on also turns the other off? This way whenever you come out of running or creeping, you know you'll be back to walking instead of jumping straight to the other mode. Currently creeping blocks running entirely, you need to manually turn it off before the run toggle works at all which can be inconvenient if want to just jump to the mode of the key you pressed. I've always wondered if the HUD and menu graphics could be modernized to be a little more high resolution: We could surely have a nicer looking lightgem, one that actually looks more like a gem and maybe makes light level even clearer. I've tinkered with the HUD and could technically look at it, but I'm working on several projects now and don't even know for sure what changes would be accepted in vanilla. Hope someone else can provide more feedback and maybe take a look! Can't say I'm a big fan of the current crouch indicator in general: It's two decorations on the side of the lightgem that stretch to the bottom of the screen, makes the point clear but looks kind of ugly. I can't readily think of anything else that wouldn't be distracting though. Normally we could use an icon indicating posture as a silhouette of the person, but that might be too large and distracting and modern looking... the later issue can be fixed by making it more like a symbol carved into a rune.

I am going to sort-of reveal that this is loosely like the nature of my upcoming mission. I noted it here when JackFarmer asked about things that are coming along in this post: https://forums.thedarkmod.com/index.php?/profile/37993-jackfarmer/&status=3943&type=status It too is a builder church. The player is requested by a hopefully famous character in another mission to handle some business that is affecting the congregation. I am looking to invoke some info and history laid down in other missions as a hook story.

Yep I assumed it was all 16:9. The code can be modified so referenceAspect is no longer const. It could use 16:9 as default and for other aspect ratios perhaps forceAspectWidth/Height can be set on those screens and the referenceAspect would be calculated based on those values. I agree it would be nice to drop special images for different aspect ratios. I was able to change the spyglass & keyhole images to always use the 16:9 image and it worked nicely. The issue is just finding a way to have the black background continue outside the letterbox area so the game viewport is not leaking through. With the fullscreen changes I was hoping to find some general way of correcting the UI without having to change the content too much, ideally so mission creators wouldn't have to go back and change their content to support different aspect ratios. I did however hit a roadblock because it seems that loading screens and briefing screens are copypasted for every mission so this content may need to be patched anyway. If a whole pass on the GUI files is necessary anyway I would skip the fullscreen hack and aspectAware parameter and go with something else that makes sense.

Maybe you can fix the font pixel issue please? Because you already know much more about it than me ;)!

Yes, this issue definitely won't be forgotten.

I created the page: https://wiki.thedarkmod.com/index.php?title=Lightgem In the source I placed the following text: <!-- Page text made by forum user Fiver: https://forums.thedarkmod.com/index.php?/topic/22327-how-can-i-create-an-account-on-the-tdm-wiki/&do=findComment&comment=491145 --> Personally I think the page isn't really necessary because the info is already present under HUD.

Not quite the same issue and slightly less funny, but had some more fun testing how guards react in real situations. Somehow he doesn't notice the 4 people he's guarding flee the room in terror screaming about an intruder. If his reaction couldn't be chugged to AI errors, you'd think he hates the people he's guarding and pretended to see nothing just to be smug

Yes: That's normal and intended when notarget is enabled, it's funny to play that way when you want an easy and abnormal experience in a run. In this case I didn't use any of the cheats, this all happens by default. Posted this on the bug tracker just now as it seems like something to be aware of. https://bugs.thedarkmod.com/view.php?id=6436 The core issue appears to be that AI doesn't actually connect attacks to the attacker... hitting a guard does put them in alert, but doesn't also make them aware of the player's presence like seeing you does. A similar result can be observed if you shoot an arrow at guards from a distance: The guard never thinks of running to the location the arrow was shot from, only searching the area right in front of him which no self aware person would do.

In the first post of the other topic Geep proposed: Then Stgatilov's answer: But I think applying subtitles in different languages shouldn't be too hard I would think, but I don't know how the current translation system works. The engine should apply the correct subtitles based on the applied language setting, this doesn't need a whole new language system I think. Not sure who's going to write those subtitles though. I can only do Dutch and English and nobody needs Dutch I think. I suggest further discussion of this to take place in topic https://forums.thedarkmod.com/index.php?/topic/21741-subtitles-possibilities-beyond-211/

With that many maps what a lot of people are going to want is curation and quality control. If you want to know why Thief FMs are still pulling more eyes, that would be my guess. It's not even that the quality of the best Thief FMs are better than ours (IMO they are not), or that they have better tools for recommending them. The big advantage is that Thief has an popular and established lexicon for having those discussions. People know their expectations and can communicate them; and when they communicate their preferences they can reasonably expect to have them understood and satisfied. An excessive example (not biographical but a plausible hypothetical): The relevant point is that playing TDM is a major investment to the biggest demographic of people that might be interested in branching out. It seems like some people here don't recognize that dynamic. Some of us think that there are a bunch of quirky or vestigial irregularities in TDM that don't add much value to the established community and could be homogenized to to lower that barrier to Thief transplants. We are confused why you guys see it as so threatening. Personally I still feel like I haven't got a single straight answer. All that said on this specific mantling issue, I am actually sympathetic to the reactionaries. I love that the new speed was calibrated off of parkour videos. That was super clever. However the opposition has a point that our play characters are usually hauling like 25 kg of loot, gear, and body armor during a typical mission, judging by the in game models. And they are generally not in any big hurry. It it were me I would split the difference between the old and new speeds, or maybe go 70-30 in favor of parkour.

Yeah it would be cool to see some more detailed statistics and it’s a shame they aren’t really captured. Since we are talking about fan mission platforms, where players also make the content for the game, I feel like the best thing we’ve got is you can look at the number of content releases for the games. Keep in mind the graph counts campaigns as single missions - so for example NHAT and TBP both count as 1 mission. A good year for TDM has has approaching maybe 50% - mostly we’re 25-30%. https://www.ttlg.com/forums/showthread.php?t=152494 You could also look at the number of ratings thief missions get on https://www.thiefguild.com/ vs TDM ones, but that is pretty iffy in that you could chalk that up to more awareness of the site in the thief community than TDM Out of curiosity is there a reason a thief player can’t be a new player? I kind of think a player is a player and new players would be ones who are playing the dark mod who weren't? Is there disagreement the base of players most likely to pick up the game are fans of the thief games? They are certainly the most fruitful place to find feedback on the game beyond the sphere of this forum that I have seen. When we were trying to finish up SLL there was a lot of discussion on the forums about how long it had been since there was a release for the game. I am thankful that the stats show at least some stability over the years in terms of releases for TDM, but the trend for all of the games is decline. Not doing anything is a valid response if that’s what the devs want to do - it is not possible to provide evidence that any effort will slow that inertia. As a player and content maker I would just prefer trying to find feedback where it is offered from players who were willing to try the game but ultimately could not engage with it and see if there is anything that can be done within reason to ease them into the game. The game has a lot to offer imo. All those players are potential contributors - contributions in turn attract players - it’d be nice to see the cycle go on as long as it can.

In which way do you think that the changes made to mantling and leaning will "encourage new players"? I don't see anything about the old systems which would be a hindrance, or a discourage for people getting into the game. Anyway, my main issue with this and other things which have been pushed here quite aggressively lately is something different. But, that's something the core team of the mod should address (and know), and is probably not something to discuss here in public (and not up to me anyway). I'm in good faith that it will be addressed, because, I don't think it can go on much longer like this.

As I mentioned in my post, if the this is even an issue the devs modeled it off of actual human capabilities. ie watching actual people perform the task. Whose capabilities are you measuring that feeling against? Your own? That of a season thief? It really doesn’t matter, they are your perceptions of the game. That should be valid enough without worrying if your subjective feelings about how the game should feel meet “reality”. The game is inherently not realistic, nor are any of the games in the pantheon of immersive sims. That is another topic entirely though. Do you have an opinion on the default mantle roll setting?

Liking this mission, but I have an issue - Thanks!

Your latest design is OK, but doesn't touch on several aspects that I addressed in my design: ring lower edge no longer crushing the top of 1st line text excess backing field below text 2nd line trimmed, to allow space for (1) backing field behind ring, as I believe requested by snatcher & datiswous I could further discuss this and the narrowing issue, where views differ, but I'm more than OK to "switch from background boxes to outline around text", as you suggest. There is still leaves improvements to ring vertical spacing - a la (1) - and not have the ring interior be transparent (probably just opaque) - similar in spirit to (3). And of course, actually implementing it in the beta. snatcher found 8-fold to be visually best. The minor artifacting with the scaled Stone font (e.g, a wisp to the left of a capital T) will become more prominent with drop shadows. But that could be addressed in a font update to include native Stone 12pt in 2.13

I have been quite careful to ensure that making the subtitles narrower for barks (but not story verbosity) is not potentially breaking. Examples of this treatment have been included in all my more recent testSubtitles... releases. Yes, this is "crucial" for me. Regarding the padding issue, to restate: TDM 2.11 and on through the 2.12 released beta version use a subtitle right text padding of 20 px. While some padding is necessary, this does a poor job of centering the text visually in the backing field. This is obvious with a short bark. My redo of this, with padding of 7.5px on both sides, fixes it, while I believe not causing any problems for word wrap of subtitles with the given compressed font & scale. I'm provided several versions above of this fix (code hidden as Spoiler). Most recently, this was with snatcher's suggested tabbed location ring and vertically-tighter backing field, here This version will also be incorporated into testSubtitlesDrunk, to be released tomorrow just released. I would urge you to incorporate this code (or a close variant) into the next beta release.

I also did find one interesting issue this morning when going through Written in Stone. It seems like the snow particles got cut off at a visportal, which I imagine is a bug:

Creating a new thread for this as it was being discussed in an old beta-testing thread starting here: https://forums.thedarkmod.com/index.php?/topic/21822-beta-testing-high-expectations/&do=findComment&comment=490751 I suppose the main questions are: when should this spawnarg be used, if at all? why was it introduced in the first place? Can we get it documented properly on the Wiki so misuse isn't propagated? @stgatilov @Dragofer

Messages about pthreads is just some trash which is printed almost always. The issue is most likely not related to it. Please provide some more specific info. Location (getviewpos), maybe savefile. Probably instead config file too. https://wiki.thedarkmod.com/index.php?title=Reporting_Problem

I believe the issue with footsteps not playing is fixed on 2.12 beta. As for how max FPS settings works, I noticed that it takes effect on integer number of milliseconds per frame. So if you set 180 Hz, you'll get 166 because it's 6 ms. And if you set 220, then you'll get 200, since it is 5 ms. The actual code which establishes FPS cap uses microsecond precision, it is not obvious why this millisecond effect happens.

I can confirm your issue. My monitor can run at 165 Hz so I set the in-game FPS cap to 166. When capped at 166 FPS I can't hear any faint footsteps while creeping either, but when set to a cap of 144 FPS the creeping footsteps played as expected. I've only played a handful of missions since I got this monitor so I likely just didn't notice this and if there were any other oddities like the camera and other movement, I didn't notice them either. Still, there's clearly something subtle happening at higher frame rates. I'd be curious if the problem happens on say a 60 Hz monitor but still capped at 166 FPS. Guessing it would. As for the other thing you noticed where the actual frame rate cap doesn't seem to match the one selected in the menus, I think this is more of an issue with the Doom 3 (id Tech 4) engine the game uses as its base. My understanding is it took some work to actually get higher frame rates than 60 working in the game in the first place. Even the dhewm3 source port of Doom 3 doesn't have it working correctly. Even if you uncap the FPS the timing of the game goes to warp speed and it's completely unplayable. https://github.com/dhewm/dhewm3/pull/297. Amusingly there's at least one TDM dev who posted there, since people talk about how TDM implemented their own solution (not without its own bugs).

Hi, I tried playing TDM on a 170 hz monitor but there seems to be a problem with the footstep noise rate and camera sway speed when creeping at very high framerates. I tried a few searches in this forum and couldn't find any posts about it so here goes. With the Max FPS setting at 150, creeping footstep noise and camera sway seem similar to capped 60 fps behavior, possibly a tiny bit faster. With Max FPS at 160 and then 166, the footsteps slow down such that creeping feels noticeably floaty. With Max FPS at 170, I've recorded a whopping 1 minute and 20 seconds between starting to creep and hearing the first footstep noise. The camera sway is slow and smooth enough that it is hard to notice at all. My specs: Windows 10 64 bit, Nvidia RTX 3060 Ti, Intel Core i7-13700KF. I'm playing on TDM 2.11 and have experienced this issue while testing both the Training Mission and Tears of St. Lucia. On a possibly related note, the "Max FPS" setting in found in the game's menu seems highly inaccurate. According to the game's own fps counter as well as my external counter, "Max FPS 180" actually caps the fps to 166, "Max FPS 200" actually caps fps to about 180, and so on. For this post I used the numbers shown in the game's menu, not the ones reported by the counter.

This is caused by DXT1 compression of textures/darkmod/sfx/black_matt.tga. This image has constant color (1, 1, 1) everywhere, i.e. almost black. Previously, the image was compressed by OpenGL driver, so you could get different results depending on vendor. I got (0, 0, 0) everywhere, you probably got the same. But someone else on another vendor could get something else. Now, compression is done by our code, same for everyone. It compresses the color to (0, 1, 0). Obviously, this is a bit closer to (1, 1, 1) than (0, 0, 0) Notice that DXT1 uses 5 bits for red and blue but 6 bits for green. So while it is possible to represent 1/255 value for green, it is not possible to do the same for red and blue. However, this 1 tick adds a bit of green to the overly black picture, and then you apply huge gamma correction (basically take sqrt of all color components) and this green becomes noticeable. Some ways to fix the issue: Use _black texture. It is (0, 0, 0), and I am rather sure it will be compressed to (0, 0, 0) by all implementations. Modify textures/darkmod/sfx/black_matt to be full black (0, 0, 0). Add forceHighQuality to the stage which blends textures/darkmod/sfx/black_matt. Add DDS version of textures/darkmod/sfx/black_matt to core assets. Note that points 1, 2, 4 produce equivalent output, i.e. force texture to (0, 0, 0) color. Point 3 leaves the texture as (1, 1, 1), but there is no way to do this for all materials: the keyword has to be added to each material. Points 1 and 3 look bad because they fix the problem now, but don't stop the problem from happening again in the future.

Looking at the code, the originals were "pm_mantle_pull 750" and "pm_mantle_pullFast 450". The new "pm_mantle_pull" value is "400". A "pm_mantle_pullFast" value of "450" would be slower than regular pull, not faster. With both being set to "400", they are at least similar. Other than that, it's subjective and the feedback from playtesters was positive. Also, referenced internally here: https://forums.thedarkmod.com/index.php?/topic/22256-movementcontrols-settings-in-main-menu/&do=findComment&comment=489158

Would you mind giving more details about this issue? Is it repeatable? Which mission and viewpos? Does it also happen in 2.11?