Jump to content
The Dark Mod Forums

Geep

Member
  • Posts

    1066
  • Joined

  • Last visited

  • Days Won

    57

Everything posted by Geep

  1. 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();
  2. 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.
  3. 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?
  4. 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.]
  5. 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>"
  6. 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.
  7. 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.
  8. 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.
  9. 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 "."
  10. 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).
  11. Probably not enough to go on, for anyone to say. But it's great that you quickly found a way forward.
  12. 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.
  13. 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.
  14. 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)".
  15. 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.
  16. 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?
  17. 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.
  18. 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
  19. Actually, there are additional possibilities where X and x are not additive, but alternatives: a.4) d = max(c,L) + min(X,x,U) a.5) d = max(c,L) + min(max(X,x),U) a.6) d = max(c,L) + min(x,U) // iff x > 0. In that case, x overrides X b.4) d = max(c + min(X,x,U), L) b.5) d = max(c + min(max(X,x),U), L) b.6) d = max(c + min(x,U), L) // iff x > 0. In that case, x overrides X
  20. @stgatilov, I started to apply the inline "-x" option for extra time to a vocal set, but then realized that I needed to know better how it worked, in order to choose appropriate values. So some questions: 1) Does the inline -x work... a) the same for "story" and "speech" verbosities b) differently If (b), the next questions will need to be answered twice. I'm going to state these in mathematical terms, summarizing the behavior of the algorithm and reflecting the order in which values are combined. All variables are in seconds. c = length of a given sound clip x = inline -x value for extra time. Should be positive. Zero if not given. d = calculated length of subtitle duration L = global giving a lower bound on subtitle duration. Default is 1.0 X = global giving an extension to subtitle duration. Default is 0.2 U = global giving an upper bound on X. Default is 5.0 2) When there is no value of x, which equation describes the algorithm's behavior? a) d = max(c,L) + min(X,U) b) d = max(c+min(X,U),L) 3) When there is a valid value of x, the equation becomes... a.1) d = max(c,L) + min(X,U) + x a.2) d = max(c+x,L) + min(X,U) a.3) d = max(c,L) + min(X+x,U) b.1) d = max(c+min(X,U),L) + x b.2) d = max(c+x+min(X,U),L) b.3) d = max(c+min(X+x,U),L) Thanks for help with this.
  21. Books are out of scope for this thread, which is just concerned with subtitles. As an aside, because of the way book text is laid out (separate independent overlays for "title" and "body" text), changing the font from what the FM author provided would tend to make a mess.
  22. @datiswous, I'll try to incorporate Skip Forward/Backward buttons (or whatever I end up calling them) into the upcoming testSubtitlesWench release. Likely sometime next week.
  23. An update of command-line tool "buildSubtitleShaders" is now available: Win executable C++ source code file With this Feb. 10 version, if you ask for help (buildSubtitleShaders -h or ?), there's an additional option shown: -c counter start value (default: 1). Eases merging results from different sound file folders. As before, comments in the source code file provide full documentation.
  24. Yeah, that is a pain in the butt. The main problem with multiple input folders is that you really want to be able to specify relative paths on the command line (i.e., not just absolute), but then reformulate the paths into the form that TDM wants in the sound shader. I tried to code that earlier, and ended up with a real mess. One of those situations where the more you try to fix, the worse it gets. So I abandoned that attempt. What I could do instead, fairly easily, is to provide another command line option that would let you specify a starting number greater than 1, so you wouldn't have to separately renumber. EDIT: See next item.
  25. ??? If you don't specify the output file, then it writes to stdout. The expected behavior would be you would see the output on the terminal screen, unless you did something like "> my_new_results.sndshd". Are you not seeing that with wine? No, you currently would have to run the program separately for each folder and cut/paste to merge the outputs by hand. Since that's kinda trivial, and programming for multiple input folders less so, probably won't be happening. I'm thinking here you're talking about a "testSubtitle..." FM. So in addition to jumping to a particular soundfile by changing the cursub value in the console, you'd maybe like 2 more in-game buttons, to skip forward and skip backwards?
×
×
  • Create New...