Geep

An update. Like the Briefing, the Objectives menu relies on the Carleton 24pt font. Characters missing from this font, affecting the Romanian and Polish renderings, were mentioned a week ago. Also missing is the "a with ring above" character (0xe5 in the TDM map), affecting the Danish rendering. I've decided in all these cases to leave the full translation in "all.lang" as a comment, and provide in-game text with the base characters as replacements. Also in this font, the German lower-case "ß" (Eszett) (0xDF in iso-8859-1) is present in TDM's charmap at that point, but the provided glyph is full-height. The height should be that of other lower-case characters... it needs to be scaled down in the font's DAT file. (This font's lower-case characters appear as scaled down upper case. So this is in keeping with that.) Note: Recall the Objectives text size is adjustable using the HUD settings. Fortunately, it's set to a maximum size by default (a slider value of 1.0 applied to a base textscale value of 0.27). So, it would seem this is not an additional source of overflow worry for us. Marching through the languages continues.

The remaining task is to inspect the language strings associated with messages and objectives as they might appear in the game. However, to actually run AirPocket to completion for each of the 16 languages would be time-consuming and tedious. So, as an alternative, a minimal FM "testAirPocketMessages" was created. This was built from a clone of last year's "testSubtitlesANSI", with the subtitle assets removed, AirPocket's i18n string assets added, and the script file rewritten for a new purpose. For messages, for a given language, this allows all 7 to be reviewed one after another by simply pressing a button. The test FM and Air Pocket use the same message GUI (namely "atdm_gui_message_no_art"), showing white text on a transparent background, with vertical centering controlled by a nominal "lines" spawnarg. (While this could have been done by copying the 7 gui message objects from one Dark Radiant instance to another, I did it by searching airpocket.map for "gui_message" and copying blocks to the test .map. With object origin and entity # changes. Also, when you show a message, a supplemental message box appears in the upper left corner with #str and "lines" values. Implementation of latter is only quick & dirty.) When inspecting, mainly I will be looking for any cases where there's so much text that it overflows below the lower edge of the screen. Plus any missing characters. Also, I dimmed ambient_world, which was too blazing bright in testSubtitlesANSI. I can read overlays much easier now. (Testing within testAirPocketMessages neglects any visibility issues due to the likely background in the real game's scene.) For Air Pocket's 12 Objectives, they are copied into the test FM and altered so that they always appear. (Again, searching airpocket.map, this time for blocks mentioning "objective".) Each objective is made visible and attributes made identical (except "obj...desc" #str text) , e.g., with obj 1 as the example: "obj1_1_irreversible" "0" "obj1_1_not" "0" "obj1_1_player_responsible" "0" "obj1_1_state" "0" "obj1_1_type" "custom" "obj1_desc" "#str_fm_map_obj01_no_hurt_or_loot_crew" "obj1_irreversible" "0" "obj1_mandatory" "1" "obj1_ongoing" "0" "obj1_state" "0" "obj1_visible" "1" For test purposes, really only the last attribute is essential. TDM's GUI used for the Objectives menu limits each to 3 lines as rendered, after which it truncates the string. So that's the main thing to inspect for. (Interestingly, the last objective fails this test in English. I guess since I separately programmed a popup message that states the new objective, I never tested what it looks like in the Objectives list.) Next, I'll use all this to review the language strings.

OK, the Briefings are essentially done. As I said before, content is now distributed into 3 pages, instead of the original 2. Also, I’ve been using “\n\n” to separate paragraphs. This provides “air” between paragraphs, and also makes it easy to fit yet more text on a given page if necessary by combining paragraphs. I needed to that only once (for German). There are additional specific-character changes that I applied manually, but in the future the AI could be told to do (i.e., not generate unwanted characters). I’m discussing these in the context of AI-generated Briefings, but they are more widely applicable, including to the [English] section. * Replace long dash “–“ (U+2013) with short dash. * Replace single-character ellipsis … with 3 individual dots. * Replace double quotes with single quotes. * Replace directional single quotes (namely ‘ and ’, including latter as apostrophe) with non-directional. Regarding double quotes, replacing them with single quotes is generally best. However, you can in some cases retain a non-directional double quote, but you’d have to escape it (with preceding \ ), and I vaguely recall that doesn’t work under all use cases. Russian has directional double-angle marks as quotes, which you can use. TDM’s ”english” (European) character map repurposes the Latin-1 double-angle codepoints for other purposes. Be aware that the default briefing font renders a straight single quote as if directional. Turning to shortcomings of the default Briefing font (scaled from Carleton 24pt), certain glyphs were never implemented and appear as squares (or artifacts) on-screen. At codepoints 9c-9e (Polish lower-case n with accent, Romanian lower-case s & t with descenders). Likely upper-case 8c-8e are also problematic. Possibilities of what to do: The long-term system-level solution is to complete the font’s character coverage. Awaiting that, you could just leave the FM with the squares/artifacts. In the FM strings, replace these characters with their unaccented base letters. As an interim system-level fix, update the font’s DAT, to replace these characters with their unaccented base letters. For Air Pocket, I’ll do either (1 - awaiting) or (2) at this time. Finally, for Spanish, the TDM standard english/european character map does not support the inverted exclamation mark: ¡. Three FM workarounds: Drop the leading ¡ but retain the trailing !. Make the sentence non-exclamatory, replacing also the trailing ! with a period. (This is what I generally chose.) Likewise drop both marks, but also capitalize the phrase to indicate shouting.

For the re-distribution of briefing text, I thought about basing it on char count, but instead took an easier approach: Move to 2 sentences from the end of page 1 to the start of page 2, then 2 sentences from the end of page 2 to the (empty) page 3. The original page 1 was jam-packed, while the original page 2 was not, so I was less concerned with the latter. This will still need to be verified next time I generate the *.lang files, to make sure there is no truncation at any page bottom. (I had to do the re-distribution for each language, but if I'd done a slimming redistribution of the English early-on, that might have been enough to carry through to other languages. Or possible the AI could manage the redistribution, if you give it a character or word count target. Conjecturally a target around 550 characters per page might work well with the current briefing GUI. I'd ask it not to split sentences.). That leaves the Objectives and Messages to do next.

Well, as usual December was too involved IRL to get anything done in TDM. (Happy New Year, BTW.) On the briefings, I did get a little further since last report. I decided, rather than do tedious patching based on the back-translations, I'd instead change the English source to clarify some phrases, and then re-translate again and call it good enough. This is being expeditious rather than cautious. I expect the briefing translations to on some pages exceed briefing page-text limit. Rather than doing a custom briefing GUI (e.g., with scaling), I instead will edit the .xd to hand-distribute by eyeball the text among the briefing pages.

Amusing, some of translation issues. In the original FM briefing, I referred to "tacky goods". The back-translations from various languages rendered this as "sticky goods". I was intending a different meaning (perhaps a dated Americanism) of "embarrassingly cheap-looking" goods.

After submission, there was some back and forth dialog with ChatGPT about how to structure and batch the output. I let it decide how to denote the language sections (it chose for example "=== German ==="), because I planned to hand-include the results into all.lang (e.g., the "[German]" section). It suggested a few batching options, and I chose 4 languages at a time. (In future, probably 1 at a time would be better to ensure complete batch delivery without pause.) It took maybe 40 minutes to get all the results. While I asked it to update me on progress every few minutes, it only actually reported an update if I poked it. And it seemed to get confused about what was contained in each batch as it delivered it (but actual contents at quick glance were as expected). So when I get time next, I'll archive these results into all.lang, and begin the (time consuming) back-translation verification, looking for flubs and spot fixups. At the end, changes in the lengths of sentences are expected to require manual tweaks (e.g., changing page distributions) for correct display. Pop-up messages in particular may need further customization TBD.

For the FM's text not yet translated, I gave ChatGPT a complex job (in a fresh session, not logged in). The prompt begins... You are an expert translator between English and other European languages, including Russian. You wish to translate a video game, set aboard a small historic merchant sailing ship, from English into these target languages: 1. German 2. French 3. Polish 4. Italian 5. Spanish (as spoken in Spain) 6. Portuguese (as spoken in Portugal) 7. Russian 8. Czech 9. Hungarian 10. Dutch 11. Slovak 12. Danish 13. Swedish 14. Romanian 15. Turkish 16. Catalan. As input, there are 3 lists of English text strings to translate. The 3 lists are respectively in these sections below: A. Objectives B. Thought Messages C. Mission Briefing Each section will start with "Translation Notes:" with additional indented guidance points for that section, then the list itself. Each line of a list begins with a tab, then a word beginning with #str_ within double quotes, then another tab, then a phrase within double quotes. When you translate a line, in the output keep the tabs and the #str_ word unchanged, and only change the phrase to the other target language in UTF-8, keeping it in double quotes. Do not generate Unicode combining characters. Make the translated phrase reasonably short while preserving the formal meaning. Avoid modern slang. Old-fashioned wording is fine. Generate output lists grouped by target language, then within that by section. Also, as separate lines, add comments about any directive that was unclear, or any part of a translation where confidence is low. For consistency with other pre-existing text, it is important to use certain preferred translations, contained in a Glossary below. The Glossary takes the form of a series of 2-column tab-separated tables, one table for each term. In each row, the first column has the language, and the second the corresponding term within quotes. English terms should be matched against the English source text, to drive the translations into other languages. The glossary shows the nominative or noun/subject case, without gender, and when generating translation will be need appropriate declination adjustment to each target language as specific context dictates. Throughout, when translating both "captain" by itself, and "Captain" as a title (e.g., for Riggs), always replace the English term with the translated term from the Glossary. For people names "Riggs" and "Emily", don't translate, except for Russian, transliterate into Cyrillic alphabet. Then the Glossary Tables (detailed in the preceding forum post) appear. After that, the prompt continues with the 3 sections. I'm showing just a sample of A and B here, avoiding spoilers. "Translation Notes" are my guesses, e.g., about needed context for potentially ambiguous phrases... A. Objectives ============= Translation Notes: Objectives are goals the player strives for at various times during game play. "(Opt.)" means "(Optional)"; the translation may use an abbreviation if there is a well-known one. "Capt." means "Captain"; the translation may use an abbreviation if there is a well-known one. "For "sea trunk", use the Glossary. ... "#str_fm_map_obj01_no_hurt_or_loot_crew" "Rile neither the captain nor crew. No assaults by me or gratuitous thieving... not that there's much to steal." "#str_fm_map_obj02_stow_provisions_in_bow_clear_stairs" "Finish stowing the new provisions forward in the bow. Clear them away from the hatch stairs and doorway." ... "#str_fm_map_obj06_opt_get_sword_from_sea_chest" "(Opt.) Retrieve my sword that I put in the sea trunk. I'll likely need it against those who attacked us." ... B. Thought Messages =================== Translation Notes: "keys" are keys to locks on doors or trunks. "My bow's too slippery to handle" is talking about bow and arrows, not ship's bow. "slippery" is due to water. ... ... "#str_fm_map_thought_msg2_keys_missing" "My keys are missing! Must have fallen from my pocket in the attack." ... "#str_fm_map_thought_msg4_bow_unusable" "My bow's too slippery to handle... useless for now! Maybe tomorrow." ... C. Mission Briefing =================== Translation Notes: a "tradeship" is a small merchant vessel with tradegoods. "my sea trunk" is really a ship's sea trunk assigned to the player. Use the Glossary for "sea trunk". "bow galley" refers the galley, which in this ship is located in the ship's bow. Use the Glossary for "galley". "I'm still sore from hauling the goods." Here, "sore" means physically sore, not angry. "sail a half bell" refers to ship's time measured in bells. "His face looked a bit clouded." is a poetic way of saying "He looked worried." "galley hold" is a general storage area within the galley (and not a pantry specifically for food/kitchen items). "ship waist" is the center of the ship, neither bow nor stern. "clearing the mess" refers to clearing dishes after a meal in the ship's mess. Use the Glossary for "mess". "#str_fm_mission_briefing_xd_pg1_body" "Life is sweet! It's been 3 days since Emily ran away with me, leaving behind her bastard husband. He's miles away now, as our tradeship Esmeralda plies herself down the coast.\n\nWe were in luck that Captain Riggs was short of hands. Seems like he's short of funds, too. We had to bribe him with some jewelry to let us crew, particularly a woman.\n\nHe insisted I stow my sword in my sea trunk. Not much trust either way. I've managed to hide some other stuff from him, now up in the crow's nest. But I need to keep on the good side of him and his raggedy crew.\n\nAnyway, Emily's set up a cozy bunk for us in the bow galley.\n" "#str_fm_mission_briefing_xd_pg2_body" "I saw the captain do a lot of haggling and bartering this afternoon, at a village port. I'm still sore from hauling the goods. Since then, we only managed to sail a half bell, before the wind turned unfavorable. Riggs has us anchored in a place he called Shark Jaw Cove. His face looked a bit clouded.\n\nI'll finish moving the new provisions into the galley hold, whilst the two mates stow and secure the tacky tradegoods in the ship's waist. Emily's clearing the mess, then feeding table scraps to the livestock on deck.\n"

I've developed a Glossary for terms that I want to have consistent throughout a given language's translation: "Captain", "First Mate/Officer", "Second Mate/Officer", "Galley", "Mess", and "Sea Trunk". And corrected the previously-done piecemeal translations by hand. In some cases, extra translation was needed to go from the noun/subject case of the Glossary to get gender and other declinations correct, like the "accusative" case in Slavic languages. I then passed 4 of the Glossary terms (in text form from a private spreadsheet, and skipping the 1st and 2nd mates) as part of a new prompt to ChatGPT, to attempt to do all the remaining FM translation work in one big gulp. Four Glossary Tables:

Back to the on-going translation effort. Here’s some general observations and lessons learned while translating the main readable. Recap This readable, mentioned earlier, has an all.lang entry of: [English] // Readables in airpocket.xd: "#str_fm_airpocket_xd_sheet_appointment_to_service_pg1__title" "Appointment to Service\n" "#str_fm_airpocket_xd_sheet_appointment_to_service_pg1_body" "\n\nHEAR YE ALL, that the Bearer is found Fit to Serve, and appointed to the Rank of Ordinary Seaman, aboard the Merchant Ship Esmerelda, by Authority of the Shipmaster, Captain Riggs.\n\nThe Appointee serves Under the Direction & at the Pleasure of the Captain & Officers. By the Law of the Sea known by all, while Aboard, Violations of Duty will be Judged & Punished by the Captain & Those carrying out his Orders. Thievery, Mutiny, Assault, & Other Gross Breeches of Order will be met by Flogging or Death. At Successful Voyage End, the Appointee on Discharge will get the Agreed Wage recorded in the Ship's Log, less any Deductions.\n" "#str_fm_airpocket_xd_sheet_appointment_to_service_pg2__title" "Further Instructions\n" "#str_fm_airpocket_xd_sheet_appointment_to_service_pg2_body" "\n\n\n\nAs agreed, the 2 new crewmates will bunk in the galley, and share the sea trunk nearest the door in the mess.\n\nCaptain Riggs\n" As stated earlier, this text, stripped of #str_ IDs, tabs, and quotes, was given a long directive context prompt and fed into ChatGPT for forward-translation into all the TDM languages. For verification, individual language results were then back-translated (without additional prompt context) into English using Google Translate. Google Translate was also the preferred choice for spot patch-ups. Results were Good Overall Across languages, most sentences appeared to roundtrip-translate quite fine. Some languages (e.g., Turkish) needed more patch up, perhaps due to less AI training or just a greater sentence-structure differential. I did not stress-out about how well the officious over-capitalization of the original was carried over into the translation. Forward-Translation Problem #1 – Piecemeal Translation and Naming Consistency In order to keep this exploration tractable, at the outset I subdivided the collection of English #str_ into various groups (e.g, inventory items, character names (including shouldered), readable, briefing, etc.), and arranged to translate each group separately into all languages. The downside of this is that the subgroups end up with different names for the same thing. This is not unusual IRL, but not real desirable in a game. So, for instance, a key (inventory item) labeled “Mess” (for the door to the ship’s eating place) often has multiple correct nautical translations in a given language. When the word “mess” in the readable is translated, the AI may choose a different one. So patch-up is needed to make the references match. (Future projects might well benefit from a more holistic use of AI.) This problem also affects ranks and titles of persons, about which more next. Forward-Translation Problem #2 – Nautical Ranks and Titles left in English ChatGPT, when translating “...appointed to the Rank of Ordinary Seaman”, almost always left “Ordinary Seaman” in English. And would only sometimes translate “Captain” into a target language. (For a quick look at some suitable nomenclature, type this - “EU commercial nautical deck department ranks in all EU languages - into Google Search and see what the AI provides.) Furthermore, when “Captain” appeared in the readable as a title, e.g., “Captain Riggs”, ChatGPT liked to leave it unchanged. There are two ways to think about that: ChatGPT thinks “Captain” is a first or nickname. ChatGPT thinks that the rank of Captain (and perhaps the surname) implies this is an Englishman, so the rank should be left as conferred by the governing authority. It would be easiest for me to just leave it as “Captain Riggs” throughout. But I’m not really trying to imply Riggs is English, and would think translated immersion would be better if the title was also translated. (I haven’t yet decided which way to go.) Forward-Translation Problem #3 – Lost Nuance affecting a Proximity Clue The last sentence of the readable refers to “the 2 new crewmates ... share the sea trunk nearest the door in the mess.” The English implies that this trunk is *within* the mess. In retrospect, it would have been better to phrase it that way (perhaps I will in the end product’s [English]). Translations into some languages kept this implication; others just said something like the trunk was “near the mess door”, so could be outside the mess. This is a bigger problem than you might think, since the areas involved are underwater and chaotic, so search is difficult. I will do patch-up retranslation where needed.

By themselves, yes. Not with a caption, e.g., a bale of hay with the caption "hay". Within an overall area captioned "Smells" I agree feelings, touch, probably tastes are better off text-only.

Engaging concept. For smells, which in your demo tend to predominant and persist, it might be less distracting to use icons+captions, a la the style of inventory items. Maybe, say, a column of these at the left edge. Constant smells would just be opaque, but a likely or possible smell more translucent and/or with pulsing, fade in/out.

You would hope that even if an algorithm raises a flag, a person would still review it, knowing that algorithms are imperfect. I agree that the EU provides way more privacy protection than the US. At least from third-party data brokers... don't know about from governments. I recall that researchers are working on "distilled" or other forms of light-weight AI that can run locally on your PC or phone, without needing the cloud and attendant privacy concerns. Translation is an obvious use case for this work, so some reason for optimism there.

By "IP", I'm thinking you mean my machine's address (not intellectual property). Yes, if an AI was not privacy-preserving, and actively monitoring for and reporting IRL criminal activity (likely many are), and misconstrued what I was doing, then I see your point. For my particular FM, the phrases don't really imply any criminal acts, just clues. This is not the case for all FMs. In those cases, when untrustworthy AI systems allow rich prompts, it's probably a good idea to specifically indicate you are writing for a fictional mission within a PC game. Also, the activity itself, translating into a fixed suite of multiple languages, is probably not something an actual criminal enterprise would do. Talking in the forums about your FM under development would also show that your intentions are not real-world crimes, and I'd like to think ward off all but the most wrong-headed prosecutions.

Nice to hear about this. That's an impressive roster of languages... but there's always the question, how good is it for translation to the particular language(s) one needs? Privacy-centered is great too, although perhaps less important for happenings in the fictional TDM world. I was also looking today at Anthropic's Claude Haiku 4.5 announcement, which seemed to suggest that the free tier includes access to it through its API. (In the long run, I can see driving forward/backward translations through different model APIs.) Haiku is claimed to be a small but powerful AI model. A general concern about making models small is that they are less knowledgeable, so maybe less good translations. So many AI systems, under such swift change. In the meantime, I'm taking a slow, cautious, and somewhat piecemeal approach, seeing where the translation problems are, and how to fix them.

I see a problem that's starting to bite me. I probably should have including some prompting to steer towards European dialects of languages, rather than relying on defaults. The latter for ChatGPT is said to be Brazilian Portuguese and "Latin American" Spanish (neutral, but leaning towards a mix of Mexican, Cuban, Venezuelan). The defaults dialects had more training data and so will be more accurate. But European (e.g., Castilian Spanish and Portugal's dialect) would better reflect TDM's predominant audience and the game's historic time period. Don't know that I really want to redo for this, tho. And TDM's language choice doesn't mention dialects.

Going to resume the paused Air Pocket back-translation work now.

Cyrillic Mason Released This project is wrapping up here, with hand-off for incorporation into a 2.14 beta release. For TDM’s Mason 48pt font, within the /russian/mason/ and (as a clone) /russian/mason_glow/ scope, it provides full coverage of all the TDM-supported Cyrillic characters. Characters may be seen up-close within this FM: testMasonLora3Way.pk4 of October 1. from which 2 representative overall screenshots are shown here. For further details, besides running the foregoing test FM and viewing what it says in the briefing, see also: 1) The bugtracker post 0006642: Extend Mason Font to All Cyrillic Characters which will be updated momentarily to indicate that other admins may begin the process of incorporating it into 2.14 beta releases. 2) The doc “Tested Changes to Russian Mason Font, Proposed for TDM 2.14, Oct 14 2025”. This 10-page Word doc first touches on the project background (for those not following previous posts in this forum), then talks in details about implementation aspects (mainly the successful ones) with their pluses and minuses. 3) The text file “fontimage_48[mason, Sept 30 2025].ref”, used to generate the corresponding final .dat file. It itemizes all 256 ASCII+Cyrillic characters, with annotations for this project. 4) The wiki’s Mason Font article now reflects a summary of these proposed changes.

Lips they flap, but the dubbed voices go their own way. YouTube doesn't have access to the underlying character 3D model, so can't easily adjust lips to match dubs. Tho some artificial intelligence systems for movie dubbing do that now, so I guess it's a matter of time for YouTube too.

I just added a bugtracker ticket about this work: 0006642: Extend Mason Font to All Cyrillic Characters For the benefit of that post, let me add a summary of the current situation. Current Workplan Originally, TDM's Mason was likely generated from Mason Alternate TTF, which has no Cyrillic coverage. Subsequently, some Cyrillic characters needed for TDM's main menu were presumably hand fabricated. To avoid further tedious hand-work, the strategy is to use just-developed program ExportUnicodeFontToDoom3 (see wiki) to harvest Cyrillic characters into supplemental DDS files and corresponding DAT. Source TTFs that have the required Cyrillic glyphs were reviewed. A distinctive aspect of Mason Alternate's style is that angular lines (like the sides of "A") are terminated by serifs that are stroke-perpendicular instead of horizontal. Other reviewed TTF fonts, including Regular Mason (and clone MasonChronicles) do not feature that. Thus, Mason TTF is an okay but not precise match to the Mason Alternate style. It is good match for some characters, but less for others, where it substitutes curved lines for angular ones. It has unpromising licensing. Of TTF fonts with Cyrillic coverage and open-font licensing, Lora has an adequate (though not precise) stylistic match, with the desired angular lines. Lora coverage and character style were shown in a screenshot earlier in this thread. The current workplan is to have a 3-way merge of existing TDM /english/ Mason (which has crisper ASCII characters), existing /russian/ Mason, and newly generated Lora characters. The existing TDM Mason font has some hand-drawn Cyrillic characters, of variable quality, that may be stylistically preferred over Lora. Lora characters will be scaled and custom-aligned as appropriate. Kalinovka and Geep have a private DM going, including a spreadsheet to manage decisions about individual characters.

I did originally consider using either a key binding (hard to come by) or a button. The button would seem to require a lot of iteration and per-readable customization to find a location where it's not blocking the text. Plus i18n for its label and complex treatment of when to hide and show it (or in some cases toggle the text). I got tired just thinking about it. So while I don't deny that player control is good, my more-limited version I feel is more-practically implementable with a reasonable amount of core-coding and GUI-hacking work for 2.14 or 2.15

Links for Release 1 of ExportUnicodeFontToDoom3 are finally posted on the wiki.

testLora Released (Aug 30 version - run4) testLora.pk4 This shows an experimental FM, run 4 of testLora. It's certainly not the final product. The idea is to generate the Cyrillic characters for /russian/mason/ from a TTF font that has them (unlike MasonAlternate, the traditional TDM "mason" font), but is not too unlike MasonAlternate in style. And has a license we can live with. During generation, scaling was done (by using ExportUnicdoeToDoom3 with 45pt as a stand-in for "48pt"). As the screenshot shows, this makes the Lora lower case characters the same height as MasonAlternate lower case. However, the Lora upper-case characters, unlike MasonAlternate are not yet scaled up by 120% nor top-aligned. (Nor will they be at this point in the experiments.) The final product will likely have complex 3-way character sourcing, from MasonAlternative ASCII, some MasonAlternative Cyrillic, some Lora Cyrillic. Restating the briefing: Here's a mockup TDM character set, within-world, for a mixture of Mason and Lora fonts for Russian characters. This version of the FM has - - at codepoints 0x00-0x7f, the TDM 2.13 Mason ENGLISH characters. Most of these are crisp due to enlarged bitmaps. - at codepoints0x80-0xff, there's freshly generated Lora 45pt (passing as Mason 48pt) for Russian character set. Make sure TDM's language is set to Russian. On a room's floor, all cp1251-defined (and thus DAT-defined) printable glyphs are laid out, to quickly reveal missing & bad characters. They are shown twice, to evaluate 'stray marks' (due to bounding box overlap of neighbor glyphs) & vertical/horizontal 'spacing' [shown in screenshot]. View it all from the ledge (or noclip), or walk the floor for close inspection. No special top-alignment or per-character scaling yet. If used in an FM (as here), this font will not include 'glow' enhancements.

Maybe. I try to ideally only rotate once from a grid-aligned object, to minimize problems. So in your case, have a grid-aligned fence segment from which you copy and rotate each segment separately. Or you could temporarily go to a rather fine grid if you have to do cumulative rotations. But in my experience that sometimes can cause other problems... objects in question disappearing, mysterious lighting artifacts.

I'd vote it NO. I'm thinking that a "save game" just copies the process's memory and registers into one big mostly unstructured blob file, and "load" just reverses that process. I don't see anyway for DR to work with that.