Geep

@datiswous and others, you can get my Windows console program buildSubtitleShaders.exe now at: https://drive.google.com/file/d/19Pf513nv5gwOzZ5tyWHJN7Ka-D9UxBET/view?usp=sharing Do "buildSubtitleShaders -h" to get help on parameters. The output should be compatible with an instance you clone (and rename) from the testSubtitlesThug FM, provided you go into the FM's .script file and change #define SHADER_PREFIX "fm_ai_thug_shader" to #define SHADER_PREFIX "fm_test_subtitles_shader" This will be the fixed sound shader prefix I use for all the AI vocal sets subtitles I will make available (embedded in various testSubtitles...) to QA in the future. I'm not releasing the full VS project for this program right now, but you can make your own console project and build it yourself with the only file needed, buildSubtitleShaders.cpp: https://drive.google.com/file/d/16Epx2V2iGa2b91Mnt0cbzGSb3IQBJpk7/view?usp=sharing Needs C++ v17 to compile. Rest are VS2022 defaults. For more on purpose and deployment, see comments in start of buildSubtitlesShaders.cpp generated output file

This ties into another thing I would very much like, namely, the ability to extend the duration of a subtitle beyond the end of the clip. This is not possible now, so would require some build-out of threading capabilities for subtitles. There are a lot of barks that are too short, below the minimum recommended 1 second for a subtitle. In theory, one could add dead-air to the .ogg files, but really, way too much tedious work. Assume that the underlying tech issues to allow duration extension could be addressed. Then extension could be deployed through 2 complementary features - - Have the subtitle system automatically enforce the 1 second requirement for inline only. - Have the "inline" and "srt" commands take an optional additional parameter, for overall duration (i.e., greater than the clip duration). This would allow the subtitler to ask for a small time extension to accommodate CPS/WPM concerns. When specifying the final "srt" phrase, it could use that extended timeline. Typically, for longer clips, a small extension like 1/4 second more would suffice. A long extension is undesirable for voice-subtitle sync reasons. Finally, going back to the previous post, if the subtitles were threaded and more independent of the sound playing, then another capability would be, if a high-priority clip wants to play but there are no subtitle slots, see if any of the lower-priority clips will conclude shortly (ideally, within 1/4 second), and queue the subtitle to appear then (importantly, without shortening). Instead of immediately bumping the lower-priority clip.

So, just thinking about priority further, we have the 3 obvious levels: 1) story 2) speech 3) effect Suppose, if all 3 slots are filled, a higher-priority subtitle could "bump" (take over the slot) of a lower-priority one. I'm thinking this would not be too difficult technically. From a reader's viewpoint, the main difficulty is that the bumped subtitle would appear on-screen for a shortened amount of time. How do you minimize the grief? You have to choose which subtitle to bump. If they're different priorities (1 is speech, 1 is effect), this is easy. Otherwise, you might choose the subtitle of the sound clip that is closest to completion anyway. This implies knowing the total duration and the starttime of playing clips. Maybe you need to put in a 1/10 second no-subtitle moment when the bump occurs, a visual cue.

Copied from the AI Barks thread. In response to datiswous, I said:

Here's my understanding. There are 3 stacked non-overlapping "slots" for a subtitle field to appear in. You can see this in the testSubtitles FM if you hit any of the buttons fast enough. (Granted, this is all in the same voice, not different voices.) When a sound is about to play, the sound system looks for the lowest unused slot to put its field in. And it keeps that field until the sound clip ends (e.g., across multiple srt phrases). If a sound starts playing and there's no slot free, then no subtitle appears for it. Because the sound system currently doesn't know who/what emits a sound, it can't "reserve" a slot for a particular AI or other entity across separate .ogg files. Even without knowing the emitting entity, what the subtitle system could do now (but doesn't currently) is look at the standardized pathname of the sound file, and determine what vocal set it comes from. It could then "reserve" a slot for a while for future utterances from the same voice. Is that a good idea? Unclear to me. (There's a broader issue here about giving priority to "story" phrases over "speech" phrases. I'll move this to the Future thread.) Later in the year, when more bark subtitles for different voices are in 2.12dev, it should be possible to just drop your player into a room of miscellaneous AI and fill up those 3 slots big time.

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.