Geep

I've changed the example code in wiki entries "Scripting basics" and "My first map script" to use what @Frost_Salamander indicated: $player1.setHealth(0); // kill the player instead of $player1.kill();

The subtitles for The Young Builder (Builder 4) vocal set is now available: testSubtitleYoungBuilder.pk4 As usual, the testing FM is used as the vehicle to provide these subtitles for eventual incorporation into TDM. Statistics There were 471 subtitles. Only 10 were SRT; the rest inline. Of the inline, about 87 required a -dx extension of duration in the range 0.25-0.50 seconds (By policy, 0.50 was the cap, hit by 35 of these. In a worst case, that cap could be raised; none required that). Of the srt, two had a first phrase that had to be slightly shortened (non-verbatim). Corresponding Excel File TheYoungBuilderSubtitles.xlsx The final form of the Young Builder Excel spreadsheet was also retained (without data) as Version 4 of the evolving Subtitle Template. Documentation about the spreadsheet/template usage will be available.

Maybe that can be faked somehow. Create an AI that looks like a guard, but is really a civilian, and swap that character in to replace a real guard when the skeleton appears?

To elaborate on that idea further, this would make "Version:" into a keyword, indicating the start of the block that could be ignored during display, and replaced by download info. That info would have to be locally persisted. I think the file "missions.tdminfo" already does this, but content would have to change somewhat (e.g., to include release date of locally downloaded FMs). Pre-release FMs could use whatever versioning scheme desired in darkmod.txt, e.g., "Version: 0.2", "Version: A", "Version: Dec 4", and rely on suppression of that when the official releases/updates occur. As with other keyword blocks, "Version:" could be in any order with respect to other blocks. If you didn't want this new display-override feature, use a non-keyword, e.g., "Vers #3". Just like "Version:" is treated currently. [An alternative implementation of this idea would just auto-edit the "Version:" block of darkmod.txt during upload to the distribution site. So all the change happens on the backend. Might be issues with site mirrors.]

Currently, to see the Downloadable Version number from the TDM menus, well, it's kinda buried. You have to go to the Downloadable Missions list, select an entry, and in the popup left screen, under details, select More.... That shows you info in the internal local "mods" array. Including the Release Date. When you select from Available Missions instead, the info in the left screen comes pretty much from darkmod.txt Proposal - make that display code smarter: if the selection is one that was earlier downloaded (e.g., is in mods[] ), instead of displaying "Version: ..." from darkmod.txt, instead show "Downloaded Version ## Released on <date>"

OK, I stared at the code some more. It doesn't care about EOL. It just divides the text into blocks based on where the known keyword strings are. (It's a bit complicated. It uses a sorted associative set of starting locations (plus end-of-text), and manipulates an iterator over that set is such a way that the block order is not important. That's in ModInfo.cpp's LoadMetaData() function.) So in the example above, a block begins at the start of "Title:..." and stops right before the beginning of "Author". Because "Version:" is not a parsed keyword, it's just more content for the title block.

I don't know exactly how the parsing determines where a string like "Title:" ends. I was guessing it looks for a EOL character, but maybe not.

As far as I can see from looking at the source code (and in agreement with @nbohr1more that FM "Version" is not parsed), the New Missions popup is just showing lines* associated with FM darkmod.txt "Title:" fields. So I guess what's happening is that you edit your darkmod.txt like this: Title: In Plain Sight <enough spaces here to wordwrap to next line when displayed> Version 1.3 Then, in the main mission list, because of all the spaces, the "Version 1.3" won't appear due to clipping. Assuming that's what you want. *It also starts with #str_02143, "New Mission(s) Available" in English, and if there's more than 3 new missions, stops listing them and just says so.

The update to subtitles for The Thug vocal set ("Thug2") is now available: testSubtitlesThug2.pk4 Corresponding Excel file - Thug2Subtitles.xlsx The testing FM is used to distribute this update. (See the preceding description of "Lord2" for recent testingSubtitles... improvements.) Out of 392 subtitles, the changes are as follows. Durations, Phrases, Linebreaks 5 formerly-inline subtitles are now each 2 srt phrases. Of the 5, 4 are muttering or snoring; 1 has a yawn between 2 sentences. For inline, 14 -dx extensions are added to pad duration between 0.25-0.50 4 previously-shortened inline captions are now restored to verbatim, due to extension (-dx or auto 0.20 seconds) 10 enforcements of 42-char/line policy are done by adding linebreaks Style Changes 15 Square brackets are replaced by parentheses 3 Sentences starting with 'evening are changed to Evening Transcription More Like Vocalization 1 "is" replaced by 's 1 "?" replaced by "."

The update to subtitles for The Lord vocal set ("Lord2") is now available, that makes use of the new -dx (durationExtend) feature of 2.12dev: testSubtitlesLord2.pk4 Corresponding Excel file - TheLord2Subtitles.xlsx As usual, the testing FM is used as the vehicle to distribute this update. Out of 390 subtitles (all of which are inline, no srt needed), the changes are as follows. Durations Extended 67 times, -dx was used to pad duration between 0.25 and 0.50 second (instead of default 0.20), calculated based on a presentation rate of 17 cps. The value of 0.50 was set as a cap by policy. When reached, it leads to a presentation rate higher than 17 cps. The cap is ignored if the presentation rate reaches the quite fast 20 cps. For Lord2, this occurred once (-dx 0.61, a value calculated for 20 cps presentation rate). This particular subtitle now is verbatim, unlike the original Lord subtitle release, where the text was shortened. Also for presentation rate reasons, leading optional "(...)" descriptors were dropped or shortened (1 case of each). In the spreadsheet, additional columns were added to help in the foregoing calculations. This will be documented when The Wench is released. Style Issues Capitalize leading 'Tis or 'Twas 14 times. Replace [...] with (...) for descriptors. Improvements for testSubtitles... FMs This applies to Lord2, forthcoming Thug2 and Wench releases, and later. In-game, the "Prev", "Again", and "Next" buttons are now twinned with a group of 3 more buttons labeled "Same but Quiet". As requested by @datiswous, these affect the cursub numeric counter without either playing an audio sound or showing its subtitle. The cursub counter (as an HUD overlay) shows itself more consistently, thanks to an implementation hack. Each subtitle appears in a field that is now Geep-standardized to a half-screen wide, compatible with a 42-char/line limit. This is done with an override of tdm_subtitles_common.gui, based upon a customization of TDM 2.11 code. (So it does not include visual indicators of AI location or speech volume found in recent 2.12dev's tdm_subtitles_common.gui).

Probably not enough to go on, for anyone to say. But it's great that you quickly found a way forward.

In the kdenlive subtitle editor, use the "End" counter to adjust the subtitle phrase end point. Then export to an .srt file, and look within that file. Does the phrase have the same specified endtime, or has it been changed? The latest Cadet release version, 2.0.044 of April 14, incorporates the beta. The main feature added was that, if you go into Tool/Preferences, there's a new line "Show cc reading rate with alarm threshold of [...] in units of [CPS or WPM]". There's also a bit more flexibility in how to advance from one phrase to the next. BTW, I found the Cadet project feature adds no value. I just (re)use an anonymous project, and export the .srt. If later I need to adjust something, I can use "Import" of the .srt to do so. If I strongly needed a tool that had speech-to-text capabilities, I would not use Cadet. Since I've got preexisting text for the vocal sets I'm currently processing, I'm not needing speech-to-text right now.

checkDurationsinSRT is now available: checkDurationsInSRT.exe checkDurationsInSRT.cpp This Win/console program scans a directory for .srt files, reporting on each in turn. It warns about those subtitle phrases(aka messages) that are potentially too short or too long in time, or that seem to require too high a reading rate, expressed in characters per second (cps). It also looks for within-file subtitle messages that overlap in time. Invocation: checkDurationsInSRT -l lowerBound [default is 1.0 sec] -u upperBound [default is 6.0 sec] -c maxCPS [default is 17] -d dirWithSrtFiles [default is current dir] -o output file [default is stdout] For more, run with -h or ? options, or see comments in the C++ source code file. EDIT: The above links now access a May 6, 2023 update, that corrects a significant error in character counting for the cps calculation. In addition, if a given subtitle's cps is too high, the warning now includes a suggestion: "try x.xxx seconds". That says what longer duration would be needed to achieve the target cps. How or whether than longer duration could be achieved is left up to you.

Yeah, it's pretty simple. I'm using a beta build, that adds an automatic cps calculate & display, and better supports my workflow... don't know the beta has seen public release yet. I found I could live with Cadet's quirks better than those of kdenlive. Chief among the latter: because kdenlive is based on video, it insists on changing exported srt times, presumably to conform to the frame timestamps (of a non-existent video). This bothered me too much, maybe more than it should. I don't specifically, though I do use utility programs and Excel to help calculate constraints and make decisions about - inserting line breaks when to use the new inline durationExtend option, and what value to give it SRT instead of inline Non-verbatim instead of verbatim transcription For a given vocal set, it appears just a small number of bark clips need the SRT treatment (and so Cadet) instead of inline. Another satisfied customer of buildSubtitleShaders. I've got another console utility about ready to release, for group checking SRTs. Soon. For me, this is an example of where it CAN fit in an inline, but should be placed in an SRT instead. I would definitely put the final phrase into a subtitle message, and at least consider breaking into 3 or 4 messages. For The Wench, there were some clips (of 7 - 30 seconds) where she's idly humming. Rather than a single inline, e.g., "(humming long tune, hoarsely)" that stayed up the whole time, I went with srt, showed that message briefly, and then towards clip end showed "(humming ends)".

I was just trying to distinguish between individual message (aka phrase) appearance time on-screen, and overall srt timeline maximum. You're thinking "duration" should to refer to only the latter, but I was momentarily using it to refer to the former. Probably it would be better with srt not to refer to "Duration" by itself, but instead: SoundDuration MessageDuration MaxMessageEndtime "Duration" by itself is misleading, because it seems to imply something about how long messages appear on screen; that's not the case because the first-starting temporal message in an srt doesn't have to start at time zero. (And the summation of individual MessageDurations is even less informative, since there can be time gaps between messages.) That's one way of reporting what for TDM is an srt error. OK, I understand what the expected code behavior is now. Thanks.