Geep

FYI, Air Pocket translations are essentially done, but I'm postponing release until I can do some final testing under 2.15[beta]. I'm starting to look at helping the main menu translations, mostly with AI. When I have something to report, that will be a separate forum thread (probably dev).

@Azaran -

Of interest to translators, new wiki page https://wiki.thedarkmod.com/index.php?title=Multilanguage_Display That page ends with a big fat color-coded table, per Unicode character, comparing TDM and supported five ISO-8859 encodings. It should help guide a translator trying to show a desired character, even if that character is not native to the current language.

If any of you blokes could verify the fix for func_klaus and report it to him at: 0005617: "Open Map From Project" prevents pointfile from loading (link above) that would be good.

After pausing to work on an Carleton 24pt font update, I'm back on Air Pocket. I've been testing inventory names... some translations are too long and the names are clipped. Related to that, I just added a short section to the wiki's "Inventory" page called "Length of Inventory Display Names".

Turns out there's a ticket open for this circa 2021. I've tickled it further there. https://bugs.thedarkmod.com/view.php?id=5617

Just seeing this problem too while following up a defective portal. In DR, couldn't see the pointfile (...portalD...lin) if I opened it with File/Open Map from Project, but did see the pointfile if I opened map with File/Open...

So with this update, Carleton 24pt joins Stone 24pt in having the full set of TDM-defined characters for the TDM-supported languages. For translations, this mainly benefits the main menu, but also the body text of any FM readables using Carleton. I need to update the Carleton font wiki article soon about this.

Regarding the Carleton 24pt update: it's done for now, released to the bugtracker for eventual inclusion and evaluation in a 2.15 beta.

Ah, sorry. Let me copy the content here... All - Recall that the Carleton 24pt font is widely used throughout the main menu. In some cases, a particular text string is indicated as selected (or being moused-over), by showing each character in white with a red background "glow", offset to the right (and often below). I'm wrapping up a revision cycle for Carleton 24pt, and now have to deal with the corresponding carleton_glow bitmaps. It would save me considerable time if I could just use a dup of (revised) carleton 24pt itself to do this, instead of creating custom bitmaps and DAT files. Using a dup for carleton_glow would simply rely on existing GUI offsets to show a red drop-shadow. That is how the /russian/ version of carleton 24pt implements red glow. Visual Examples We'll start with existing TDM 2.14, looking at the main menu's Settings/Video/Language page. (You can run TDM to see this comparison live.) Two screen shot snippets are shown, from page top and (with mouse-over) bottom. Here's English, which uses custom bitmaps with "blurred/feathered" glow: Then here's the same page after Russian is selected as the language and TDM restarted: There's not a lot of difference. The white part of English is a little crisper, but may be attributable to... English carleton 24pt has 512x512 bitmaps, while Russian has the traditional 256x256. English carleton 24pt glyphs have edge-darkenting (i.e., thin black border), which was not done for Russian. Thus, I think the difference is not due to the different red glow treatments. The English glow has hints of red to the left of some characters, and more feathered red glow in character interiors, e.g., within the arms of the E, or extending further down from the top stroke of G. But it also shows some artifacting, where the feathering would like to extend further but is cut off by the character's bounding box. See the lower right corner of D and O in "Video", where the red is somewhat squared off due to this clipping. Now here are similar shots from an experimental FM with my revised carleton 24pt font, and also using the revised DAT and DDS files dup'd for carteton_glow: As with 2.14 carleton, the revised carleton retains glyph edge-darkening for definition. This edge-darkening didn't seem to hurt anything when carleton bitmaps was dup'd to carleton_glow. So, I'm proposing to use this "dup" approach, using red drop shadows, going forward. This would save me a bunch of time and effort (which I can expand on if necessary), and simplify the system. Thoughts?

@datiswous, yeah, my explanation was possibly gobbledygook to non-devs. I cross-posted here, cuz I just wanted to give a heads-up to anyone interested, to look at the screen shots and see the noticeable but minor visual impact of the proposed change. I admit there's not enough eye-candy involved for this thread.

Hey, everyone. I'm proposing a change in how text red "glow" background in the TDM main menus would appear, to save me considerable effort in wrapping up an upgrade to the Carleton 24pt font. Please visit here in my "Improvements to Carleton 24pt Font" thread to see visual examples and details, and to tell me what you think. Thanks

I dunno, but looking at the TDM Script Reference, there's a few things you might try from a triggered script. Like <entity>.stopSound(channel), where channel might be SND_CHANNEL_ANY. Don't know if this works with AI. Or maybe <ai>.bark(sound), where sound could be a short silence clip. Or even just null? Other possibilities I guess: <emitter>.Off(); <emitter>.On(); startSound(...); playAndLipSync(...);

If the automation could do a screenshot, that would be another approach. You'd puppet to each target, frob it, take the screenshot (and in the case of my custom readables, wait some seconds and screenshot again). Then review the translations from the screenshots. Would be even better if it was possible for the script to pass a meaningful filename for each screenshot.

Google will give it away with "Famous Slovakian building from 1505"