Geep

BTW, the Perl script I18N.pl expects only an integer value after "#str_". Could be modified (or deprecated).

That is one reason. That is 2 more reasons. You'd like a script that, if you had to run it again, would "do the right thing". Unfortunately, that right thing is very hard to program, and needs IMHO to be both bidirectional and with a better method of string version control, to support both the FM author's updates and potentially multiple translators. Yes, another reason. Currently, it is my understanding that updating an FM (from the non-converted copy) and running the conversion script again causes mis-alignment of newly-generated #str values and previous .lang #str values. Another important cause of "nobody is making these language packs" is that Dark Radiant at best tolerates converted FMs. It offers no special translation support, as expressed in this code comment: "...we don't have any support for parsing the mod-specific translation data...." [from DR's DifficultySettingsManager.cpp]. That's where we are now. So officially give up on FM Western translations? Or improve the #str system to make it work for everyone? Or invent a new system? A new system. What would that look like to the FM author? To a non-author translator

Then your experience is different than mine. I just recently downloaded a very old mission, The Outpost, that is listed as having German, French, Italian translations, to test out language capabilities. It was not converted (no "#str" found in .map file). Nor was there a language pack included (at least not from thedarkmod downloader).

BTW, my concern about #str values is about those distributed in FM-specific .lang files. For standard assets, where the info would be in tdm_base01.pk4/all.lang and its derivative .lang files, I guess that's less of a problem. In that case, maybe, instead of using a #str_<number>, you could use a fixed prefix, like: #str_shouldered_<english_name> or #str_moveable_<english_name> That is, like #str_shouldered_chair A general string like that might be used with multiple different chair models, as you intended. If the author overrode the shouldered name with a non-#str name: #str_shouldered_chair --> cushy chair with clue then any translated general strings would be hidden, and just the English version shown.

Interesting idea. Not sure about my upcoming time availability to help. A couple of concerns here - - I assume the popup words uses the "Informative Texts" slot, e.g., where you might see "Acquired 80 in Jewels", so it likely wouldn't interfere with that or with already-higher subtitles. - There are indications that #str is becoming unviable in FMs; see my just-posted: https://forums.thedarkmod.com/index.php?/topic/22434-western-language-support-in-2024/

In considering my possible upcoming TDM projects, such as upgrading some fonts to Latin-1 or "TDM Latin", I reviewed the current status of support for European Latin-based languages. Basically, for FMs, the translation system has fallen into disrepair and disuse (or perhaps kicked into the grave). Neither "converted" (i.e., #str using) FMs nor Language Packs are now being maintained and distributed by thedarkmod.com. As to other sites, for Cyrillic/Russian, DarkFate provides such resources. Are there any such sites in native Western European tongues, say, German, French, Italian, that likewise offer translated TDM FMs? So, turning back to thedarkmod.com, questions - - is Western Language support (outside the main menu system) officially dead? - if so, maybe it's time to stop pretending otherwise. - if not, should the converted #str system be revived, with better infrastructure? - or an alternative translation system be devised... if so, what? I'm just trying to identify work worth doing. (I started to draft a doc with a litany of problems with Western language support, and possible sub-projects to address them, but TL;DR. And really, not pertinent if support is considered dropped.) Thanks for your thoughts.

This last month, I've been exploring TDM's font situation, and improving the documentation as I go. In the wiki, "Font Conversion & Repair" was rewritten, with parts broken out and expanded as: Font Files Font Metrics & DAT File Format Font Bitmaps in DDS Files ExportFontToDoom3 Q3Font Refont As announced earlier, that last item is a new C++ console utility for revising font metrics in DAT files; essentially another alternative to Q3Font and Font Patcher. It now has additional functionality that provides font-coverage analysis. A summary of current results across all TDM fonts is reported in the forum thread "Analysis of 2.12 TDM Fonts". Also, refont allows its human-readable outputs to be decorated with an annotation for each character (out of 256 codepoints). Associated with that, I've just created and released 4 annotation files: 1 Cyrillic version for TDM's russian map 3 variants for TDM's custom english/european char map. One of the variants was derived from another new mapping file that is now available from existing wiki article "I18N - Charset". Within that file is a list, in a standard format, of the 256 TDM bitmap codepoints mapped to the corresponding Unicode U+NNNN value and name. This may be useful in defining TDM's mapping to TTF font editing programs. For all these wiki pages mentioned, I imagine there will be additional cross-links and tweaks. But pretty much done.

I've added your much better description of the process to the existing mention of resizing speakers in https://wiki.thedarkmod.com/index.php?title=Setting_Up_Speakers#maxDistance%2F_s_maxdistance

To the "Path Nodes" wiki article, I've added a few sentences about path_follow_actor. It mentions that it currently doesn't support the actor being the player, and has pointers to the new bug report and the workaround given in this thread. The entry for path_follow_actor in the Entity Database now reads "... actor (= other AI, not player)...

That was just a "nice to have", not "must have". No worries. Nor I.

Thanks, looks useful. Except datetimes look like all Jan 24, 2024, presumably when the archive was formed, not when file edit was done. So it goes.

I thought that might be the case. I don't believe I can access the SVN. Could you zip up all the font stuff you can easily find in that archive and send a link to me? TGA/DDS, even TTF for Stone, Mason, Carleton, etc., etc. No hurry. Thanks. P.S. Try to preserve file timedates

I'm guessing there's a way to do that. Then back to DDS to distribute. That process would still cause an extra generation of quality loss, but at least you'd have a TGA in hand, for iterative editing without cumulative losses. But maybe first ask long-time TDMers to hunt for archived TGAs.

Because DDS is a lossy format, every direct edit of a DDS file may reduce its quality slightly. So that means either: hunt down the corresponding TGA file with the same timestamp otherwise, edit the DDS as few times as possible. In the case of Stone, if the TGA can't be found and editing DDS is needed, I'd want to think about batching up all the bitmap edits needed for i18n... but that's a lot of work. I might add, there a third possibility in the case of the readable fonts that are currently ASCII only. If they were sourced from TTF, and you find the TTF (easy in a few cases), then see if it covers Latin-1 or more. You can (with some complications RE the conversion software) regenerate an improved TDM font from that.

I'm assuming we're talking about Stone 24pt font here, used in subscripts & elsewhere. Images of letters are arranged into a bitmap by a process that doesn't have to conform to a tidy alphabetic grid. See Figure 2 of my new article https://wiki.thedarkmod.com/index.php?title=Font_Bitmaps_in_DDS_Files In the figure, you can see there's an accented "a" to the left of the W, whose foot is presumably within W's bounding box. I think I looked at this earlier & concluded that I couldn't shrink W's bounding box enough in the DAT file. So probably the pixels of the W need to be moved to the right... I haven't tried such surgery yet.

I have updated my Refont program, to now have a function that can analyze a font DAT file for missing or problematic characters. As part of a broader inquiry, I've just applied that program, individually, to all current 'english' font DAT files. I'm reporting the overall results here. I'm sure this will not be a surprise to some of you, but may be to others. Background As you know, TDM fonts are based a bitmap system, derived from 256-character code pages, of which "English" and "Russian" are currently supported. "English" is actually Latin-1, with additional characters to cover more European languages in a single codepage. This is (in theory) quite good for major European languages, less so for less-prominent ones. For each font, bitmaps are distributed in 3 sizes (12, 24, 48 pt), with the engine doing interpolation scaling. Current Font Findings 12-pt Size for All Fonts Only ASCII (i.e., lower range 0-127) characters are provided, no European. For some fonts (stone, mason, mason_glow), the 12-pt DAT is not distributed, so the engine will substitute a larger size, which typically has better Latin-1 coverage. For Fonts Used in Main Menus, HUD, or Subtitles The numbers shown approximate the number of "characters needing work" Fontname Size-24 Size-48 carleton 20 16 carleton_condensed 20 35 mason -- 33 Since 24 pt is not distributed, engine uses 48 pt. stone 30 83 For Additional Fonts Used in FM Readables, Etc. Except for one font (treasure_map), all the remaining fonts are ASCII-only, i.e., no characters in the upper range. In the lower range, routinely the 24 and 48 pt sizes have equivalent coverage. Most of these fonts are fully or nearly complete, while some neglect certain punctuation symbols. The worst is "everette", with 24 "needing work" characters. Further details are here:

This was overall an enjoyable FM for me. Thanks for making it. Thoughts/spoilers: Also, there were 2 minor issues undoubtedly due to engine or asset shortcomings:

That would be another good method. The one I used was easier for me, given that I was also supporting a SFW difficulty level where she is already dressed before reaching the attic. Thanks. No animation available for that either, so all done with cut-scene fakery and video editing. Glad you enjoyed a bit of sparks with those. Although I can't take any credit for the idea of dress mannequins with human hands... you'll see them IRL at any mall. But the implementation in TDM... therein the magic: It's 11pm here, and I'm off. Thanks for chatting.

That "fall" delay was by design. Because there is no animation available to show her actually re-dressing from the trunk of clothing, so instead I wanted you to have to imagine it. Rather than actually catching up with her and seeing the instant body swap.

They are a riff on historic mushroom-style "linen smoothers", as this article sketches: http://www.oldandinteresting.com/antique-irons-smoothers-mangles.aspx The gold color hints at heavy brass. Bonus in the NSFW difficulty setting: One is also seen outside a laundry setting, for its *snort* suggestive shape.

I have just released a new utility, "refont", as an open-source, partial-successor of the traditional "q3font", used to tweak the spacing and placement of TDM's bitmap font characters. For the whole story, see the new wiki page Refont.

I have just released a new utility, "refont", as an open-source, partial-successor of the traditional "q3font". For the whole story, see the new wiki page Refont. (I'm gonna post this in a few forum threads. Don't hate me for that.)

I have just released a new utility, "refont", as an open-source, partial-successor of the traditional "q3font". For the whole story, see the new wiki page Refont.

Yeah, it's J anky, but can't be fixed in the DAT file. Likely it requires moving pixels in the bitmap. I'm personally unenthused about doing that, particularly in a 2.12 timeframe.

Yet another Stone 24 pt Update. This removes stray marks to the left of G (as well as char 249, u with accent grave), visible with textscale 0.25 but not 0.24. So this may or may not benefit subtitles, but it will definitely help Stone font readables. Most of them use a scale of 0.25 for body text. An attempt was made to also improve G spacing, but (since xSkip can't be changed) effect is marginal at best. fontImage_24.dat of Feb 27