Geep

For the record, here is another version of tdm_subtitles_message.gui and the standard backing field, now improved with the right horizontal padding reduced to 7.5 px, and a new left padding to match, for better visual text centering. I also removed a comment about a possible CVar subtitle_narrowfield_nonstory, which seems less important than the other potential CVars. Beyond that, as you guys have noted, vertical dimensions could be adjusted to improve the appearance of the widgets. I'll try to come up with something concrete next, keeping conflicts with other adjustable-size HUD elements in mind. Another question for you: To cover a case where the backing field is suppressed, should the sector widget interior still be largely transparent, or would translucent or opaque be better?

So maybe new CVars along the lines of the following would do the job for 2.12: subtitleColorR 0.00-1.00 subtitleColorG ditto subtitleColorB ditto subtitleBackground 1/0 subtitleSoundSource 1/0

@snatcher, I meant to mention, I do like your sector sound-source widget. I'd be happy going with that. As to its ring color.... while my personal pref tends toward some color that would contrast with text color, I guess most folks would prefer white, to match the current text color (and likely default if text color is made variable). That would be fine.

I reviewed the Stone font spacing vis a vis padding: Worst-case spacing for Stone 24pt for ASCII lower-case characters = 20 (and "A" is less than this) Scale by 50% to 12 pt = 10 Compress-width of font by 0.75 = 7.5 So I'm thinking a reduced right padding, now 7.5 px, plus a new left padding of 7.5 px to improve centering.

I wonder if you could test 9x versus 4x-diagonals and 4x-non-diagonals? Maybe the extra 5 renders don't add much. There probably is some minor performance effect. I think you're still showing the widget too high, so it seems to be associated with the wrong subtitle. I prefer @stgatilov's original vertical positioning, even though it pushes the widget's lower edge against the top of the caption lettering. I wasn't sure what you where trying to point out as a problem... was it the word wrap? Yeah, the automatic word wrap with centered text can look ugly at times. An FM author can choose to insert a manual line break in that case. I do that routinely all the time for barks. Since padding is part of the background box, sure. It occurs to me now that maybe, to improve the appearance of text centering, the background box should also have equal-size padding on the left. That is, the location and size of the inner box is unchanged, but the outer box is wider and its origin shifted left, so the inner box is centered horizontally within. The padding can certainly be made smaller. I imagine the seed value of 17px was for a worse-case character like "W", that was then rounded up to 20. We could shrink it by: - choosing the seed character as the widest that might actually be at the end of a line followed by space to cause word wrap. Probably "w" or "A". - not rounding up - scaling by the compression aspect ratio I'll try to come up with a new number. No problem here with having the background by default. But recognize there's a compromise between world visibility and text readability. Can't we make it possible to turn the background off for people who hate it so much that they avoid using subtitles because of it? "...visible in all circumstances" may be too high a bar. The simple implementation would be a single CVar that toggles the background on/off and possibly, conversely toggles fake drop shadows off/on.

I will take a look this coming week. In my heart of hearts, I'd rather make "background or not" a user choice. The simple version of that wouldn't be too hard: just a CVar settng the backing field visibility. The more sophisticated version, where no-background implies fake-drop-shadows, requires more thought to make it live with the backing field code.

@snatcher, based on your earlier sample, I see that the horizontal widget positioning in the beta release of tdm_subtitles_message.gui and in my version were both off by 10px to the left. (Probably because the widget was originally wider.) My version corrected here (but not addressing text centering problem):

There's the inner box to constrain the text, and trigger word wrap, and the outer box to show the backing field. These are identical in size and location except the latter is a bit wider, by 20 px. A comment in the .gui code says: // #5914: engine allows overflowing textbox size by one character // maximum character width is 17 at textscale 0.25, so leave horizontal padding 20 on the right So the motivation is to keep the text from never visually exceeding the backing field. However, that extra padding can not be considered when the engine decides the point about which to center text in the inner box Probably a padding of 20 is excessive, even more so now that a width-compressed font is used. That said, there may be something else dominating the anomaly. And the sound location widget is also off-center.

I noticed that too. There is a bit of intentional padding on the right hand side, but this seems too much.

Yes, the backing field shown, while narrower, is still a fixed width for all bark texts, so still wider than ideal for that particular phrase. The width is the minimum needed to safely accommodate subtitle lines up to 42 characters long of 12 pt Stone font.

So true. In that regard, gui code has been available for a few months to create a narrower backing field for barks (i.e., speech verbosity) than for story text. This code has not been included in the beta to date. Perhaps it will take users in addition to me to favor and push for it! If you want to try it, put this code in your FM's "guis" folder as over-ride file "tdm_subtitles_message.gui":

Ah, I see now. The bordercolor code in the gui is just a remnant around the now-transparent backing field.

True. It would require a modification of the engine code. Earlier this year I wrote two experimental C++ utility programs that do the required calculation, for respectively 12 pt Carleton and (scaled to 12 pt) Stone fonts. However, others have expressed distaste, on complexity grounds, to having variable-width backing fields, so I've since been restricting my advocacy to a narrower fixed-width backing field for speech-verbosity subtitles. This outlining isn't really visible in your screen shots; and I'd like to see various color-tone game locations too. I see you use the "bordercolor" attribute for your outlining. I vaguely recall there was some circa-2010 TDM "drop shadow" experiments with (I'm guessing) using this for subtitling, with the Carleton font then in use. (This was before I got involved in subtitling.) Same conclusion: a bit problematic with the given font. So that led to the translucent backing field as an reasonable approach. It would be possible to add a new unicolor font just for subtitles to TDM. There is a roadmap for this, but it's a major project, so TDM 2.13? Agreed. That was part of my motivation for wishing to narrow the width of the backing field. I'm in favor of having settings to let players have more flexibility in the subtitle presentation. That would include font color.

Just too small a gap currently between blocks, to not overlap with something. I think it's better to overlap with the subtitle it's associated with, rather than the one above. The gap could be enlarged, but then 3rd topmost block would be close to screen center vertically, blocking more of the general view. Oval could be further shrunk, but becomes less informative. I guess, with tricky programming, you could suppress the ovals when there are more than 1 blocks shown. Probably no perfect answer.

After you do that, check to see if the now-white ring visually interferes with the white caption font. If so, the ring might need overall thinning. if not, good to go.

Thanks so much. I'll review the spreadsheet starting tomorrow and after any tweaks, export to .subs as inline. Then convert any to srt that need it, and do QA. The usual process, tho possibly a bit slow due to travel/holidays. I've already built a testSubtitlesDrunk to house the subtitles.

The subtitles of The Lady02 vocal set is now available for eventual incorporation into TDM: testSubtitlesLady02.pk4 Lady02 is another noblewoman, somewhat newer and so unmentioned on the wiki. She is a drawling speaker, often indecisive, and given to long musings. Favorite topics are how boring life is for the wealthy, and how to keep men of the household and the maids apart. Lady02 required heavier and more complex use of .srt files than most AI characters, due to: Her slow, rambling monologues Some of the underlying .ogg files were poorly trimmed at the end, so needed compensatory .srt timings. I appreciate the assistance of @datiswous in this effort. Statistics In file fm_root.subs there are 195 inlines, including: 25 with an explicit linebreak, intending 2 lines 170 without Only 1 of these needed an explicit duration extension, to the capped value 0.50 seconds, for 17-20 cps There are 116 SRTs, including: 78 with 1 message (to correct trim problem) 24 with 2 messages 7 with 3 messages 2 with 4 messages 3 with 5 messages 1 with 8 messages 1 with 9 messages Of the 187 total SRT messages, there are: 90 with an explicit linebreak, intending 2 lines 97 without In all, there are 311 voice clips with subtitles, showing 382 messages. Corresponding Excel File Lady02Subtitles.xlsx This is based on Version 6 of the Excel Template for TDM bark subtitles.

I suppose you could split the difference, making the line moderately thin but obvious at the lower edge but vanish at the upper edge, letting the gray interior carry the upper shape. So, I prefer the 3D slope, but am OK without, if that's what others like.

You raised the oval further up from the text, but that will put it atop a different caption text when 2-3 are showing stacked simultaneously. So shouldn't change that aspect of implementation. I see your mockup has a uniform opaque gray interior, rather than translucent. That would be easier to implement and integrate with the backing field. @stgatilov, can you take it from here, with the .tga that @snatcher provided?

I can try to work up a variant design, with a white ring. Do you like the current size of the oval, or prefer my original "blue ring" design, that was wider but slightly less tall? My original design was transparent inside, although the lower-half overlapped the neutral translucent rectangular backing field. I could try to provide the upper-half with a neutral translucency that would approximate the backing field. This would be approximate because the translucency would be provided in 2 separate ways (photoshopped vs. gui). The white line in that case could be very thin on the upper part, because the translucency would also define the shape. I thought it desirable to provide a sense that the oval was really a disk viewed in perspective, so the lower edge is thicker... but maybe you'd prefer a uniform-thickness white line all around?

OK. To confirm Libreoffice compatibility, please download one of the recent completed spreadsheets, e.g., for Critic or Manbeast (links in OP of this thread). Also, you will likely find it helpful to have such a worked example while reviewing the "Explained" doc discussed below. Assuming compatibility, I'll programmatically pre-populate a fresh spreadsheet with .ogg filenames and clip durations for "The Drunk" vocal set (in the vocals04 pk4), and DM a link for that for you. While waiting, please review these two Word docs (see links in OP): "Subtitle Style Guide - Part 1". There's a 1-page summary of main points at start. Skim the rest. "Dec 7 Update of the "Explained" Doc for Spreadsheet Template v5". This details what the two worksheets and the columns within each mean. You will start with the "Compose" worksheet; I will have already filled columns A & B, and C is auto-calculated. Since we have no pre-existing vocal text script for The Drunk, column D will be left blank (TIP: hide it), and column F will be useless. You will start filling in column E, "Tweaked Subtitle". There's lots more to say, but that's enough for now. The spreadsheet I send you will based on Barks Template v6, but it's only trivially different from v5, so the Dec 7 doc should be fine. BTW, there's more workflow that is done before/after your part. If curious or need more context, see: "June 10 Documents Explaining Workflow and Excel Spreadsheet/Template (for AverageJack)"

Not sure what you mean... better centered horizontally? Not overlapping the top edge of the subtitles? Keep in mind that the subtitles can stack 3 up, and the space between them is limited. This constraints both the size of the oval and what overlap may occur with the backing fields. If you had a scaled-down glyph of a talking head (instead of just a central dot), it may be unrecognizable as such. Dunno. The current graphics are stgatilov's version. The movable red square indicator is a re-using of a graphic already used as a frob assistant.

Thanks for that offer. My process is more complicated than that, and involves an Excel spreadsheet to manage the captions, and determine (partially automatically) for each one - if it needs breaking into 2 lines, and if so, where if it needs additional presentation time, using the inline -dx option, and if so, calculates how much if it instead needs to handled as a separate .srt file, instead of as an inline; based on both duration & character count So, if you can work with Excel (and doesn't have to be latest version... mine's a decade old), and are willing to read some Word docs, then you can help at the transcription into Excel, at least for 1 of the vocal sets remaining. Otherwise, I'll have to pass on your offer.

Work is once again underway on Lady02 vocal set. To deal with untrimmed .ogg files (discussed earlier), the srt-based method of ending captions early will be used.

Regarding the earlier discussion about telling when an objective is complete from script, I just added a brief entry under the wiki's "Objective Editor/FAQ & Examples" called "Determining an Objective's Current State from a Script" As for as Stim/Response... I often find it hard to wrap my head around too. I don't recall writing anything very authoritative about it, but maybe in some narrow context? Or maybe @JackFarmer, you were remembering someone else's explanation? So, I can put it on my list of possible wiki topics for 2024, but it would require a lot of research by me, and likely @Dragofer or others could do it better & quicker.