Geep

Also, related to font improvement, I've just released "ExportFontToDoom3All256", a reconstruction of an earlier but now lost tool variant. This is described and available in the wiki article ExportFontToDoom3 I tested that tool using one of the TDM FM fonts, Andrew Script, for which a TTF file is available. I generated a fresh set of bitmaps (newly including any available Latin-1 characters). I also mucked about with FontForge, to reconfigure that TTF to be ordered like the TDM custom codepage. However, Andrew Script is missing a fair number of Latin-1 glyphs, so it would take some work to make it good (whether by editing in FontForge or post-export as bitmaps). I'm putting that aside for now, since the jury is out on whether Western language support in FMs and their fonts will become viable (see Western language support in 2024?). Instead, I plan to turn my font-improvement-for-2.13 attention to Stone 24pt, which (because its used in HUD captions) is more clearly worthwhile to work on. Looks like I'll have to convert the Stone DDS to TGA as a prerequisite to bitmap editing.

Just for the record to benefit readers here, the archived Stone .tga's turned out to be the original ASCII-only versions, not the versions that got extensive bitmap editing. Too bad.

I agree, that is an issue. It would be better if the system handling briefings/readables could be revised as you indicated, to handle individual sentences as #str_, rather than whole pages. Baring that, having a key field like "#str_This is a whole page\nfull of text that goes on and on and on [...] until done" would appear as a very long single line. That is nasty to look at in the Readables Editor, and even worse in the .langs file, where the too-long text would appear twice on a line (once with #str_ prefix of English version, another in translation). So for those, it would be better in the short term to stick to symbolic keys, e.g., existing #str_12345 or revised form #str_myfm_book_of_spells_page_1 I might add, in the longer term, enhancing the Readable Editor to use the .lang files would be an enormous improvement for FM authors and a significant accomplishment. A fair amount of work though, but probably doable in increments over several releases.

I think you need to do things at the exact moment in DR that the user changes a field, so you can capture both the old value and the new value. Would be way better if DR just handled everything natively, but could be done through a hook to an external script too, I suppose. Or some complicated logging.

One of the problems with the old #str_number system, that would not be automatically solved in the new #str_phrase system, is lack of versioning/history. For example, suppose in the FM I provide a new string: #str_Mother! which (by magic TBD, ideally in DR) generates this placeholder in all the .lang files: "#str_Mother!" "Mother!" The translator in the fr.lang file later does this: "#str_Mother!" "Mere!" Still later, the FM author revises the string in DR: "str_Mother!!!" In a naive implementation, this breaks the link to the existing translation(s), which becomes orphan in all the .langs, and creates a new entry: "#str_Mother!!!" "Mother!!!" OK, how could we do better? Case 1 (as above): the FM author knows the change is trivial, and so (at revision time in DR) might ask the translations to be retained but marked for review. So maybe the fr.lang files gets: // WAS UNTIL 2025-01-01: "#str_Mother!" "Mere!" "#str_Mother!!!" "Mere!" // Needs minor review with removal of the orphans (after they become comments and moved to before their replacements) Case 2, where the revision is not trivial: the FM author (at revision time in DR) might ask the translations to be replaced by english but marked for review, e.g.: #str_Mother of Pearl! causes the fr.lang files to have (with orphan removal as case 1): // WAS UNTIL 2025-01-01: "#str_Mother!" "Mere!" "#str_Mother of Pearl!" "Mother of Pearl!" // NEEDS REDO Then the translator could eventually fix it: // WAS UNTIL 2025-01-01: "#str_Mother!" "Mere!" "#str_Mother of Pearl!" "Nacre!" // Done 2025-03-14 by Henri

I mentioned this elsewhere, but just a historical note: the existing i18n.pl conversion script expects only a numeric value after #str_ in its pattern matching regex (and possibly method of hashing). I do think @datiswous's idea to have key/value pairs with values like: "#str_Nobody crosses me! Must get back Frothley's scepter Creep stole off me." is a good way forward. Maybe with this version, DR could actually choose over time to provide some .lang support. And probably the engine would have to create hash tables to avoid slow string matching with these long non-numeric strings. (Oh, one other thing, since we're talking about The Outpost. When I played it earlier the month under 2.12, my screen would periodically go black for a second or two, every minute or two. I wonder if anyone else sees this, or just my odd Intel graphics chip?)

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)...