Geep

I don't recall that idea being implemented, whether based on distance or volume. I think - to an approximation - if you can hear the sound when it starts playing, however faintly, then you get the subtitle. Otherwise, there's a problem. Suppose you have a distant guard running towards you... you want to trigger the subtitle even when faint, rather than lose it entirely. Perhaps there's some way to make it work OK. Dunno. Otherwise, for now, if you aren't suppose to hear the sound, maybe in some cases you can set its shader's max distance to be smaller.

stgatilov I presume the speaker sources have overlapping max distance spheres, and all are triggered to start at the same moment. If the player is in an overlap location when triggering happens (and so can hear the same monologue start from multiple sources, although probably without realizing it), then multiple subtitles appear. If the player is in a non-overlap location when triggering happens, but moves into an overlap location while the monologue continues, I'm guessing the extra subtitle would not appear. (Could be wrong about this.) In any event, this is a common speaker setup (although most often with looping sounds). @stgatilov would know better, but I think a reasonable restriction would be to enforce a prohibition on multiple subtitle slots starting the same subtitle (i.e., sharing a subtitle path/name) "at the same time" (e.g., a frame or 2), irrespective of source. Probably that would be enough. Don't want to have to calculate whether sources are part of an overlap. Or look at whether sources are distinct and/or static (see next pp). In my subtitle test FMs, I have a single static sound source, but if desired can trigger multiple recurrences of the same monologue with multiple button presses. The button presses and so monologue instances are offset in time. I see that as a feature, not a bug. So the prohibition on duplicate subtitles "at the same time" would be appropriately constrained. If you had two nearby instances of the same guard model, and they emitted the same bark at *exactly* the same moment, you'd only see one subtitle. Probably rare and not a problem. We'd have to rethink that if there was choral singing.

I wonder if you could suppress response temporarily on nearby guards using SetAlertLevel or SetAlertGracePeriod script functions

In general in programming, it often indicates you've called a function from within itself (e.g., recursively), and didn't provide any way to stop the recursion. Sometimes more than 1 function is involved in the endless call chain.

Could you make the ragdoll a friend instead of a neutral? Maybe that would work.

I just posted another release to https://bugs.thedarkmod.com/view.php?id=6543 for incremental improvements to 3 more fonts. I've now touched all the ASCII-only fonts (the majority), and next will start looking at the remaining fonts for which the title of 6543 - "Change TDM codemap to add 2 new characters" - actually applies.

Both New Job and Tears of St. Lucia use trigger_look and ai_trigger_look. Others I'm aware of that use trigger_look include my airpocket and Goldwell's The Accountant 2. Probably lots more.

datBound 1.3 Released Bug fixes and more visualization options, the latter prompted by working with the odd-metrics Medusa font. Details & downloads as usual at https://wiki.thedarkmod.com/index.php?title=DatBounds

FYI, I just posted a proposal to drop the 12pt size of fonts (in DATs & DDS’s) from the TDM 2.13 distribution.

A Proposal to Drop the 12pt Size of Fonts (in DATs & DDS’s) from TDM 2.13 Distribution I’d like to suggest distributing only 24pt and 48pt sizes going forward. Reasons are as follows: 12pt is little used. It appears that none of the readable or sign prefabs come with a .gui with a textscale value (i.e., under 0.15) that would invoke 12pt glyphs. Engine wouldn’t care if it’s dropped. If an FM-specific .gui used a textscale that would ordinarily invoke a font’s 12pt glyphs, but those files are not present, it would automatically switch over to 24pt instead. This is a well-worn functionality. 12pt coverage of codepoints is unimpressive. Generally, ASCII-only at best. Provided 12pt glyphs are often worse-looking than scaled-down 24pt glyphs, particularly on modern screens. The traditional case for 12pt was that, when generated from TTF, it could take advantage of small-scale “hinting” to make better tiny bitmaps. Maybe some fonts do that successfully; I just looked at 12pt Camberic in detail, and there are a number of glyphs that are crap. Nowadays, with higher-rez screens than Doom days, passing it through the 12pt bitmap before scaling to the screen seems like a quality bottleneck. It’s not worth the effort to make 12pt fonts better. This is the most important point. Tweaking glyphs and expanding codepoint coverage (e.g., for missing or European characters) is slow work. That effort with DATs & DDS’s is better spent on 24 & 48pt.

BTW, this is also covered in the wiki's DDS creation article.

For a new FM, if you limit yourself to readables that use Stone, Carleton, Carleton_condensed, or (more limited) Treasure_map, then your translation can include and show European characters. However, that won't help your dream... The translation system is to show the language the user-selects, not what the mapper wants at particular locations. Probably you'd have to burn text into images instead, like an in-game map. And then you can have Asian, Arabic, and the artist formerly known (and I guess known again) as Prince.

Refont v 2.1 is released, and available through Refont/Downloads. The main changes are detailed in that wiki article's much-revised section on "Errors, Warnings, and Auto-Corrections". Briefly, better code for these issues was first ported from datBounds, then reworked to boost coverage and consistency. Testing and incremental improvements of this was done by DAT --> REF conversions while I marched through TDM's 2.12 font corpus. Highlights: Checks that font metric values are in expected ranges. Checks if character bounds (s, t, s2, t2) expressed as 0..1 floats, can be expressed exactly as 0..256 ints. Distinguishes between minor & major warnings. Minor = very-slightly-off conversion from float to int. Cross-checks of (s2-s) vs imageWidth, (t2-t) vs imageHeight vs height. Always generate REF character bounds values (i.e., coord_s, etc.) as ints, never as decimals. When generating a REF file, for certain problematic line items, optionally append a comment starting with "// WARNING:". Adds options -scaling_ok, -no_warn_comments.

As one debugging technique you might try: just give the Player_position some fixed coordinates on-screen, and try to pass some content into the "text" (e.g., instead of the "X") from your script.

Maybe have your script call inventoryHandle=$player1.getInventoryOverlay(); ?

Example of handle use follows. You might consider using the atdm_message entity, and showing the map through that. It has the advantage of already having a "show" time-out-if-not-clicked mechanic. Caveat: I didn't test this code "classname" "atdm:gui_message" "name" "atdm_gui_message_my_map" "comment" "Slide of map. 'show' is maximum seconds if user doesn't click. 'lines' & 'text' are ignored." "gui" "guis/my_map.gui" "show" "10" A script to use it might be like: void show_map() // called from some external trigger { sys.trigger($atdm_gui_message_my_map); tdm_gui_message e = $atdm_gui_message_my_map; // Can takes awhile for the overlay handle to be created and for e.gui to be non-zero. // If spawnarg "delay" is zero, the default, a 0.1 second delay is imposed. float handlenum = 0; while(handlenum == 0) { handlenum = e.gui; // 10 is default overlayHandle for atdm:gui_message layer sys.wait(0.1); } //sys.println("Handle Num: " + handlenum); // MAP IS NOW SHOWING float map_done = 0; while(map_done == 0) { // NOT SHOWN: your code here to calculate xdisp, ydisp; $player1.setGuiFloat(handlenum, "dispx", xdisp); $player1.setGuiFloat(handlenum, "dispy", ydisp); sys.wait(0.1); map_done = $player1.getGuiFloat(handlenum, "MyMapDone"); } } Where associated my_map.gui is windowDef MyMapSlide { visible 1 rect 0,0,640,480 // x, y, w, h. Origin upper-left backcolor 0, 0, 0, 1 // Map clicked: onAction { set "MyMapSlide::visible" "0"; set "gui::MyMapDone" "1"; } windowDef MyMapArt { visible 1 rect 0,0,640,480 // x, y, w, h. background "guis/assets/my_map_art" // If you wanted map to have a transparent perimeter, you could base it on a standard asset like "guis/assets/readables/scroll" // In that case, adjust rect, which can be bigger than the parent if you want to reduce transparent perimeter. } windowDef Player_position { // NOT SHOWN: your code to read "gui::xdisp" and "gui::ydisp" to show player position } }

I think this might be what you want in your .gui: rect "gui::dispx", "gui::dispy", "gui::dispx"+1, "gui::dispy"+40

I've noticed that DAT definitions of the TDM mason and mason_glow fonts use a special type of per-character scaling. I've describe this now in the wiki: https://wiki.thedarkmod.com/index.php?title=Font_Metrics_%26_DAT_File_Format#Per-Character_Font_Scaling In that article, I've also made some minor tweaks in the description of how xSkip is used in practice, based on more experience.

@wesp5, please do add it to your patch in the meantime. Perhaps that would allow it to get a touch more of early testing. Anyone playing under a non-English European language may see fuller use of accents on the names of weapons and stock inventory items. But there could be existing or new problems there to be further addressed, as well as with any FM custom inventory item. Also, any readable or sign that uses Stone font merits inspection. This is true for text presented in English, or (if the player has gone through the considerable hassle of tracking down and installing a pertinent language pack) in other Latin-based languages. Expected problems with latter, requiring freshening of translation to fix, are still-missing accents or (worst conceivable case) changed word-wrap leading to confusing formatting or truncated end of text.

Under the wiki's Refont entry, annotation files are now available that reflect the change in the TDM charmap for 2.13, replacing the duplicate O/o circumflex chars with G/g breve.

Stone 24pt Font Upgrade, June 20, 2024 Final Release With this third and (I hope) final update, Stone 24pt becomes TDM's only font+size that fully provides all 256 characters defined in the TDM custom character map. This last update concludes adding the more difficult characters, chiefly symbols, Icelandic, and remaining accented letters. Plus general overall tweaks to improve character rendering and spacing (as evaluated with testSubtitlesANSI), while preserving important metrics, e.g., xSkip of ASCII alphanumerics. Unwanted overlapping boundaries were eliminated, and things made more consistent. As one example, the metrics for the lower-case "e", and accented characters based on it, were adjusted a year ago to suppress stray marks, but at the expense of clipping the glyphs, making them less stylish. With the added insight now provided by datBounds visualization, it was possible to restore the style while keeping the stray marks away. In summary - 16 new glyphs were created. 64 existing characters got tweaks. These were mostly affecting the .dat, but some glyphs were moved in the bitmap (a little or a lot) to solve various problems. Download: 2024 June 20 Stone 24 Final Font Update.zip As with the prior interim releases, this download is made up of - .dat and 2 .dds files, for distribution/game inclusion .ref [with changes annotated] and .xcf [master source GIMP project, including datBounds layers] The hand-annotations in the .ref file are neither absolutely conclusive, nor necessary to preserve for future work. You may generate a fresh .ref without them from the .dat file by using refont. Enumeration of Changes: There will be some follow-on work, e.g., expressed earlier in this thread in a bugtracker entry.

Release of datBounds 1.2 This fixes a bug with codepoint 255 being skipped. It also adds metadata consistency checking as console warnings. As before, available from the Downloads section of https://wiki.thedarkmod.com/index.php?title=DatBounds

They are reportedly part of Turkish/Tatar (e.g., Crimean)/Azerbaijani. Turkish is one of the 17 languages seen in TDM Settings. They are part of the ISO 8859-3 standard (at 0xAB, 0xBB) and ISO 8859-9 (at 0xD0, 0xF0). EDIT: @wesp5, let me answer more broadly. Like most hobbyists, I enjoy a certain amount of magical thinking. In this case, I'd like to think that improvements to the translation system might grow the potential TDM player base. But as to which improvements... we have no focus groups. Of course, this particular improvement - choosing 2 additional characters - is minuscule. (After I finish the Stone 24pt font work, I hope to formulate and float some more impactful ideas.) EDIT2: https://bugs.thedarkmod.com/view.php?id=6543 lists additional work needed to support 2 new characters for TDM 2.13

As detailed above (see hidden content), 2 characters may be chosen to replace duplicate characters in the existing TDM codepoint map. Since I didn't hear any feedback here, I have chosen: Ğ/ğ, with breve (cup), where Ğ uses TDM codepoint 0x88 ğ uses TDM codepoint 0x98 Why these? Because they are reasonable language-wise, and easy to bitmap-draw. At the moment, I will be doing Stone 24pt glyphs and DAT entries for these characters. I intend to add a bugtracker entry (for assignment to me) for additional work needed to fully support this new mapping

A third option would be to delay the briefing until right after the game starts, and just treat it as a video cutscene, invoked by a script. Then you would have access to the if statements and language cvar you need.