Search the Community

Change the subtitle setting from Story to On in the audio menu. You will now see subtitles for standard AI greetings / barks.

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

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

Complaint From Players The player must pick up candles before extinguishing them, and then the player must remember to drop the candle. The player must drag a body before shouldering it (picking it up), and the player must remember to frob again to stop dragging the body. The player finds this annoying or easy to make mistakes. For players who ghost, some of them have the goal of returning objects back to their original positions. With the current "pick up, use item, and drop" system, the item might not return easily or at all to its original position. For example, a candlestick might bounce off its holder. (See player quotes at the bottom.) Bug Tracker https://bugs.thedarkmod.com/view.php?id=6316 Problems to Solve How can the "pick up" step be eliminated so that the player can directly use or interact with the item where it is in the game world? How can so much key pressing and mouse clicking be eliminated when the player wants to directly use an item? How can candles be extinguished and lanterns toggled off/on without first picking them up? How can bodies be shouldered without first dragging them? Solution Design Goals Make TDM easier for new players while also improving it for longtime players. Reduce tedious steps for common frob interactions. Make it intuitive so that menu settings are unnecessary. Do not introduce bugs or break the game. Terms frob -- the frob button action happens instantly. hold frob -- the frob button is held for 200ms before the action happens. (This can be changed via cvar: 200ms by default.) Proposed Solution Note: Some issues have been struckthrough to show changes since the patch has been updated. Change how frobbing works for bodies, candles, and lanterns. For bodies: Frob to shoulder (pick up) a body. Second frob to drop shouldered body, while allowing frob on doors, switches, etc. Hold frob (key down) to start drag, continue to hold frob (key down) to drag body, and then release frob (key up) to stop dragging body. Also, a body can be dragged immediately by holding frob and moving the mouse. For candles/lanterns: Frob to extinguish candles and toggle off/on lanterns. Hold frob to pick it up, and then frob again to drop. Frob to pick it up, and then frob again to drop. Hold frob to extinguish candles and toggle off/on lanterns. For food: Frob to pick it up, and then frob again to drop. Hold frob to eat food. For other items: No change. New cvar "tdm_frobhold_delay", default:"200" The frob hold delay (in ms) before drag or extinguish. Set to 0 for TDM v2.11 (and prior) behavior. Solution Benefits Bodies: New players will have less to learn to get started moving knocked out guards. With TDM v2.11 and earlier, some players have played several missions before realizing that they could shoulder a body instead of dragging it long distances. Frob to shoulder body matches Thief, so longtime Thief players will find it familiar. Second frob drops a shouldered body. Players still have the ability to both shoulder and drag bodies. Compatible with the new auto-search bodies feature. Dragging feels more natural -- just grab, hold, and drop with a single button press. There is no longer the need to press the button twice. Also, it's no longer possible to walk away from a body while unintentionally dragging it. Set "tdm_frobhold_delay" cvar to delay of 0 to restore TDM v2.11 (and prior) behavior. Candles: New players will have less to learn to get started extinguishing candles. With TDM v2.11 and earlier, some players didn't know they could extinguish candles by picking them up and using them. Instead, they resorted to throwing them to extinguish them or hiding them. Hold frob to extinguish a candle feels like "pinching" it out. Once a candle is picked up, players still have the ability to manipulate and use them the same way they are used to in TDM v2.11 and earlier. For players who ghost and have the goal of putting objects back to their original positions, they'll have an easier time and not have to deal with candles popping off their holders when trying to place them back carefully. Set "tdm_frobhold_delay" cvar to delay of 0 to restore TDM v2.11 (and prior) behavior. Solution Issues Bodies: Frob does not drop a shouldered body, so that might be unexpected for new players. This is also different than Thief where a second frob will drop a body. "Use Inv. Item" or "Drop Inv. Item" drops the body. This is the same as TDM v2.11 and earlier. This is the price to pay for being able to frob (open/close) doors while shouldering a body. Patch was updated to drop body on second frob, while allowing frob on doors, switches, etc. Candles: Picking up a candle or lantern requires a slight delay, because the player must hold the frob button. The player might unintentionally extinguish a candle while moving it if they hold down frob. The player will need to learn that holding frob will extinguish the candle. The player can change the delay period via the "tdm_frobhold_delay" cvar. Also, when the cvar is set to a delay of 0, the behavior matches TDM v2.11 and earlier, meaning the player would have to first "Frob/Interact" to pick up the candle and then press "Use Inv. Item" to extinguish it. Some players might unintentionally extinguish a candle when they are trying to move it or pick it up. They need to make sure to hold frob to initiate moving the candle. When a candle is unlit, it will highlight but do nothing on frob. That might confuse players. However, the player will likely learn after extinguishing several candles that an unlit candle still highlights. It makes sense that an already-extinguished candle cannot be extinguished on frob. The official "Training Mission" might need to have its instructions updated to correctly guide the player through candle manipulation training. Updating the training mission to include the hold frob to extinguish would probably be helpful. Similar Solutions In Fallout 4, frob uses an item and long-press frob picks it up. Goldwell's mission, "Accountant 2: New In Town", has candles that extinguish on frob without the need of picking them up first. Snatcher's TDM Modpack includes a "Blow / Ignite" item that allows the player to blow out candles Wesp5's Unofficial Patch provides a way to directly extinguish movable candles by frobbing. Demonstration Videos Note: The last two videos don't quite demonstrate the latest patch anymore. But the gist is the same. This feature proposal is best experienced in game, but some demonstration videos are better than nothing. The following videos show either a clear improvement or that the player is not slowed down with the change in controls. For example, "long-press" sounds long, but it really isn't. Video: Body Shouldering and Dragging The purpose of this video is to show that frob to shoulder a body is fast and long-press frob to drag a body is fast enough and accurate. Video: Long-Press Frob to Pick Up Candle The purpose of this video is to show how the long-press frob to pick up a candle isn't really much slower than regular frob. Video: Frob to Extinguish The purpose of this video -- if a bit contrived -- is to show the efficiency and precision of this proposed feature. The task in the video was for the player to as quickly and accurately as possible extinguish candles and put them back in their original positions. On the left, TDM v2.11 is shown. The player has to highlight each candle, press "Frob/Interact" to pick up, press "Use Inv. Item" to extinguish, make sure the candle is back in place, and finally press "Frob/Interact" to drop the candle. The result shows mistakes and candles getting misplaced. On the right, the proposed feature is shown. The player frobs to extinguish the candles. The result shows no mistakes and candles are kept in their original positions. Special Thanks @Wellingtoncrab was instrumental in improving this feature during its early stages. We had many discussions covering varying scenarios, pros, and cons, and how it would affect the gameplay and player experience. Originally, I had a completely different solution that added a special "use modifier" keybinding. He suggested the frob to use and long-press frob to pick up mechanics. I coded it up, gave it a try, and found it to be too good. Without his feedback and patience, this feature wouldn't be as good as it is. Thank you, @Wellingtoncrab! And, of note, @Wellingtoncrab hasn't been able to try it in game yet, because I'm using Linux and can't compile a Windows build for him. So, if this feature isn't good, that's my fault. Code Patch I'll post the code patch in another post below this one so that folks who compile TDM themselves can give this proposal a try in game. And, if you do, I look forward to your feedback! Player Complaints TTLG (2023-01-10) Player 1: TDM Forums (2021-03-13) Player 2: Player 3: TDM Forums (2023-06-17) Player 4: TDM Discord (2021-05-18) Player 5: TDM Discord (2023-02-14) Player 6: Player 7: Player 8:

Just curious, based on this discussion: http://forums.thedarkmod.com/topic/19239-soft-r-gamma/?p=427350

I believe the subtitle Stone font is currently scaled to 11.52 pts, instead of 12 pts. I have asked before whether that is the intended scaling, or inadvertent, but heard nothing. In tdm_subtitles_common.gui, there is: #define SUBTITLES_TEXT_SCALE 0.24 In TDM 2.11, it was: #define SUBTITLES_TEXT_SCALE 0.25 Where a scale of 1.0 represents 48 pts.

Not technically, no. snatcher, maybe it's soon time for a subtitle Modpack to offer some of the design alternatives.

It appears it's only affecting the vertical positioning of the subtitle slot stack, so I wouldn't think it affects max chars per slot

Does this guarantee that the same (maximum) amount of characters fit in that subtitle box at any time?

My two cents here is to mimic video streaming services, such as Netflix. They've likely spent a lot of time and money researching subtitles. The Netflix default is a white font color with a black drop shadow. In the subtitle settings, users can change the font color and enable/disable a background color. We could do the same and provide settings in the menu. The improvements to both the subtitles and location ring are looking good! Netflix settings:

I think this doesn't looks very nice. I think it's best to make the background the same width as the subtitle block. What do others think? Are we going for the background look, or are we going for the black outline? It's not clear to me what the current direction is, but the outline looks nicer and it seems a waste to try to implement something that doesn't get chosen anyway.

reduced height of the box & text from 45 to 37, while moving everything up by 9 points location ring moved up by 2 points added background field to location ring distance between subtitles reduced from 55 to 52 (50 makes location ring merge with next subtitle box) tdm_subtitles_message.gui

"I think we have an opportunity to enlarge the potential TDM community to include deaf players, or those who like to play games with sound off." Even for the existing TDM players, some degree of customization, e.g., font choice, would be an improvement. Nobody argues with that, provided the bar to expressing need is not too high. Certainly TDMs large number of CVars hints that a bit of complexity has been tolerated in the past to achieve improvements and allow for satisfying individual needs and preferences. The TDM subtitle system I feel was meant to eventually cover all game sounds, so yes. (If you're talking about screen-reader software, it will not understand game context.) That's one of 2 possible methods I mentioned to help implement per-subtitle visual cues. There are no doubt others. It's ok with me if things like cue customization doesn't start to happen until TDM 2.13. I'm just trying to lay out a pathway through the terrain, which sadly seems more fraught than ideal.

Can you share a subtitle file with mixed regular, bold, italic, colors... such as the above example so that I can see what you can see in my PC? The ugliest the subs the merrier

Colored text shows normally like this: But with Snatcher's subtitle look the colored subtitles look now extremely bolted: I guess this does make it more useful for emphasis, but a little less bolting would be better.

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.

Ever since I worked on "Chalice of Kings" with Bikerdude, I have wanted to get flame particles with new particle glares into the core mod. My reasoning was that the candles have glares and the un-glared torches look mismatched. This proposal was met with mixed reactions, so (knowing the history of TDM feature proposals...) I have created a technical demo. You may download it here: zzz_flameglare.pk4.txt (fixed) Just rename without the .txt extension at the end and place it in your Darkmod directory. Here are some screens. Using particles for this is probably the wrong way to go now that Duzenko has an emissive light feature in his branch: http://forums.thedarkmod.com/topic/19659-feature-request-emissive-materialsvolumetric-lights/

I made Subtitle files with help of Whisper. This uses only srt files. No inline subs. Edit: subtitles added to mission.

I think it looks much better when included in the subtitle background block.

I wonder if you could test 9x versus 4x-diagonals and 4x-non-diagonals? Maybe the extra 5 renders don't add much. There probably is some minor performance effect. I think you're still showing the widget too high, so it seems to be associated with the wrong subtitle. I prefer @stgatilov's original vertical positioning, even though it pushes the widget's lower edge against the top of the caption lettering. I wasn't sure what you where trying to point out as a problem... was it the word wrap? Yeah, the automatic word wrap with centered text can look ugly at times. An FM author can choose to insert a manual line break in that case. I do that routinely all the time for barks. Since padding is part of the background box, sure. It occurs to me now that maybe, to improve the appearance of text centering, the background box should also have equal-size padding on the left. That is, the location and size of the inner box is unchanged, but the outer box is wider and its origin shifted left, so the inner box is centered horizontally within. The padding can certainly be made smaller. I imagine the seed value of 17px was for a worse-case character like "W", that was then rounded up to 20. We could shrink it by: - choosing the seed character as the widest that might actually be at the end of a line followed by space to cause word wrap. Probably "w" or "A". - not rounding up - scaling by the compression aspect ratio I'll try to come up with a new number. No problem here with having the background by default. But recognize there's a compromise between world visibility and text readability. Can't we make it possible to turn the background off for people who hate it so much that they avoid using subtitles because of it? "...visible in all circumstances" may be too high a bar. The simple implementation would be a single CVar that toggles the background on/off and possibly, conversely toggles fake drop shadows off/on.

Yes, the backing field shown, while narrower, is still a fixed width for all bark texts, so still wider than ideal for that particular phrase. The width is the minimum needed to safely accommodate subtitle lines up to 42 characters long of 12 pt Stone font.

True. It would require a modification of the engine code. Earlier this year I wrote two experimental C++ utility programs that do the required calculation, for respectively 12 pt Carleton and (scaled to 12 pt) Stone fonts. However, others have expressed distaste, on complexity grounds, to having variable-width backing fields, so I've since been restricting my advocacy to a narrower fixed-width backing field for speech-verbosity subtitles. This outlining isn't really visible in your screen shots; and I'd like to see various color-tone game locations too. I see you use the "bordercolor" attribute for your outlining. I vaguely recall there was some circa-2010 TDM "drop shadow" experiments with (I'm guessing) using this for subtitling, with the Carleton font then in use. (This was before I got involved in subtitling.) Same conclusion: a bit problematic with the given font. So that led to the translucent backing field as an reasonable approach. It would be possible to add a new unicolor font just for subtitles to TDM. There is a roadmap for this, but it's a major project, so TDM 2.13? Agreed. That was part of my motivation for wishing to narrow the width of the backing field. I'm in favor of having settings to let players have more flexibility in the subtitle presentation. That would include font color.

Another utility program, "findToolLongSubtitles", is now available, which scans a directory for .subs and .srt files, and checks the length in characters of each subtitle line against a maximum fieldwidth expressed in characters: Win executable C++ source code file It is more fully described in the latter as: findTooLongSubtitles.cpp By Geep, March, 2023, for The Dark Mod, under the terms of its open-source license. Purpose: Given a particular subtitle maximum fieldwidth, evaluates TDM subtitles - contained in .subs and .srt files - and reports those that don't fit. Assumes a maximum 2-line subtitle field. If a subtitle doesn't currently fit (or suboptimally relies on auto-word-wrap to fit), but could be made good by inserting or adjusting a linebreak, locations where that break could be positioned are shown. This program only examines a single folder at a time for contained .subs and .srt files. If your FM has these files in multiple places, run this program more than once. For an "inline" subtitle, a string-embedded "\n" causes a manual linebreak. When shown in this program's output, that subtitle has 2 lines, as in the game. This allows use of a common output routine for inline & srt subtitles. Console program invocation: findTooLongSubtitles -m maxSubtitleCharsPerLine [default is 42] -d dirWithSoundFiles [default is current dir] -o output file [default is stdout] Build: Requires C++ 17 or later For example outputs, evaluating subtitles found in the 2.11 releases of FMs New Job and St. Lucia against a proposed 42-character fieldwidth, see here.

"...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!

I noticed that there was a pre-existing "carleton_condensed" font, and was wondering how it compares with the other versions I've floated as subtitle font options. So here's an eyeball comparison, all with the same gui scale factor of 0.25. In this shot, from top to bottom are: "carleton_condensed" "carleton" "carleton@aspect=16:9" So "carleton_condensed" is intermediary between the two. If "carleton" is considered width=1 (designed for 4:3 screens), and carleton@aspect=16:9 is width=0.75, then "carleton_condensed" is maybe width=0.875 So, since it's pre-existing, it could be another reasonable subtitle font choice... maybe called in Settings "Carleton, Medium Wide"?