Jump to content
The Dark Mod Forums

Geep

Member
  • Posts

    1073
  • Joined

  • Last visited

  • Days Won

    58

Everything posted by Geep

  1. The subtitles for The Pro vocal set, popular for upper-level guards, is now available: testSubtitlesPro.pk4 As usual, the testing FM is used as the vehicle to provide these subtitles for eventual incorporation into TDM. Statistics A new console program "statsForSubtitles" now calculates this info. There were 353 subtitles. As usual for barks, almost all were inline. Of the 5 that were instead SRT - 3 were 2-message 1 was 3-message 1 was 4-message. Of the inline, 54 were arranged on 2 lines with a manual line break. Of the inline, 46 required an explicit -dx extension of duration, as follows: 26 in the range 0.25 to 0.49 second, for a 17 cps presentation rate. 18 at the cap (by policy) of 0.50 second. (For one of these, a near-inperceptable word was dropped to achieve this.) 2 worse-case fast-talkers, raised slightly beyond the cap, for a 20 cps presentation rate. Corresponding Excel File TheProSubtitles.xlsx This spreadsheet used (without any changes) Subtitle Template V5, documented previously in the context of the Average Jack vocal set.
  2. Ah, there was an original plan to have a heart-shaped stone, or maybe bind two oval stones together to fake that (as a previous FM did, that was a story inspiration here). But it turned out that was all too much of a lift. So just used a single oval stone, with a heart outline to allude to the "Stolen Heart" theme. Just atmospherics.
  3. FYI, there are now two documents that describe my current workflow for the bark subtitles associated with any AI. The "Overall" Doc This gives a 1-page summary of how an Excel spreadsheet serves as the hub to manage and tune the inline subtitles, and flag those that need an SRT treatment. SRT is then covered in more detail, as is preparation of an FM for testing the results and releasing them for incorporation into TDM: Subtitling Overall Workflow, SRT, Testing (Jack - June 2023).docx The "Explained" Doc This concentrates on the latest version of the spreadsheet, beginning with its instantiation from an Excel template, followed by population of the first four columns with program-generated data and with strings copied from the vocal set. Manipulation of each subtitle, and its affect on generated column info and your decision making, is then covered. Finally, export to a text file and further text editing creates the content needed to be incorporated into the testing FM: Explained - SubtitlesTemplate(v5) & AverageJackSubtitles.docx
  4. The subtitles for the Average Jack vocal set is now available: testSubtitlesJack.pk4 Subsets of the Average Jack vocal set are defined for civilians, guards, beggars, cooks, labourers, and merchants. As usual, the testing FM is used as the vehicle to provide these subtitles for eventual incorporation into TDM. Statistics There were 388 subtitles. Almost all were inline. Only 12 were SRT; these were all two-message, except 1 was 3-message. Of the inline, 52 required a -dx extension of duration, as follows: 31 in the range 0.25 to 0.49 second. 17 at the cap (by policy) of 0.50 second. 4 worse-case fast-talkers, raised slightly beyond the cap. One of the cap-exceeders also needed a word dropped (non-verbatim). Corresponding Excel File AverageJackSubtitles.xlsx The final form of the Average Jack Excel spreadsheet was also retained (without data) as Version 5 of the evolving Subtitle Template. This and documentation about its spreadsheet/template usage will be available shortly.
  5. Sorry, I was only reading the static code with limited understanding. It references the idActor class, so which does include the player, so it would seem it should work with the player. If it doesn't, it probably needs someone with the code in the debugger (i.e., not me) to figure out why. Yeah, but then the AI wants to move on it's own, so how can it be bound to the player without messing the player up? Sounds like a 3-legged race!
  6. Getting FollowActorTask to work with the player is probably a good bugtracker request. BTW, I was curious about the behavior. It seems the follower gets as close as 60 units by walking, then stops. If the distance is over 480 units, the follower runs until within 180, then resumes walking. Given by these constants: #define DISTANCE_FOLLOWER_REACHED 60 #define DISTANCE_FOLLOWER_CATCHUP_DISTANCE 480 #define DISTANCE_FOLLOWER_CLOSE_ENOUGH_TO_STOP_RUNNING 180 I don't know if there's a means to tell the follower, "stop following, go to some path node".
  7. Possibly the reason this doesn't work is because the FollowActorTask code screens out actors that are NULL, AI_DEAD, or AI_KNOCKEDOUT.
  8. 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();
  9. 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.
  10. 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?
  11. 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.]
  12. 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>"
  13. 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.
  14. 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.
  15. 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.
  16. 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 "."
  17. 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).
  18. Probably not enough to go on, for anyone to say. But it's great that you quickly found a way forward.
  19. 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.
  20. 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.
  21. 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)".
  22. 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.
  23. Now that I think about it, "duration" needs to be expressed in terms of each srt phrase. So the equation you gave is good for a single-phrase srt that starts at time 0. More generally: start = phrase start time (within clip) stop = phrase stop time diff = stop - start In most cases: d = diff For the final phrase, there is this constraint: stop = min(LastMessageEndTime, SoundDuration + tdm_subtitles_durationExtensionLimit) But are these globals also applicable to SRT? the 1.0 second lower bound (I was calling L) the 0.2 extension (I was calling X) BTW, how are overlapping time ranges within an SRT handled?
  24. Good to know! Since SRT now has it's own way of extending (using end time of last phrase), there is probably not a need for -dx with srt. Hmm, I wonder what the calculation of d is for SRT. Probably could use this variable: e = end time of last phrase within srt Then maybe redefine variable x as: x = e - c In this case, x could be negative or positive. Then tie it in to the 3 internal globals. Maybe differs from inline.
  25. OK, I would express this as: d = min(max(c + X, L), c + U) if x not defined d = min(max(c + x, L), c + U) if x defined (where x > 0) In this formulation, if the user chooses to set the maximum extension U to zero, then the values of x, X (default 0.2), and L (default 1.0) have no effect. Soon I hope. I can't finalize any more vocal sets barks until then. I'm not clear how parsing is dependent on line breaks here. I mean, this would be OK: inline "say1.ogg" "Hello, world" -x 0.3 inline "say2.ogg" "Goodbye" That said, I'm not wedded to "-x", but I would very much like to have the extension value either part or adjacent to the inline statement it modifies. Ideas: inline "say1.ogg" "Hello, world" "" // last parameter is no longer optional, but if "", then treated as if not given or inline "say1.ogg" "Hello, world" inline-extend 0.3 // or maybe inline-extend "say1.ogg" 0.3
×
×
  • Create New...