Geep

Another C++ program now functional, "soundDurationsCSV.exe", that fetches sound file names from a directory and gets their durations in seconds, to millisecond resolution. The result is output to a .csv file, for import into Excel. Durations will be used to calculate WPM and CPS reading rates for subtitles. Details: This Windows-specific console program relies on separately-installed ffprobe (bundled with ffmpeg) to get each duration. The program builds a batch file that calls ffprobe repeatedly, for each sound file. Then quietly executes the batch file, and finally reformats the results into a .csv The program needs further polishing, but good enough for the moment to start working on Lord subtitles next.

Yeah, I'm wrong, you're right, there are 3 script objects due to @Dragofer that are included in 2.11 tdm_base01.pk4/script/: - in tdm_safe.script, there's scriptobject tdm_safe, that is referenced from your safe's door - in tdm_safe_lock.script, there's these scriptobjects: tdm_safe_lock, referenced from the lock housing tdm_numberwheel, referenced from each of the 3 wheels Since the safe02 prefab elements seem to reference these, the problem probably lies elsewhere. Maybe Dragofer will shed light. Or you could temporarily try the wall safe prefab, that uses the same scriptobjects, and see if that works correctly or fails similarly. Otherwise, you might override these script files with your own copies and start debugging (i.e., print values to the console).

Probably the .script file that's needed, but unfortunately can't be included with a prefab. Maybe there's a comment somewhere in the prefab (or in the wiki or forums) that says what script it needs and where to find it. (The similar combination setup I used earlier doesn't involve "slot", so clearly uses a different script that I what I have.)

Could well be, but there's lots of ways that could go. You had some good suggestions for automatically adjusting vertical locations and field widths, on the assumption that the subtitle font size remains fixed. But maybe that assumption needs to be revisited. Certainly the current subtitle font size is bigger than the fonts with the weapon and inventory icons, so maybe it doesn't need to made greatly enlargable to address needs of low-vision folks. The automatic adjustment you suggested would also be different from other HUD settings, that are (mostly) manual and independent of other elements. Maybe there should be subtitle positioning sliders. I dunno. I worry that moving the subtitles still further towards the center of screen (particularly when 3 fields are active) would make the game unplayable. Making the fields narrower than at present I can certainly see. Possibly only as wide as their text (another form of automatic adjustment), as I mentioned earlier. I expect most everyone would agree with you and wish HTML-style font markup was available throughout TDM. The problem is, it would be such a major effort, since the engine doesn't support such font markup (and underlying font attributes and rendering) currently. Still, maybe it's time to add that as an "aspirational" feature request to the bug tracker.

I just built a tiny command-line program, "buildSubtitleShaders.exe", to expedite creation of the specialized sound shaders needed by my testSubtitles.... You point the program at a directory of .oggs, and its spits out the completed .sndshd file. Basically, it does what datiswous (and similarly, me) did in Excel earlier, as shown above. I've used it to now generate The Lord sound shaders. Details - This was a rather trivial VS 2020/C++ 17 console program. The only minor complexity was in programmatically truncating the directory path down to what TDM wants, namely, a path starting with "sound/..." There's some sanity-checking to make sure the path provided (either implicitly or explicitly) is of TDM-compliant-form. This runs under Win11; because of file path issues, it might need to be tweaked to work right under Linux. To use with stock tdm-distributed sounds, you would point it at an unzipped .pk4 directory of interest, and generate the needed file. At run (i.e., testing) time, because of the truncated directory path, it works fine against the usual zipped .pk4, like every other sound shader. At some point I'll probably post source to github. Going on now to try to build a similar program to gather sound file durations, for import into Excel as a csv file. Will be trickier.

I've chosen "The Lord" vocal script to subtitle next.

I noted this in the other thread, but let me quote myself here as well: I've updated the "displayed text" section of the wiki's Subtitles to include this and other stuff.

For fixed-width fields, side margins of about 115 would support 55 chars per line, and be a touch under 2/3rds of the screen. Side margins of about 160 would support 42 chars per line.

Just confirmed that the caret markup does work for subtitles... ^1good whore^0 appeared in red. This markup and its limitations are described in https://wiki.thedarkmod.com/index.php?title=Text_Decals_for_Signs_etc.#Signs_with_Illuminated_Colored_Letters

If the Icon Size and Weapons/Item Text Sizes are adjusted to their maximum HUD settings, then it will be pretty impossible to avoid overlap [see image, still using previously-proposed 100 margins]. The 100 margins could, however, be increased. If the field width was narrowed slightly from about 60 characters to about 55, that would be about 2/3rds of the screen. That would still be fine, and provide very good flexibility to the subtitler to decide where best to break a long phrase into 2 lines. If narrowed to 42 characters (about 8 words), which other subtitling systems use, then verbatim subtitling would still be doable, but (for phrases > 70 chars) flexibility would be lost, so either poorly positioned linebreaks would occur, or more phrases would have to be subdivided, e.g., from inline into srt. Now, other subtitling systems minimized average overlap by not using fixed-width fields. Common is to have, behind each text line, a black field that is just the width of the text. We could do that. For each text line, the engine would calculate the width needed, and pass that value to the gui. Our backing field could be black (best for quick readability) or translucent like now (best for world awareness). [This would be preclude augmenting the field edge with speaker positioning info, floated earlier.] Also, again thinking about overlap, the subtitling field-choice system could be made smarter, so that if there's something to be seen at the bottom of the screen (e.g., enlarged light gem, breath metter, text like "Acquired 80 in Jewels"), the lowest subtitle field is the last of the 3 populated, not the first. Slider(s) could be added to adjust subtitle font size (and other layout attributes). Could get pretty complicated... and make subtitlers life harder. As for changing individual characters/words with markup, yeah, there's only a bastardized "caret" markup at the moment to select primary colors. Having a real system would be no trivial effort.

I just did an experiment, with the field width margins increased from 10 to 100. That looks attractive with respect to the current weapon and inventory displays in the corners. And seems wide enough for expected content. To confirm if they are wide enough, I took the 3 longest Thug subtitles (as representative of longest expected subtitle strings) and duplicated each text string, to guarantee that they would overflow (exceed 2 lines). I then counted where they overflowed: after respectively char 121, 134 [shown], and 126. IMHO, as long as a typical phrase of 120 characters or less (and usually way less) can fit, it's all good. Where 120 characters = 6 second max subtitle duration x 20 cps max reading rate. @datiswous, since this was your idea, perhaps you'd like to do this as a new-feature request on the bug tracker? Then I could upload the proposed revised tdm_subtitles_common.gui file.

In the long run, figuring out a way to add font attributes (e.g., color, bold, underline, italics) would be great for subtitles and throughout TDM. Hard, tho. I guess fontsize markup is an attribute that might be most easily conceived at the moment. But I don't know if TDM has any underlying support for interleaved mixed-size characters. Turning to a potentially easier issue, on the "Barks" thread, @datiswous noted... I responded: datiswous: Geep: I agree.... Related: I'll probably do some more experiments with the current TDM font & size, to understand max char count versus field width.

Regarding Excel, I likewise used its integer incrementing feature. My spreadsheet was more complicated - ultimately multiple worksheets. That's because I was using it to include the draft subtitles, from which were auto-calculated character and word counts, as well as CPS and WPM, which were then color-coded against specific thresholds Those latter calculation required the sound file durations. I originally used Windows Powershell to gather those, but Windows only exposes duration to the nearest second, which proved inadequate. I then installed the Windows version of ffmpeg. That includes ffprobe, which reports duration in seconds to 2 digits after the decimal point. Regrettably, the output format from ffprobe is a problem, and Powershell was a big fight for several reasons (among them I'm a Powershell novice). The results were usable but barely. So I'm not going to write up my method as the hodge-podge it currently is. Maybe one or more specialized C++ or C# formatting programs would be the way to go next for me. Sadly, the extraction and import of first-draft subtitles from the existing wiki AI vocal scripts will probably continue to be a manual process. Because the .ogg file names have changed from when the old vocal scripts were written, so auto-matching can't easily be done. (This is a problem FM subtitle authors don't have.)

I agree. I'm copying this idea over to the https://forums.thedarkmod.com/index.php?/topic/21741-subtitles-possibilities-beyond-211/ thread. Related: I'll probably do some more experiments with the current TDM font & size, to understand max char count versus field width.

Player Clip or a general clip is go-to all-purpose method. If you outfit your bushes with sloped tops (I recall greater than 40 degrees), the player can't climb up them.

Interesting idea, though I wouldn't want the text to be interpreted as objectives by the player. Glad that's working for you. Yeah, getting the data into shape is a pain. I did it for me with a lot of Excel in/out and text find/replace misadventures. Some potential for process improvement there, next time. Most guidance for subtitles would restrict them to the central 2/3rds of the screen, width-wise. So maybe narrowing the fields a bit throughout would be good. Need to think about this. I guess the lowest field would also obscure the health and breathe bars a bit.

The subtitles for The Thug vocals have been posted to the bugtracker #6240 for review & eventual incorporation into 2.12dev. They are in FM form, embedded into QA-program testSubtitlesThug. The .pk4 is available here: https://drive.google.com/file/d/1VNP2fNge-2Ff3RkdUvCLagRENUESVW40/view?usp=sharing Easy instructions on using this FM can be found in both the Notes and Briefing. That info also sketches how the test program can be adapted by FM authors to present & test sets of their own custom subtitles. (I'm not claiming getting your data into this FM is real easy.) As I refined these subtitles, a particular style evolved, and particular tools/methods were used. I'm working on documenting this, but it won't be ready to release for a while. And things may mutate further as I tackle the next AI's subtitle. I'm thinking I need to do a character with longer speeches next, e.g., a noble.

I don't know if this would solve it, or cause other problems, but you could try enveloping the key area in a force field that pushes the key against the wall.

I wonder if this gawdawful hack works in readables: https://wiki.thedarkmod.com/index.php?title=Text_Decals_for_Signs_etc.#Signs_with_Illuminated_Colored_Letters Possibly a related need: in long term, could use color fonts in subtitles too.

I changed over to finer-grained characters-per-second metric instead of words-per-minute. Using 20 cps, 3 of the above phrases could be left verbatim.

For the Thug, out of 393 utterances, only 9 required subtitle editing to stay within a 240 words-per-minute reading rate, the highest anyone thinks reasonable. There were: Verbatim --> Shortened Let's have a look. --> Let's look. I'm ready for him. --> I'm ready. [only needed for shortest clip with this phrase; 2 other clips were fine verbatim.] How'd you like a taste of this? --> Like a taste of this? [2 clips] I'll piss where I want to piss. --> I'll piss where I want to. I guess I have to do it. --> Guess I have to do it I guess I have to do it. --> Guess I have to. [shortest clip] The son of a whore was right here. Look around! --> (curse) ...was right here. Look around! Look, you bastard! --> Look, bastard! If I used the still high but slightly lower reading rate of 200 WPM, about 21 additional edits would be needed. Edit: Actually, those last 2 don't need editing. Spreadsheet calculation problem fixed. Might revisit some criteria too.

BTW, under Win11 File Explorer, you can see the duration (called "Length") of sound files in a directory, as well as sort on that. Use the "Details" view. Right-click on the columns header, and checkmark "Length" to include its column. Resolution is only rounded to the nearest second, tho. Adequate for making the "inline" vs "srt" choice. Not for calculating WPM.

It's the duration that matters. If the clip exceeds 6 seconds, use srt. Individual segments within srt should be 1-6 seconds long. There's more to it than that. I'll DM you later today with a Word doc, a draft fragment of the style guide under development, that delves into this. Specifically, if there's too many words to read in the time that a subtitle is shown, you may need to edit out some words. That is, move away from a verbatim caption. The fragment has quantitative guidance on this.

@datiswous, made that correction fm_test.subs --> fm_conversations.subs @stgatilov, about srt naming and file location, would you be OK with the following edit? New/changed stuff in italics: srt command is followed by paths to a sound sample and its .srt file, typically with matching filenames. An .srt file is usually placed either with its sound file or in a "subtitles" folder. The .srt file format is described e.g. [1]. The file must be in engine-native encoding (internationalization is not supported yet anyway) and have no BOM mark. It contains a sequence of text messages to show during the sound sample, each with start and end timestamps within the sample's timeline. It is recommended to use common software to create .srt files for sound samples, instead of writing them manually. This way is more flexible but more complicated, and it is only necessary for long sounds, for instance sound sample of a briefing video. It's a simple enough standard that it can be shown as an short example, demonstrating that subtitle segments can have time gaps between them. And the example can show correct TDM usage, without requiring a trip off-site and picking through features that TDM doesn't support. Specifically, the example shows how to define two lines by direct entry, rather than using unsupported message location tags (X1, Y1, etc.). And skips other unavailable SRT font markups like italics, mentioned in the wikipedia description. The example would also show the TDM-specific path treatment. The example could be inserted before the sentence "It is recommended to use common software...."

@stgatilov, in the Subtitles_decls section of the Subtitles wiki page, you show example code, that includes an srt reference. Wouldn't it be better to guide people to place the corresponding .srt files within the "subtitles" tree (where their .subs live), rather than the "sound" tree? Also, should FM authors be encouraged (if not required) to prefix .srt files with "fm_" ? Like "fm_sound8_long.srt" ? Finally, in the "displayed text" section, under the srt command, there's a desperate need to see example .srt content, in this case, something made up for sound8_long.srt (or fm_sound8_long.srt) like: 1 00:00:06,612 --> 00:00:10,376 Something's wrong with this crystal ball. 2 00:00:15,482 --> 00:00:20,609 Bugger me! It's not showing the right dream. 3 00:00:25,336 --> 00:00:28,167 Ah! Here we go. --end