Subtitles - Possibilities Beyond 2.11

[Geep]

21 hours ago, stgatilov said:

I think we should move all the "(sign)" and "(clear throat)" to Effect level and add one more level to the menu. I definitely don't need to see them on my screen.

I know we disagree on what an "effect" is. To me, it's a non-human sound. So an arrow hit, or a raven call. Primarily to benefit low-hearing players.

I would be fine with having a fourth category, between speech and effect. Let's call it maybe "vocal sounds". Here would go the barks that contain zero words. So, snores, cries of pain, some mutters; barks currently translated as just "(sigh)" or "AAiiee"

In the short term, if you just fully implement 3 categories, but rename the 3rd category as "vocal_sounds" (or "vocalizations" or whatever), so there would be a "verbosity vocal_sounds" in .subs, then I'd be willing to redo the barks subtitles to use that.

[Geep]

2 minutes ago, datiswous said:

Some subs have sugestive text, like what the tone of the voice is. Is that something that could be added as an option?

Yeah, I tried to do that sparingly. It's that low-hearing/audio-off vs normal-hearing/audio-on tradeoff again. Mostly did it when the text itself could be interpreted differently depending on tone. Like sarcasm.

Current mechanism would make that hard to add as an option.

[datiswous]

Well if we add a category hearing impaired then a different set with these additions could be loaded. I thought the ai-barks are mostly made for understanding the speach for non native English players.

[Geep]

On 1/24/2024 at 12:27 PM, stgatilov said:

Try to lower scale 2x, maybe then it will pick up the _12 version.

Hmm, interesting. The _12 version appears to be picked up at textscale of 0.15 or lower. So you'd have to get down to appx 7 pt type to start using the _12 as source, given my understanding that textscale 1.0 = 48 pts. Kinda baffling.

[Geep]

5 hours ago, datiswous said:

Well if we add a category hearing impaired then a different set with these additions could be loaded.

Sure, and a similar mechanism, not yet existing, could load translated subtitles, for Polish, Czech, etc. Sounds like 2.13+ to me.

 

5 hours ago, datiswous said:

I thought the ai-barks are mostly made for understanding the speach for non native English players.

That is the main use case at this time. My own desire is not to limit it to that.

[Geep]

On 1/23/2024 at 3:41 PM, snatcher said:

Widget removed (too many things to focus on)

I like the widget, but I'd love it to be an optional thing, toggled on/off by setting and/or CVar.

[stgatilov]

15 hours ago, Geep said:

I know we disagree on what an "effect" is. To me, it's a non-human sound. So an arrow hit, or a raven call. Primarily to benefit low-hearing players.

I don't see any purpose in distinguishing human and non-human sound.

If I am non-native speaker, I want to see subtitles with words only, because that's what I have trouble understanding.
The only reason to see non-word subtitles is that I don't hear sounds for some reason (sound turned off, no speakers, hearing impaired). It does not matter who makes this sound.

[Geep]

On 1/26/2024 at 3:20 AM, stgatilov said:

I don't see any purpose in distinguishing human and non-human sound.

It's another aspect of, over time, tailoring the degree of subtitles shown to reflect the needs and preferences of the individual player. I think some low-hearing/audio-off players might appreciate brief soundscape descriptions, including weapon sounds; others would find it clutter. I understand that distinction is not personally of interest to you.

For now, a fourth category is just theoretical, not a 2.12 item. I'm just asking for a different description of the existing category, other than "effects", that we can both live with. Something that sounds more human. How about "expressions"?

If we can agree on a term, then I will revise the appropriate barks to use it.

[Geep]

Related to looking into the stray marks associated with Stone font characters... I've noticed that the nominal 12 pt DDS (which as discussed above only kicks in under 8 pt) has only ASCII glyphs... nothing with code points above 127. Maybe that's why the corresponding 12 pt DAT file was not distributed, as a workaround to force the engine to use 24pt instead, because tels never got around to finishing the low-priority aspects of the project.

The 24 pt DDS does have the ANSI glyphs. At a glance, most are fine; a few are a bit ragged. I didn't check compliance and completeness with TDM's character map as given on the wiki. I don't feel ANSI improvement is a 2.12 item.

I've got a test FM to show all the characters. At some point, after refinement, I'll post a link.

[datiswous]

It's a bit off topic, but I post this here for now, maybe useful.

To find all the places where conversations take place, to review subtitles, you can use the following procedure:

1. Use console command listEntities
2. Then search for atdm:conversation_info entities, check their names

(actually, it's easier to just open the map file in a text editor and search for atdm_conversation_info and copy all the names of those entities)

1. Then use command teleport [name of atdm:conversation_info entity]
2. You might have to search the trigger that activates the conversation.

 

Edited January 29 by datiswous

[stgatilov]

4 hours ago, datiswous said:

1. Use console command listEntities
2. Then search for atdm:conversation_info entities, check their names

You can run listEntities *conversation_info* if this is part of the name.
I'm not sure how it works, but I know it works when you want to filter by substring

[MirceaKitsune]

An issue worth mentioning I'm sure others have observed: When reading a readable, subtitles of nearby AI can cover it and make it harder to read the text. Can be quite annoying, would definitely layer them behind readables and the inventory menu and so on.

Edited January 29 by MirceaKitsune

[datiswous]

10 hours ago, datiswous said:

To find all the places where conversations take place, to review subtitles, you can use the following procedure:

This actually doesn't work if mappers don't place these entities close to the actual conversations.. Well, it was worth a try.

[snatcher]

13 hours ago, MirceaKitsune said:

An issue worth mentioning I'm sure others have observed: When reading a readable, subtitles of nearby AI can cover it and make it harder to read the text. Can be quite annoying, would definitely layer them behind readables and the inventory menu and so on.

Aren't subtitles, by their nature, supposed to be neutral to whatever that is going on onscreen?

[datiswous]

13 hours ago, MirceaKitsune said:

An issue worth mentioning I'm sure others have observed: When reading a readable, subtitles of nearby AI can cover it and make it harder to read the text. Can be quite annoying, would definitely layer them behind readables and the inventory menu and so on.

Yeah tdm.subtitles.gui says:

Quote

 * stgatilov: This GUI is always displayed in-game as topmost overlay

But maybe this is not good?

Or maybe subtitles should be disabled during (some) gui overlays?

[Geep]

59 minutes ago, datiswous said:

Or maybe subtitles should be disabled during (some) gui overlays?

Maybe it would be possible for the user to just bind a hotkey to toggle subtitles on/off?

[MirceaKitsune]

5 hours ago, snatcher said:

Aren't subtitles, by their nature, supposed to be neutral to whatever that is going on onscreen?

I can see that as a design choice, but the practical problem is pretty striking: If you're looking at a readable and an AI mutters something nearby, the subtitles will cover the text on your readable. It's the game's equivalent of someone putting their palm in front of your face while you're reading a book. Since subtitles are secondary, layering behind readables would make sense... or even better, disable subtitles while readables or the inventory menu are open.

[Geep]

File Update for Improved Subtitle Font

As requested a while ago, to address the stray marks and other problems seen with current subtitle font, Stone, I am providing a short-term fix for characters in the printable ASCII range 32-126, using corrected metadata:

fontimage_24.dat

This is intended to replace tdm_fonts01.pk4\fonts\english\stone\fontimage_24.dat
No change is needed in the related  .dds files for this.

Briefly, problems with stray marks found to the left of a character were due to picking up pixels from an adjoining character in the glyph bitmap dds files. Adjusting the location of the source box and related metrics fixed these. Affected were: % C E T W Y |
The | character also got improved spacing, as did J
Finally, the entirely screwed data for the angle brackets was corrected.

This coming month I hope to work up a wiki page with diagrams to better explain what I learned about the mysteries of the idTech4 font .dat and .dds files.

To see what the results look like with corrected fontimage_24.dat in place (as an override), here is my testing FM:

testSubtitlesASCII.pk4

A longer-term fix (beyond 2.12 release) would also address ANSI and TDM-specific-mapped charaters in the range 128-255. To look at that, I have a similar experimental tester for ANSI (unripe to release). It shows substantial issues in that range. And then there's also consideration of fontimage_12.dat and fontimage_48.dat. And the russian-character variant.

[Geep]

Anyone have a working link (or can create a link) to the modified version of ExportFontToDoom3 executable? This 2009 version was created by Crispy, to handle 256 chars instead of just 128. It was released in this forum post:

 the dark mode readables ttf fonts

The following links to it are now dead:
- crispy's original release: http://www.inventivedingo.com/stuff/exportfonttodoom3_modified.zip
  This is what's listed at the bottom of Font Conversion & Repair as as "Fixed version of ExportFontToDoom".
- Hyeron's 2009 upload: http://www.4shared.com/file/151870191/d47d0e16/exportfonttodoom3_modified.html
- tels 2011 mirror: http://bloodgate.com/mirrors/tdm/pub/exportfonttodoom3_modified.zip.

No luck with wayback machine, github, sourceforge, either .exe or source.

(Source & exe for unmodified version from Grant Davies is in hand.)

[nbohr1more]

21 hours ago, Geep said:

Anyone have a working link (or can create a link) to the modified version of ExportFontToDoom3 executable? This 2009 version was created by Crispy, to handle 256 chars instead of just 128. It was released in this forum post:

 the dark mode readables ttf fonts

The following links to it are now dead:
- crispy's original release: http://www.inventivedingo.com/stuff/exportfonttodoom3_modified.zip
  This is what's listed at the bottom of Font Conversion & Repair as as "Fixed version of ExportFontToDoom".
- Hyeron's 2009 upload: http://www.4shared.com/file/151870191/d47d0e16/exportfonttodoom3_modified.html
- tels 2011 mirror: http://bloodgate.com/mirrors/tdm/pub/exportfonttodoom3_modified.zip.

No luck with wayback machine, github, sourceforge, either .exe or source.

(Source & exe for unmodified version from Grant Davies is in hand.)

Try sending a chat to Tels. It will send an alert email and he may respond ( he visits on rare occasion )

[Geep]

I've just been reading through some old forum posts about correcting fonts. One of the points Tels makes is that, if correcting a font used in readables, you need to avoiding changing any character's spacing (I read this as xSkip value), to prevent changes in existing FM readables with that font.

I suspect this advice is too conservative. You want to avoid enlarging an xSkip, because the resulting changes to wordwraps could potentially lead to line or paragraph truncation.

Making an xSkip smaller could lead to wordwrap changes, but these IMHO would be unlikely to be harmful.

In that regard, here's the situation with my changes to english Stone fontimage_24.dat (see a few posts previous as File Update for Improved Subtitle Font). Only a few characters got altered xSkips. Of those, the angle brackets were unlikely to be used in an existing readable, because they showed garbage glyphs. The "|" was xSkip-shortened, but also unlikely in readables. Only the badly centered and so xSkip-shortened "J" is thought to have potential to affect existing wordwraps.

I have argued here that xSkip shortening is OK. However, I'm willing to revert spacing changes for "|" and "J" if people feel strongly otherwise.

 

 

[stgatilov]

On 2/7/2024 at 4:18 PM, Geep said:

I suspect this advice is too conservative. You want to avoid enlarging an xSkip, because the resulting changes to wordwraps could potentially lead to line or paragraph truncation.

Some GUIs use some kind of pseudographics.
Reducing the spacing also breaks such readables.

[Geep]

Hmmm, interesting. But Stone is not a monospaced font, so trying to do pseudo-graphics using Stone (if that was indeed what was used) would already be pretty difficult.

[stgatilov]

4 hours ago, Geep said:

Hmmm, interesting. But Stone is not a monospaced font, so trying to do pseudo-graphics using Stone (if that was indeed what was used) would already be pretty difficult.

Just add spaces until it looks as you want, that's it

[datiswous]

Do subtitles for voice audio in non-video briefings actually work?

I have an instance where I can't get them to show up. Or I'm missing something.

Edited February 12 by datiswous