Geep
-
Posts
1054 -
Joined
-
Last visited
-
Days Won
57
Posts posted by Geep
-
-
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.
-
22 hours ago, datiswous said:
xdata formatting doesn't work well with the lang references.
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).
-
6 hours ago, datiswous said:
Nobody is making these language packs though. Not sure why. I heard the translation conversion script is hard to use.
That is one reason.
6 hours ago, Frost_Salamander said:the script worked once but I needed to re-run it and just couldn't get it to work. It's also Perl which nobody really uses anymore.
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.
4 hours ago, nbohr1more said:The current system makes mission updates a real problem to the point that only long dormant missions are viable for translation.
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].
6 hours ago, Frost_Salamander said:At the end of the day it's extra work for the mapper and if it adds too much overhead (i.e. is broken or is a PITA) then nobody is going to use it.
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?
4 hours ago, nbohr1more said:If all written strings were kept in XD files, the process would be easier.
We shouldn't need map edits for this.
A new system. What would that look like to the FM author? To a non-author translator
-
6 hours ago, datiswous said:
I don't understand this. When I download a mission, I can still download and update the translation files for it using the build-in mission downloader.
Also, the language packs are downloadable for the missions that have them.
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.
-
3
-
-
- Popular Post
- Popular Post
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.
-
5
-
1
-
On 4/5/2024 at 3:59 PM, OrbWeaver said:
You can drag outside a selected speaker and resize it exactly like a brush
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
-
On 4/12/2024 at 8:11 AM, grodenglaive said:
So my AI will now follow the player with no errors or warnings.
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)...
-
1
-
1
-
-
On 4/10/2024 at 2:25 PM, Amadeus said:
Yeah, sorry about that, that is when the archive was formed, I'm not really sure what I can do about that
That was just a "nice to have", not "must have". No worries.
On 4/11/2024 at 5:10 AM, datiswous said:SVN is here? https://svn.thedarkmod.com/publicsvn/darkmod_src/ no idea where these files are
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.
-
On 4/7/2024 at 5:40 PM, wesp5 said:
I don't really know what this is about, but I will use the occasion to remind everybody that there is a surplus pixel at the lower left side of the capital W character. People speculated this might come from another character nearby in a font table but I don't see how V could have a pixel at that position....
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.
-
- Popular Post
- Popular Post
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 83For 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:
SpoilerDetails about the 24 and 48 pt Sizes
The numbers shown approximate the number of "characters needing work". Note that in some cases, only a correction to font metrics in the DAT file would be needed. Other cases would need bitmap surgery.
For Fonts Used in Main Menus, HUD, or Subtitles
carleton Size-24 (20 need work) [Note 1] Ń (0x8c), Ș (0x8d), Ț (0x8e), đ (0x90), ś (0x91), ŝ (0x95), ô (0x98), ŕ (0x99), ǔ (0x9a), ń (0x9c), ș (0x9d), ț (0x9e) + 8 more [Note 4] in upper range carleton Size-48 (16 need work) [Note 1] Ô (0x88), Ń (0x8c),Ș (0x8d), Ț (0x8e), đ (0x90), ĉ (0x96), ă (0x9b), ń (0x9c), ș (0x9d), ț (0x9e), § (0xa7), Ñ (0xd1), á (x0e1), ñ (0xf1), ù (0xf9) + 1 more [Note 4] in upper range. carleton_condensed Size-24 (20 need work) [Note 1] Same set as carleton size-24 carleton_condensed Size-48 (35 need work) All in ranges 0x80-0x8e, 0x90-0x9e, plus § (0xa7), Ñ (0xd1), á (0xe1), ñ (0xf1), ù (0xf9) mason Size-48 (33 need works) [Note 2] All in ranges 0x80-0x8e, 0x90-0x9e, plus Ą (0xaa), ą (0xba), ř (0xf7) Also, treatment of Non-breaking Space (NBSP)(0xa0) and Soft hyphen (SHY) here is inconsistent with other fonts, but unclear what correct treatment should be. Stone Size-24 (30 need work) [Note 3] Ń (0x8c), Ș (0x8d), Ț (0x8e), đ (0x90), ô (0x98), ŕ (0x99), ș (0x9d), ț (0x9e), ð (0xf0) + 21 more [Note 4] in upper range. Stone Size-48 (83 need work) 2 in lower range with bad boxes (p & y) + 20 in upper range with bad boxes (could enumerate these here, but too tedious) + 61 more [Note 4]. [Note 1] Same stats for carleton_bold, carleton_glow [Note 2] Same stats for mason_glow. For mason and mason_glow, 24 pt is not distributed, so engine uses 48 pt. [Note 3] A more precise and in-depth analysis of 24-pt stone, including bitmap inspection, was presented earlier. [Note 4] Bounding boxes are shared among code points. Bitmap inspection would be needed to id which glyph "owns" bounding box, and which codepoints are interlopers. In many cases, this represents a deliberate substitution strategy, e.g., to redirect a missing accented character to another similarly-accented or unaccented character. Better than nothing.For Additional Fonts Used in FM Readables, Etc.
Only the author of one font started to add upper-range (128-256) characters, but didn't get far along:
Fontname Size-24 Size-48 treasure_map 107 96Remaining fonts are ASCII-only! Characters in the upper range (of which TDM defines 124) were not done. These are indicated as "124+" below, plus any additional problematic characters in the lower range. These latter are generally punctuation symbols.
Fontname Size-24 and Size-48 andrew_script 124+0 bamberg 124+0 camberic 124+3 carolingia 124+3 chrishand 124+6 ellianerelle 124+0 everett 124+24 gothica2 124+20 jd_hand 124+0 lotharus 124+11 mac_humaine 124+8 medusa 124+1 nancy 124+4 popsies 124+1 rapscallionpirate 124+10 (for 48 pt, +9 for 24 pt) shoppinglist 124+1 summertime 124+0-
5
-
This was overall an enjoyable FM for me. Thanks for making it. Thoughts/spoilers:
SpoilerThe briefing was clear and straightforward, if a little long. Continuity issue: one thief was described as having a fat ass, but later was not seen as being fat.
I liked the carriage start. In the village, I spent some time looking for rope arrows, or ways to mantle up house facades. Nada. Not a problem.
Inside the house, the shifting volumetric lighting and soundscapes with scraping (or distant thunder?) were particular highlights. The paintings of the sea captain and the ship with kraken amplified the storyline in the readables. The meaning of the bottles was nicely ambiguous (I thought the diary entry about seeing the dead crew in the bottles was a reference to alcoholism, not actual ghosts in the bottles.)
I figured in the enormous library, there was a 99% chance that there was nothing worth looking at on the shelves, but I surveyed them anyway. Could have used a little payoff. Or fewer bookcases.
The whole first part before the attic, while quite good from a loot, puzzle, and atmosphere perspective, might have benefited by breaking up the lengthy traversal with some unexpected threat (e.g., rotting floor giving way, stack of boxes and bottles falling over).
The statuettes were splendid, particularly the one with the projected silhouette. Although they didn't seem to a perfect match to the descriptive note and overall nautical theme (e.g., no tentacles).
Ubiquitous Terrible Old Man... kinda cool. The cutscene surprise ending was effective. Though I wish the last image could have had our heroes half covered in sand or sloshing water.
Also, there were 2 minor issues undoubtedly due to engine or asset shortcomings:
Spoiler- When I first was in the nautical trophy room, I wanted to break through the glass case tops, but had no blackjack. So I tried picking up one of your cannon balls and dropping it repeatedly on the glass. No luck.
- I didn't notice this when I played, but saw it in Cambridge Spy's youtube playthru at times 19:53 and 21:27... when a Terrible Old Man walks in front of a vertical display case, the glowing glass panels appear in front of his body, not behind.
-
1
-
-
7 minutes ago, Rio_Walker said:
Have you not considered using the screen? She walks behind it, there is a shadow of her lifting her arms, the light flickers - POOF - model swap, she steps out clothed. Although, there had to be something preventing the player from walking behind the screen.
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.
QuoteI liked how you handled her undressing to begin with.
Thanks. No animation available for that either, so all done with cut-scene fakery and video editing.
QuoteWhat startled me earlier tho, along with creepy music while the Builder's priest sings in the background, is the dress mannequin... with human hands.
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:
SpoilerIt's a regular AI, but largely immobilized in an invisible box. It stops squirming and freezes about 1/2 minute after the game starts. So its exact posture is slightly different each time. The head is given a custom offset, to bury it into the floor beneath the dress.
It's 11pm here, and I'm off. Thanks for chatting.
-
1
-
-
8 minutes ago, Rio_Walker said:
Also... maybe (if you'll be updating it someday) you should add a plank leading from the roof to the attic during the escape sequence, because I saw Emily just hover into it but fell down and missed the moment Emily respawned with clothes on. =D
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.
Analysis of 2.12 TDM Fonts
in The Dark Mod
Posted
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.