Geep

Sounds plausible. Perhaps you could file a bug report?

You will find windowDef leftPageCurl {.... within each multipage .gui, for example: tdm_gui01.pke\guis\readables\sheets\sheet_paper_print_stone.gui (line 20) I was just using this as a syntax example. I am not responsible for the code itself. As to newish more numerous console warnings: It is certainly possible that some syntax forms that were previously accepted without complaint (at the time I wrote this wiki series) are now causing warnings.

Yeah, but that line is used in a zillion .gui's, for example: tdm_gui01.pk4\guis\readables\sheets\sheet_paper_print_stone.gui(line 124): transition "leftPageCurl::matcolor" "1 1 1 0" "1 1 1 1" READABLE_FADE_TIME 0.5 0; What I said was accurate. But I'll rearrange the text to avoid future confusion.

??? I'm seeing READABLE_FADE_TIME on line 12 of readable.guicode for TDM 2.10 and 2.11, and also the version of 2.12dev I have installed (admittedly not the latest).

What you are describing is a different use case (controlled by the mapper rather than the game player), but worthwhile.

I suppose you could have the player rather than the guard cause the trigger, then somehow check in the script if the guard is being carried or is otherwise in the right place to kill. Possibly too hard to make that robust.

Hm, I wasn't being too serious here, just riffing off stgatilov's note of the weariness of TDM veterans hearing the canned barks yet again. If there is an existing way for the player to suppress the audio of everything except "story" clips throughout the entire game, I'm unaware of it.

@MirceaKitsune, looks like you're in luck: https://wiki.thedarkmod.com/index.php?title=Custom_Death

I wonder if scripting would work. If the AI is $guard1, either $guard1.kill(); or $guard1.setHurt(0); Maybe you'd have to heal first with $guard1.setHurt(1); then immediately kill. Probably your script should check the AI_KNOCKEDOUT flag before some of that, to confirm unconsciousness.

"I think we have an opportunity to enlarge the potential TDM community to include deaf players, or those who like to play games with sound off." Even for the existing TDM players, some degree of customization, e.g., font choice, would be an improvement. Nobody argues with that, provided the bar to expressing need is not too high. Certainly TDMs large number of CVars hints that a bit of complexity has been tolerated in the past to achieve improvements and allow for satisfying individual needs and preferences. The TDM subtitle system I feel was meant to eventually cover all game sounds, so yes. (If you're talking about screen-reader software, it will not understand game context.) That's one of 2 possible methods I mentioned to help implement per-subtitle visual cues. There are no doubt others. It's ok with me if things like cue customization doesn't start to happen until TDM 2.13. I'm just trying to lay out a pathway through the terrain, which sadly seems more fraught than ideal.

@stgatilov, thanks for sharing your thoughts about the original ideas behind the 3 levels, which I had not previously seen put so well. I was surprised that you considered that some of an individual AI's barks might go under "effects" instead of "speech". @snatcher likewise thought that, in effect, an AI's barks should be divided, though draws the dividing line elsewhere. I agree with you about the primary existing TDM audience for subtitles: those players appreciating help with spoken English, specially in dialects. I think partially-impaired-hearing individuals will also benefit. But, given subtitles in TDM and our newly prototyped method of indicating speaker sound source, I think we have an opportunity to enlarge the potential TDM community to include deaf players, or those who like to play games with sound off. This does involve sound categorization and visual cues, beyond just toggling story/speech/effects. Such cues could be universal (seen the same by everyone), or controlled by new options, to accommodate personal interest (or lack thereof). Let me be more specific. Consider the 2-level visual cues that snatcher preferred (while leaving open where to draw the line between the 2, or whether 2 is really too few). Examples of universal+fixed, which for barks could be done by me in the .subs file, are: bracketed vs unbracketed white vs yellow font, done by string markup. (This has significant drawback and limitations). Alternatively, there is categorization performed engine-side and passed to the GUI as one or more variables. The results could be universal, or the passed value(s) could be affected by additional optional settings. Displayed results could be, for instance: white vs yellow font, done by text font color choice Stone vs Carleton font wide vs narrow font wide vs narrow background field two different background tints or opacities colored border around backgrounds, with two different colors (Also, without involving new GUI variables, the engine could add brackets to selected strings) Turning to what additional optional settings might look like, at the basic level, you could just have an option that turns visual cues on or off. So, for example, if the visual cue was font choice, turning the visual cue option to off would cause all subtitles to use the same default font. More specificity is, of course, possible. (Maybe too, stgatilov, you could sneak in a related option to suppress "Just you wait!" audio and only play story clips!) If the barks were to be subdivided by the engine into (in this discussion) 2 categories, it could be done by a new per-line option in the .subs file, e.g, -cue 1. Or the categorization could be done entirely automatically on-the-fly by the engine, at the moment it's looking at the AI's current state & most recent state transition, in order to select a sound shader to play. It would probably use the standardized state-transition names as found in the AI .def files, e.g. "snd_foundDeadMale" rather than AI-specific sound shader names. So there would be a list of "snd_..." to determine when g_cue=1 instead of the default g_cue=0.

I appreciate your desire for simplicity, but since the current system has 3 categories, you are actually proposing to split the barks category, creating 4 in total - "story" (most vital info to know if you are to win) - ai barks, dangerous now - ai barks, not dangerous yet (but ai presence is important to know) - effects, generally ignorable Now, they don't all have to be visually distinguished... maybe 3 & 4 could be shown the same. Dunno.

Effects in brackets might be OK. A concern with color field tint is color blindness accommodation, as well as problems translucency can cause. I guess another idea is to use one font for story, a different one for speech. Instead of making font a user choice. Dunno.

There can be up to 3 subtitles seen at a time, stacked with translucent backdrops. If there are more the 3, then priorities are involved, with "story" highest and "effects" lowest. I agree that distinguishing more important from less important subtitles is desirable. One method was floated (background field width) but maybe that's not the answer. Could be background field color tint. I would not support putting all barks in brackets.

A subtitling capability was developed that offers 3 "verbosity" categories: "story", "speech", and "effects". Roughly, "story" are FM-specific talk clips, while "speech" is for ai barks, and "effects" are more general sounds. "Effects" is not yet exposed as a setup choice, nor are any sounds so tagged. I have never seen an exact differentiation of the 3 categories... which is what the feedback request is about. At the time I started this thread, there was only a few demo phrases tagged as "story" or "speech" and given subtitles. I've made many more "speech" subtitles available for eventual incorporation into 2.12 (and others have done "story"), but I'm not doing that incorporation myself. As to purpose, I surmised they are - - to help low-hearing players - to help players for whom English is not native - to demystify more obscure ai dialects and, in conjunction with visual cues to sound source location (prototyped)... - for players with audio turned off - for deaf players Hope that helps

An alternative view would be to interpret "verbosity speech" as "speech from humans, and noises from all ai that could harm me". That would exclude ravens and horses, but include everything else. Although the player himself and noises from fixed-location machine threats would then be edge cases. Among latter: pivoting security cams ("camgoyles") ticking sounds of mines?

Feedback needed. I plan to do all the "verbosity speech" subtitles for 2.12 (assuming Feb 2023 as target date), while leaving any "verbosity effects" for later. So I need a consensus on what we would like to see covered, or not, by "verbosity speech". Importantly, when you turn on "speech" subtitles in TDM, what would you expect to see or not see? Easier cases: manbeast (hear at tdm_ai_humanoid_beasts02.pk4\sound\voices\monster\manbeast) I would call as "speech", because it's still spoken and in English. steambots and automaton (tdm_ai_steambots01.pk4\sound\sfx\ai\) I would call as "effects", because of the non-language sounds & no vocal cords. Animals and Monsters [no human language spoken; so probably "effects"?]: raven (tdm_sound_vocals04.pk4\sound\voices\animal\) elemental (tdm_sound_vocals04.pk4\sound\voices\monster\elemental) spider (tdm_sound_vocals04.pk4\sound\voices\monster\spider) horse (tdm_sound_vocals05.pk4\sound\voices\animal\horse) zombie (tdm_sound_vocals05.pk4\sound\voices\undead\zombie) werebeast (tdm_ai_humanoid_beasts01.pk4\sound\voices\monster\werebeast) Edge cases: player (tdm_sound_vocals01.pk4\sound\voices\player) [mostly grunts, groans, some hmmms] revenant (tdm_sound_vocals05.pk4\sound\voices\undead\revenant)[a little english, a little latin, and much unintelligible/multiple-voices/sounds/reverb]

The subtitles of The Simpleton vocal set is now available for eventual incorporation into TDM: testSubtitlesSimpleton.pk4 "Vocal Script: Simpleton" says that he is "an uneducated, simple character, who speaks in a slow, measured voice. He goes about his life dealing with the here and now, and doesn’t think much about anything beyond what he’s doing. He could be a simple servant or labourer. For inspiration, think of the pirate with the wooden eye from 'Pirates of the Carribean', or Hank Hill from 'King of the Hill'. This is the default voice for common townsfolk, so don’t give him too much personality, or over-exaggerate it for laughs (even though some of the lines are played for comedic value)." Statistics In file fm_root.subs there are 496 inlines, including: 52 with an explicit linebreak, intending 2 lines 444 without Of these, 59 with explicit duration extensions, as follows: 37 from 0.25 to 0.49, for 17 cps 22 capped at 0.50 seconds, for 17-20 cps There are 3 SRTs, all representing vocalized tunes. Each has 2 messages, with a 2-second start message and later 2-second end message. None required an explicit linebreak. In all, there are 499 voice clips with subtitles, showing 502 messages. Corresponding Excel File SubtitlesSimpleton.xlsx As usual, this is based on Version 5 of the Excel Template for TDM bark subtitles.

On the func_damage entity, set spawnarg def_damage with the name of the desired damage entity; see tdm_damage.def for name choices.

I hope there is some solution for the crashes you reported. In my Away 0: Stolen Heart, the storyline has the player in disguised as a gentleman, which (chiefly due to custom atdm:team_relations entity) fools the civilians but not the guards, who are said to be able to recognize the face. My needs were easier than yours: that disguise doesn't change throughout the game, and you don't really see it except in a video cut-scene, where much can be faked.

Is there some reason that the custom head can't be just given to the player at the outset (in some def file), and not swapped? Might be more stable, I'm guessing.

To get a pure black background, one way is to use the view pane in the "Choose Model" picker. In the controls under the view pane, select "Lighting Mode" instead of "Texture Mode". You'll want to turn off grid lines there too, and play around with the filter options. I see there are helmets (without heads in them) under models/darkmod/wearables/headgear/

I noticed that there was a pre-existing "carleton_condensed" font, and was wondering how it compares with the other versions I've floated as subtitle font options. So here's an eyeball comparison, all with the same gui scale factor of 0.25. In this shot, from top to bottom are: "carleton_condensed" "carleton" "carleton@aspect=16:9" So "carleton_condensed" is intermediary between the two. If "carleton" is considered width=1 (designed for 4:3 screens), and carleton@aspect=16:9 is width=0.75, then "carleton_condensed" is maybe width=0.875 So, since it's pre-existing, it could be another reasonable subtitle font choice... maybe called in Settings "Carleton, Medium Wide"?

For taking a screenshot of an item to use as an HUD icon, sometimes it's easier to do that in DR (e.g., in the head model view), where you have better shot control than in TDM, even if the lighting is a bit unrealistic. Fakey lighting for an icon is often not a problem.

I agree this would be best in conjunction with rollout of automatic box sizing. Just looking ahead to that being available. I suspect many players would appreciate some font choice. BTW, if we were to implement font choice *before* automatic box sizing, we would just stick with the box size for the widest font (that would be carleton uncompressed, the 2.11 default), and the other 3 proposed font choices, being less wide, should fit. (I know that to be the case for English version of these fonts; possibly needs to be confirmed for distributed Russian version too.)